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..
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.
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.
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.
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.
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.
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.
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.
Article and comments below show lack of domain knowledge (even for 2011).
Most of the price of the smallest (1KB ram) micros today is in packaging, shipping, handling and both manufacturer and distributor margin. Price of silicon is almost irrelevant. Micros that go into memory cards cost 1c each and are shipped as bare dies.
> if a 1kB MCU were to cost ~$0.01 I think you would see it going into things like watches simple calculators and even flashlights
they do and they are
>I sure the heck don’t need linux or android running my washing machine.
its not about your need, its about marketing. If someone can make a fridge with embedded android tablet (~$10 bom) and differentiate this way from competition they will, even if its a shitty useless embedded system. Its not a question of why, its a question of why not :) Smart TVs are a perfect example, it doesnt cost anything to make TV "smart". Difference between bare lcd controller TSUMV29LU and one full of hardware decoders TSUMV59XU (mp3, MPEG1/2/4, DivXˈ, H.264, RV8, RV9, RV10, Xvid, jpeg, mjpeg) is ~one dollar. Its the same with ram, at this point small amounts of ram are basically FREE, differences you see in datasheets and in price listings are dictated by politics and market segmentation.
8051 was ~60K transistors (same ballpark as Cortex M4), 1KB ram is 1000 transistors, <2%. There really is no difference between selling you 128 bytes or 2KB ram chip, other than trying to create virtual segments and artificial price brackets.
Right. The real jump from small to large RAM devices is the presence or absence of DRAM.
Large SRAMs get costly and power hungry quick - the largest RAM Cortex-M4 devices have about 192KiB of SRAM, but cost $6-10. The jump to DRAM, however, is very expensive, because DRAM is fabricated on a different process and needs to be installed as a separate die or package. It is also too high latency to use as the only RAM, so a SRAM cache is still necessary.
The market currently segregates a lot of other features based on the RAM interface. Cortex-M series cores, sold as "microcontrollers", almost never have DRAM, only support Thumb-2, and have no MMU. Cortex-A series are sold as "application processors", have external DRAM interfaces, and include a MMU. A similar divide is visible with the MIPS architecture.
I'm starting to see more and more Cortex-Ms with DRAM interfaces. STM32F427s added them to their FSMC peripheral (their new discovery board has 32MB of DRAM actually).
NXP's LPC line of microcontrollers are M3 or M4-based and have external SDRAM interfaces that work pretty well (no high-speed layout necessary). They've been around for a while.
> 8051 was ~60K transistors (same ballpark as Cortex M4)
While I agree with your overall premise, could you provide a citation on this? I find it hard to believe that a Cortex M4 is only 60K transistors. A 32x32 multiplier should be almost 10,000 transistors by itself.
This page quotes a Cortex M4 announcement press release (which I can't find) which says that a stock M4 (without FPU/DSP instruction support) comes in at 65k gates. Meanwhile this pdf: http://www.mcu-related.com/architectures/35-cortex-m3/96-cor... claims that an M3 comes in at 43k gates. The main difference between the two is a 32x32+64 into 64 multiplier for DSP use plus some SIMD instructions so your estimate for the multiplier seems to be in the right ballpark!
Even assuming it would be possible to build ram that takes almost no power(which is a scarce resource in many systems), still memory is the biggest tool vendors use today to differentiate prices between chips and to optimize profitability and this fits with product makers since more memory generally means more complex and expensive product.
but we also see a shift towards low-cost chips with lots of memory,for example a new NXP dual-core $2 chip with 108k ram
.
What's extra nice about this chip is that it let's you use( in theory ) a garbage collected language ,or even a scripting language in one core and c in another core for your realtime stuff,thus enabling you to mostly write high level code while still having a realtime system.
Looking around, the cheapest I found was $2.62, if you buy a reel of 3000 of them [1]. It's definitely a nice price, but saying something costs two bucks implies maybe up to two and a quarter each, not when it's closer to three.
The LPC54100 series will be available... in the first quarter of 2015, with pricing starting at USD $1.99 in 10K quantities.
If you came from the future to inform us that NXP lied about their chips costing $1.99 in 10K quantities in 2015, then your beef is with the NXP marketing department, not minthd.
minthd is just relaying a number he read in a news article, which in turn relayed it from a NXP press release.
I completely missed that in my reading over the article, which was why I ended up searching for and linking to an aggregator that shows retail pricing.
I think they do. One one hand, for building complex embedded systems it sure is nice to be able to get an Arm processor, Linux a high level language etc. Getting all that setup takes time, but it's worth it since it since the rest of the development goes so much faster.
But, I still use a ton of AVRs and similar small memory micros. For each big micro I use, they have a few small micros in support. It's so much easier to do hard real time without an OS, or pipelines, etc. When you can just count instructions and know the timing.
As the bigger micros continue to move down market, the small ones will get even smaller and lower power and open up new markets.
Currently I'm working on instrumentation amplifiers and the analog signal can't travel very far. So each one has its own AVR controlling it. Then there is a high powered micro that collects and stores all the data.
Or, there may not be enough pins. May use a small micros to watch all the user interface buttons (think like a keyboard controller) which communicates to the large micro.
A stereotypical answer FigBug didn't mention was interrupt latency is much faster and jitter in the interrupt latency sometimes doesn't even exist.
Also, closely related to above, simplicity and modularity. Don't want to be the guy debugging why the antilock brakes occasionally miss an encoder transition when the engine RPM fuel injector routine is just perfectly the wrong interrupt rate. Its very much unix vs windows philosophy WRT monolithic-ness.
I went to a talk the other day [1] that argued that the really low end were too small to do crypto so their use cases were limited by that to non networked applications. Mid range eggs Cortex can though.
If I read the article correctly, "Small Ram Devices" can refer to devices with < 16 bytes of memory and < 128 bytes (the first two categories) - from that perspective, 128 kbytes is 1000x to 8000x larger.
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.