$5 Arduino-compatible Linux board

liudr: On a separate unrelated note, I've not tried any ESP8266 products. How long is the wait? Does anyone know?

With my LoLin NodeMCU board it's no more than 2 seconds from reset button to Lua 5.1.4 command prompt. With a boot loader into a compiled application (i.e. development in the Arduino environment) I'd expect it would be faster than that.

since discussion has drifted to comparing boot times:

my old 16mhz 386 pc with quick start bios takes about 250ms to dos prompt ready to edit and assemble or compile with turboc 2.1

esp8266 starts running custom flashed code in about 600ms. espressif AT prompt about 3 sec. lua or python or any other code with spif several more seconds to get going.

my 3.3ghz pc gets through the bios and into real mode msdos in about 8 sec. boot to xp desktop about 15sec.

rpi0 with an older minibian able to run user program, editor, or start gcc compile in about 10 sec. jessie may take a up to minute depending.

establishing an internet connection on any of those last ones (pretty much mandatory) may take 3 minutes or more. and you better not power down those last couple w/o asking the machine for permission!

ahhhh.... the benefits of modern technology.

john1993,

I think boot time comparison is absolutely on topic. The boards should advertise for $5 after 60 seconds and say 15 seconds to power off etc. if they are totally honest to the potential customers. As long as there is a gap in boot time, there is opportunity for MCUs to fill it.

i agree. i laughed at the rpi foundation april fools joke showing "new" pi version with onboard m328 coprocessor but really its not that crazy:

https://thepihut.com/products/raspberry-pi-model-c

aside from power/supervisory functions the addition of adc capability would be a major advantage to pi. imo better than gertboard kluge and far more useful than those marginal rpi3 improvements. however due to rpi foundations pride and prejudice unlikely to ever happen.

There is definitely a place for bare-metal, though I have tried and failed to explain it many times. Boot up speed is part of it, but what about getting hardware to work. In a past life, I was able to directly access registers to control instruments (DOS), but none of that worked on NT. Linux needed device drivers also, and although I tried it never worked and I give up. I can see that the Pi has GPIO, SPI, and I2C drivers, but what if I want ICP or some other peripheral. I can't just write to the hardware on Linux like I can on the bare-metal, I would have to make a device driver for the kernel. I don't want to spend that much time on ICP and frankly, I can't even think of a way to abstract the ICP function for the kernel. That is why I think the bare-metal coprocessor idea is solid. Not so sure about the name "coprocessor" though. It's not really adding processing power, e.g. floating point coprocessor adds ... well anyway.

in the arm world bare metal has sharp edges and WILL draw blood. sometimes pain with NO gain because many just give up once they realize the obstacles. avr on the other hand is soft and friendly with a gentle ladies touch. symmetric instruction set, sensible architecture, and friendly tools.

symmetric instruction set, sensible architecture,

We're programming in C. instruction set and (mostly) internal architecture are irrelevant... (indeterminate timing is annoying, though...)

westfw: We're programming in C.

not all of us. the best c programmers know asm too. how and when to use it. as do those who create the tools the c girls depend on. so a useful talent. specially when it comes to bare metal. REALLY bare metal.

regardless of language the issues with arm libraries and toolsets are legendary. not so much with avr.

"irrelevant" is apparently in the eye of the beholder.

The biggest problem with the ARM chips seems to be "complex peripherals." On something like a Maple, that means A2D, timers, and serial controllers that are significantly more difficult to use than typical AVR peripherals. For bigger chips, it includes things like DMA, Ethernet and USB that are inherently complex. For Raspberry Pi class boards, you see MMUs and GPUs and such that are yet another step up in complexity.

I avoid assembly these days, it caused me some gray hair at a very young age. As a side note I looked at the Intel Curie, no I did not buy one just looked at the rather spartan/anemic info (at the time) and the first thing I tried to figure out was how to do an ISR. From what I could tell they have to be done with assembly, or at least started with such. Then I had to go look at how Linux did x86 ISR's... oh the pain, yep it seems to be true there is something odd about the x86, it does not appear to have interrupt vectors that can be mapped in C the way AVR (or ARM) does (I need to look at MIPS).

moving back onto topic…

I backed it at the Omega 2 Plus option, bigger memory and SD-card ($9) with base unit for the tune of $24

I also backed this Bluetooth & Javascript module as well.

Just decided to back them. The campaign seems to be getting quite a bit of traction.

The $5 price point is great for embedding into projects or commercial products. The product will likely come with power supplies to supply it with power. So i guess the cost for the docks, expansions and whatever are only for during the development process. This could significantly cut product development time and production cost.