Is there any significant work to add 8-bit microcontroller support to Rust?
[1]: https://github.com/rust-lang/rust-roadmap/issues/15
[2]: https://github.com/rust-embedded/rfcs
Which is the interesting thing for me. At the current processing nodes (22nm and even 45nm) the cost of the packaging and bin testing dominates. It costs, too a fairly close approximation, exactly the same to put a chip in that is 8 bits as it does to put one in that is 32 bits.
I had a great discussion with a product manager from ST Micro about this at their recent Developers Conference in the Bay Area. They had some collateral on the STM8 series and I asked about it and he shared the above but said that it was either legacy designs, essentially CPLD type designs, or HW engineers without a software person to support them that seemed to still use 8 bit machines. From ST's perspective the cost to produce was the same.
At Digikey the lowest cost 32 bit processor is 58 cents[1], and the lowest cost 8 bit processor is 40 cents[2].
[1] https://www.digikey.com/product-detail/en/stmicroelectronics...
[2] https://www.digikey.com/product-detail/en/stmicroelectronics...
Are you referring to Rust here?
I have a friend that does a lot of consumer electronics development on contract. One of his favorite parts is an 8 bit micro that cost 6 cents in bare die, and that was a few years ago. The part is probably 4 cents now. A 4 dollar ARM looks rediculous next to a 4 cent part in certain application spaces.
But in my world - low volume mechatronics - the ARM with 1mb flash is the no-brainer choice.
On our product we have up to 4 processors, 1 32bit, 2 16bit, 1 8bit. Smallest only has 20bytes of RAM
Ideally I'd like to program them all with a super typesafe language
Atmel still produce a significant number of 8bit AVRs.
http://www.mouser.at/Semiconductors/Integrated-Circuits-ICs/...
Apropros "M0's being so much better", this is not really an attitude that produces effective results in "the embedded" world.
True fact: in embedded, many times you want the least powerful solution. 8-bit MCU's are freakin' everywhere, and they are not going anywhere.
That's true, but you can usually run the ARMs at higher clock speeds.
Cheapest 8-bit AVR on Digikey: https://www.digikey.com/product-detail/en/microchip-technolo...
2.5x the price is not cheaper.
If you're selling hundreds of thousands or millions of something, suddenly that is real money that justifies the incremental increase of engineering effort to use a cheaper part.
And of course they still make tons of them, it's embedded, you need to supply these chips for another 10 years for old designs.
But you shouldn't use an 8-bit uC in a new design.
What makes you say that?
MicroChip released new xMega's in May. [0]
While the core of a 32-bit controller doesn't take up much die area at smaller process nodes, core size has never really been the limiting factor with MCUs. Look at any MCU die - the flash and RAM both dominate in size over the logic. Going to a 32 bit controller generally means that your instructions are going to be wider, so your program space is going to take up more flash. You will also tend to use more RAM unless you are judicious about word size, and a context switch on an RTOS will cost more memory since the context contains much wider registers.
Another pain point with the 32-bit MCUs is that ARM currently dominates the market, and their licensing fees add a few cents to the cost of each part - which can be a killer at volume. There have been attempts to break ARM's monopoly (most notably Microchip's MIPS-based PIC32 series) but it seems like ARM will continue to dominate this space in the years to come.
As a final note, SiLabs recently introduced an ultra-low power microcontroller line based on the venerable 8-bit 8051 core, so clearly they think that 8-bit MCUs have a role to play in the years to come.