4 ms·

Honestly it depends upon what people expect from "the port". A lot of people seem to be content with Arduino-like software compatibility: high-level constructs

Honestly it depends upon what people expect from "the port". A lot of people seem to be content with Arduino-like software compatibility: high-level constructs that offer basic functionality expected across a larger number of mcu's. Even something as "simple" as a timer peripheral will vary greatly across manufacturers and families of mcu's -- something you'd care about for real-time control, but not care about in other cases. ARM controllers are (relatively) uniform and the svd files do a lot of the work by providing the mapping for the memory mapped peripherals. Across other devices it becomes even more complicated. AVR devices, AFAIK, are not providing memory mapped flash. There are also differences in byte v page erasable flash and eeprom. How would something like this map to Rust? I don't know and I'm honestly skeptical of the practical use but there is a quite serious effort put into making the AVR backend for LLVM ready for use. --- It really makes me wonder a lot about "embedded" programming and where it is heading. If I were to bet I'd say that there is a significant movement to employ more and more powerful "microcontrollers" in order to allow remove all the resource constraints typically associated with "embedded" programming. Stuff like Esprino, MicroPython, huge layers of abstraction etc. are today kind of nice tools for learning and starting out -- but give it a few years and somebody will ship a successful product build around this. It doesn't matter that the BOM cost is higher, the current draw is larger and the complexity and security understanding decreased -- it enables a faster time to market and in the end that is what makes the business. The same is happening in FPGA development. The old-fashioned hardware folks say that "not how it's done" -- myself included. But you know what they say: > When the wind of change blows, some build walls, while others build windmills.

vvanders 9y ago
> It doesn't matter that the BOM cost is higher, the current draw is larger and the complexity and security understanding decreased -- it enables a faster time to market and in the end that is what makes the business. I think consumers are still going to be cost-sensitive in quite a few markets so BOM will still be critical. I'd argue you're already seeing this with more than a few companies using Android + mid-tier ARMs when market time matters more than final cost. There's probably just going to be less people that know how to do it, much in the same way native programming is today.
fake-name 9y ago
> ARM controllers are (relatively) uniform and the svd files do a lot of the work by providing the mapping for the memory mapped peripherals. What? Sure, the core is relatively uniform, but the peripherals are radically different between manufacturers.
- henrikeh 9y ago
  Absolutely, device drivers must still be written. My observation is just that these device drivers are hidden deeper and deeper levels of abstraction, just like on a regular PC.
- FigBug 9y ago
  CMSIS provides an abstraction layer for peripherals, so at least the basics are the same between manufacturers. At least it's something, usually when switch MCUs you have to rewrite everything related to peripherals. https://developer.arm.com/embedded/cmsis https://developer.arm.com/embedded/cmsis
  - dbcurtis 9y ago
    True, but the main way an ARM licensee has to differentiate their product is adding unique peripherals. So the generic functionality is in CMSIS, but the reason you chose the processor may not be. If you look at a die photo and see what area goes to what, pretty quickly you conclude all microcontroller makers are just selling value-added flash memory.
nickpsecurity 9y ago
No need to speculate: the market data has been showing a move toward 32-bit just as you thought would happen. https://semiengineering.com/mcu-sales-up-in-2017-and-2018/ https://semiengineering.com/mcu-sales-up-in-2017-and-2018/ As vvanders says, the hard data shows plenty of the market is still maximizing profit by using 8-bitters (33%) and 16-bitters (26%). That's a combined 59% of microcontrollers a 32-/64-bit-only language would be leaving on the table in terms of deployment. Even ATS language, much more difficult than Rust, has already been deployed on 8-bitters. http://metasepi.org/doc/metasepi-icfp2015-arduino-ats.pdf http://metasepi.org/doc/metasepi-icfp2015-arduino-ats.pdf Hopefully, Rust stays adding whatever features are necessary to support this stuff. If not, the Haskell crowd can always grab it up with DSL's like Ivory: https://ivorylang.org/ivory-introduction.html https://ivorylang.org/ivory-introduction.html EDIT to add: A link about 4-bit MCU market that still exists for anyone wondering what that part of the pie chart was about. http://www.ganssle.com/rants/is4bitsdead.htm http://www.ganssle.com/rants/is4bitsdead.htm
- Ericson2314 9y ago
  Glad to hear it! Good languages as you agree have the potential to keep dev and material cost down, so there's no trade-off. But people seem to hate learning...anything, and was worried the market had already gone to too powerful devices out of laziness. Glad to hear the battle is not yet lost!
