Dimwit #1: Ah, use a 555 timer.
Dimwit #2: Use an Arduino with the Blink sketch.
Senior Software Developer: I'll use a Linux board with a blink program running on Node.js. The blink program will watch for the alarm condition and blink the LED in response. The program will also provide a web based configuration interface. What if marketing changes the requirements from a simple blink pattern to:
blink blink (pause) blink blink (pause) etc...
The simple 555 timer approach would be too inflexible.
The arduino approach would require altering, recompiling and re-flashing the firmware.
The senior software developer approach would be sufficiently flexible that you could connect a web browser and reconfigure the blink pattern.
Each blink pattern can be given a name and saved. Such as the slow-blink, fast-blink, double-blink, etc. Each pattern consists of a list of on/off states associated with a duration in milliseconds. Anyone can point their browser to this and reconfigure new blink patterns that become popular.
What could possibly go wrong?
Here's my counter-argument in case you were serious.
Dimwit #1: 555's fail when hell freezes over. An engineering intern can make changes and see it work. The PCB will cost more than the electronics. 555 as a component will be available for years.
Dimwit #2: Arduino/ATMEGA are so well documented that the next engineer supporting this should have no problem making appropriate changes even 10 years from now, assuming Microchip sustains the ATMEGA product line.
Senior Software Developer: You've introduced an attack vector [the web interface], increased the BOM cost [the Linux board], programmed it in a language that changes on a yearly basis [node.js]. Not to mention having to provide a Linux image source programmable [preferably eMMC], and ensuring compatibility of the web config for major browsers for the lifetime of the product. All for a blinking LED.
Although I'd use a tiny micro or a blinking diode by now.
It's actually a pretty huge development as far as electronics go.
Unfortunately in my case, I want to use it in a product with wired ethernet, so a PocketBeagle limited to a USB or SPI ethernet device because the it doesn't expose the pins for the AM335x's integrated MAC.
Also, buying the Octavo chip alone in small quantities is much more expensive than the whole PocketBeagle :( I wish they made a PocketBeagle-Pro with all signals routed out through high-pitch headers, comparable to Olimex's AM3352-SOM.
https://hackaday.com/2015/02/19/turn-your-beagleboneblack-in...
The Black has open-sourced schematics that can easily be edited into your own project. The Beaglebone design philosophy (start with this design and expand on it) is slightly different than the Raspberry Pi one (shoehorn it into whatever you are doing)... which is exciting to embedded developers but confusing to people that have only worked with the RPi.
It's nice to be able to do a one-off thing like that with high-level tools.
You don't have to use all of the CPU or RAM capabilities. The use cases appropriate for this board include all potential use cases for an equivalent board with less CPU or RAM. I don't think it's fair to knock it for being too capable.
Development/prototyping is an obvious one of course.
But you'd really consider this for really anything that has substantial direct user interface requirements (ie has an actual GUI + full keyboard and maybe even touchscreen interaction).
Or maybe you might use this somewhere where you're not super BOM cost or power constrained, with fuzzy requirements, and limited developer resources. Using this class of hardware opens up using 'standard' Linux tools which can potentially bring great savings in terms of: portability, availability of developer resources, ease of development. There may be applications where a 5-10x increase in BOM cost in exchange for not having to hire an embedded guy might be worth it.
A few months ago, I started on a project that needed to read an input signal, do some trigonometry on it and update some I/O at a 30kHz update rate. The kind of thing a DSP could handle in its sleep, but I don't have DSP tools and it wasn't worth the investment.
Since a standard Arduino Uno wasn't fast enough to do the math, I built a table of precomputed sines & cosines, scaled to the output signal.
But then we needed 12 bit analog input. Since the Cortex M0 on newer Arduinos (Due?) has a 12 bit A/D and is much faster, I could now drop my precalculated table and do the math on the fly.
But the ADC in the M0 turned out to be crappy, so I ditched it for an off-board 12-bit ADC and went back to the Uno and the sin/cos tables.
Had I not been concerned about latency and startup times, I'd have used a Raspberry Pi with an external ADC or a Beaglebone right out the gate and probably finished the project inside a week. I'm selling the hardware with enough margin that the extra cost doesn't matter to me and it matters even less to my customer.
That’s part of the story with Linux on BIOS. Motherboards started shipping with EEPROMs that were 2-4x larger than the BIOS would ever get, as big or bigger than typical rescue disks.
I probably waste way more power at home by keeping the lights on, but I always get a bit frustrated with how much power some of these boards use. It adds up! My college professors probably drilled power management way too hard into my head.