Comment by userbinator | Hacker News Reader

Comment by userbinator | Hacker News Reader

It's 2 years after that article was written, and I don't see 8-bit MCUs and their accompanying tiny amounts of RAM going away anytime soon - although ARM seems to have had a lot of publicity, architectures like the 8051, with its 256 bytes of RAM (and up to 64K of external RAM, not present on all models), are still alive and well; for every chip containing an ARM core that's been shipped, there's probably several times more with 8051 or other 8-bit cores. I singled out 8051 because unlike PIC/AVR which are only single-sourced, and ARM which is not free, it's both produced by many manufacturers, and AFAIK it's free to implement.

In fact I wish the trend of making "smart" devices with grossly overpowered processors that were likely chosen just so they could run a fully bloated Linux distro - only to poke a few GPIOs based on some very simple input events - would stop. Running a full OS when only a tiny fraction of the functionality is used is not only wasteful, it adds to the security risk because of increased attack area.

A few years ago I programmed an 8 bit MCU that, with a few external components, controlled power for a much larger embedded system. I think the device cost about 17 cents, and it was cheaper than dedicated power control circuitry.

It was a fun little project; getting away from massive builds of console software and just sitting down for a couple of weeks and banging out some high reliability and very low footprint code was a refreshing change of pace.

It's funny that this little chip was still more capable (by several times) than the first computer I owned, back in the late 70s.

In the 80s my roommate and I used to joke that one day computers would be prizes in cereal boxes, just toys that would fall out. Those days have almost certainly arrived.

These things are so darned cheap that I can't see them going away.

The problem is: A lot of the 'native' libraries and even the open-source embedded RT OSs really suck.

And if you use a vendor's library you are very locked in: Let's say you use a TI chip for your prototype but then someone who knows stuff about designing hardware tells you that now it has to run on an Atmel processor because $profits... you will have to reimplement a lot of your stuff which costs (quite a huge amount) of time and might even require an entire rewrite..

you could always use something like the mbed or arduino , and have the ability to change chips ,but if you want to access the full capabilities of chips ,you'll cant have portability ,because you lose something when abstracting.

Am Arduino is not a production solution. It's great for prototyping, but to expensive for mass production. You go with something as small and cheap as possible.

You can totally use the Arduino in production, and it's happened quite often. The core of the Arduino is just the ATMega8 micro, which is only a few dollars - Arduino is just a nice programming environment and set of libraries for it.

Can you? Sure.

Should you? Oh, sure, if you want a very expensive piece of hardware in your product.

I think the parent was talking about Arduino as a software platform, instead of the Arduino hardware. The software itself will run on pretty much any of the 8 bit avrs, even things like the ATTiny45.

I've only done hobbyist embedded development, so maybe I'm totally off the mark here, but I would have guessed that for truly low RAM niches (i.e. ultra low power or extremely cost constrained), an RTOS would be totally out of the question. And for the vendor-provided libraries, if you're really memory constrained, you're probably writing in assembly language anyway which dwarfs any other porting cost.

Some of the ARM MCU's are frankly amazing though. Aside from development complexity and tool licensing, they seem to sacrifice very little. Low power, low price, high performance, many features.

Atmel really isn't helping on that front with their pricing. A few years ago I discovered I could buy a Cortex M3 that ran 10x faster, had 10x the storage and twice the features/IO, and 32-bit, for 75% the cost of Atmel's offerings.

And how much more power did the M3 consume?

It really depends on what you are doing. If you compare mA/MHz, the M3 will probably be lower than the AVR. If your micro is busy a lot, you maybe get lower power consumption from the M3. If your micro is idle most of the time, the AVR lower power states will probably be more efficient than the M3.

atmel recently announced a cortex-m0 with 40ua/MHz which is competitive with 8-bit , and energy micro chips are also very competitive using their smart peripherals .

Wow. To put that in perspective, I found a reference [1] saying the simplest Cortex-M0 chips have about 12K gates, which means that the processor uses about 20,000 electrons per cycle, per gate.

When you think about how many orders of magnitude of improvement there have been since the dawn of computing, it's astonishing to realize that there might not be too many left before we start hitting the fundamental limits of semiconductors.

[1]: http://www.arrownac.com/offers/nxp-semiconductors/cortex/cor...

Maybe there's a possibility to totally turn parts of the core on and off on instruction-by instruction basis - to the point where for each instruction ,you'll only have the logic responsible for it turned on ?

At that point, the power controller would be as complex as your application processor, and you'd be trying to figure out how to power gate some of its features.

Ok maybe instruction by instruction is a bit too much, But you could simple divide the core to many power areas(say 32), and before each code section, let a compiler set the optimal power gating for it by writing a 32 bit value.

I'm sure such an arrangement would get most of the power efficiency, with minimal complexity in the mcu.

A lot of micros already do that, with various levels of sleep, and lots and lots of i/o driven interrupts to wake up the processor when relevant data needs managed. What this ends up as is your processors main function sets up the proc, and then runs a loop that consists of little more than while(1) { sleep(); }. When some state changes that needs CPU time, it'll raise an interrupt, the interrupt handler will do what's needed, and the proc will go back to sleep. Micros have a lot of smart, low power peripheral processing available to them that helps keep power consumption even lower.

You're talking about smart autonomous peripherals.They're great,but if you need to run arbitrary code(or have the design more portable),you'll need to use the core, so it's valuable to have a similar fine grained power-gating applied to the core.

asynchronous processors, been on the table for over 10 years (if not 20)

http://www.design-reuse.com/articles/35659/8-bit-pipelined-a...

With the M series coming online with newer processes, they become very competitive with 8bit MCUs produced with older tech.

I believe the answer was less! I think it was more efficient under power, and had better sleep states.

Reply on news.ycombinator.com