- jabl 9y ago
  Knowing very little about the low-end micro-controller manufacturing economics, isn't there some kind of lower bound limit where the marginal cost of the chip itself is utterly dwarfed by the cost of the pins and packaging? Sure, a 32-bit chip is bound to be bigger than an equivalent 8 or 16-bit one, but e.g. the pulpino project has designed a 32-bit one using only 11.6 kGE. Not very much nowadays. For comparison, according to someone from Atmel, the AVR core is 12k gates, and megaAVR is 20k gates (https://www.embeddedrelated.com/showthread/comp.arch.embedded/14362-1.php https://www.embeddedrelated.com/showthread/comp.arch.embedde... ).
  - nickpsecurity 9y ago

vvanders 9y ago

> It doesn't matter that the BOM cost is higher, the current draw is larger and the complexity and security understanding decreased -- it enables a faster time to market and in the end that is what makes the business. I think consumers are still going to be cost-sensitive in quite a few markets so BOM will still be critical. I'd argue you're already seeing this with more than a few companies using Android + mid-tier ARMs when market time matters more than final cost. There's probably just going to be less people that know how to do it, much in the same way native programming is today.

fake-name 9y ago

> ARM controllers are (relatively) uniform and the svd files do a lot of the work by providing the mapping for the memory mapped peripherals. What? Sure, the core is relatively uniform, but the peripherals are radically different between manufacturers.

henrikeh 9y ago
Absolutely, device drivers must still be written. My observation is just that these device drivers are hidden deeper and deeper levels of abstraction, just like on a regular PC.
FigBug 9y ago
CMSIS provides an abstraction layer for peripherals, so at least the basics are the same between manufacturers. At least it's something, usually when switch MCUs you have to rewrite everything related to peripherals. https://developer.arm.com/embedded/cmsis https://developer.arm.com/embedded/cmsis
- dbcurtis 9y ago
  True, but the main way an ARM licensee has to differentiate their product is adding unique peripherals. So the generic functionality is in CMSIS, but the reason you chose the processor may not be. If you look at a die photo and see what area goes to what, pretty quickly you conclude all microcontroller makers are just selling value-added flash memory.

nickpsecurity 9y ago

No need to speculate: the market data has been showing a move toward 32-bit just as you thought would happen. https://semiengineering.com/mcu-sales-up-in-2017-and-2018/ https://semiengineering.com/mcu-sales-up-in-2017-and-2018/ As vvanders says, the hard data shows plenty of the market is still maximizing profit by using 8-bitters (33%) and 16-bitters (26%). That's a combined 59% of microcontrollers a 32-/64-bit-only language would be leaving on the table in terms of deployment. Even ATS language, much more difficult than Rust, has already been deployed on 8-bitters. http://metasepi.org/doc/metasepi-icfp2015-arduino-ats.pdf http://metasepi.org/doc/metasepi-icfp2015-arduino-ats.pdf Hopefully, Rust stays adding whatever features are necessary to support this stuff. If not, the Haskell crowd can always grab it up with DSL's like Ivory: https://ivorylang.org/ivory-introduction.html https://ivorylang.org/ivory-introduction.html EDIT to add: A link about 4-bit MCU market that still exists for anyone wondering what that part of the pie chart was about. http://www.ganssle.com/rants/is4bitsdead.htm http://www.ganssle.com/rants/is4bitsdead.htm

Ericson2314 9y ago
Glad to hear it! Good languages as you agree have the potential to keep dev and material cost down, so there's no trade-off. But people seem to hate learning...anything, and was worried the market had already gone to too powerful devices out of laziness. Glad to hear the battle is not yet lost!
jabl 9y ago
Knowing very little about the low-end micro-controller manufacturing economics, isn't there some kind of lower bound limit where the marginal cost of the chip itself is utterly dwarfed by the cost of the pins and packaging? Sure, a 32-bit chip is bound to be bigger than an equivalent 8 or 16-bit one, but e.g. the pulpino project has designed a 32-bit one using only 11.6 kGE. Not very much nowadays. For comparison, according to someone from Atmel, the AVR core is 12k gates, and megaAVR is 20k gates (https://www.embeddedrelated.com/showthread/comp.arch.embedded/14362-1.php https://www.embeddedrelated.com/showthread/comp.arch.embedde... ).
- nickpsecurity 9y ago