4 ms·

Having Rust support embedded is only half the story: we need to lobby/advocate for chip makers to support Rust. The article doesn't directly call this out, but

Having Rust support embedded is only half the story: we need to lobby/advocate for chip makers to support Rust. The article doesn't directly call this out, but I think it's important for Rust to truly succeed in this space. Most embedded systems are fairly closed ecosystems built on vendor-specific stacks, and most professional embedded engineers wouldn't want to use Rust until the vendors support it. This isn't to say the hobby world (ala Arduino/Raspberry Pi) wouldn't benefit from Rust, but I think the long-term viability depends on the ARMs, STs, TIs and Renesas' of the world starting to embrace Rust. To date I haven't seen this happen (although I'd love to be proven wrong!) Edit: just noticed the recommendation to use a Blue Pill for Rust dev. They're cheap on eBay (just picked up 2 a few days ago) https://www.ebay.com/itm/STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module-For-Arduino-/201529768817 https://www.ebay.com/itm/STM32F103C8T6-ARM-STM32-Minimum-Sys... Looks like here is a supported Rust BSP, too: https://github.com/japaric/stm32f103xx-hal https://github.com/japaric/stm32f103xx-hal Anybody have any experience with this?

eaurouge 9y ago
Specifically what level of support are you expecting from ARM, ST or TI?
- wiremine 9y ago
  Ideally I'd like to see Rust used to ship in production systems. I do a lot of IoT, and I don't see any of my customers green-lighting Rust until the silicon guys say "yes, we'll support Rust" and provide official HALs and support.
  - petra 9y ago
    What about vendors wrapping their HAL's to rust with bindgen(or an improved version) ? will that be enough ?
kibwen 9y ago
I know this won't assuage your concerns about officialness, though it's still worth mentioning that Rust does have community-maintained HALs (https://github.com/japaric/embedded-hal https://github.com/japaric/embedded-hal ) and tools to generate APIs from official vendor-provided SVDs (https://docs.rs/svd2rust/0.12.0/svd2rust/ https://docs.rs/svd2rust/0.12.0/svd2rust/ ). There's also a few boards out there that do support Rust natively: Hail (https://www.tockos.org/blog/2017/introducing-hail/ https://www.tockos.org/blog/2017/introducing-hail/ ) and Tessel (https://www.tessel.io/ https://www.tessel.io/ ).
bb88 9y ago
> Having Rust support embedded is only half the story: we need to lobby/advocate for chip makers to support Rust. So one thing I noticed from the micropython world is that chip makers are not going to support micropython. But there are third party companies that are supporting python on specific microcontrollers. One problem the chip makers have right now is language frag. Rust is competing against go, python, kotlin/native, swift, javascript, and others. Rolling a tool chain is not free, because it needs to be updated over time for optimizations and code fixes.
- wiremine 9y ago
  Kotlin Native might have a chance, and it looks like they are targeting embedded. But the rest aren't good fits: Anything with a GC is a no-go for serious MCU development. You just can't optimize the code deep enough. Swift's reference count system might be interesting... would be curious if you could target Swift for something like a M4 or M3. Rust is the only low level systems language that really has a chance to complete with C/C++ in the space: it's mature, has a great community that's sizable, etc. (I'm talking about using Rust for professional embedded projects... I LOVE micropython as a hobby)
  - bb88 9y ago
    > Anything with a GC is a no-go for serious MCU development. That's a really good point. Edited to add: But now that I think about it, Java was originally a micro controller language. Sun decided it was better for the enterprise. https://en.wikipedia.org/wiki/Java_(programming_language) https://en.wikipedia.org/wiki/Java_(programming_language) I'm not sure if they included the GC in the original version or not.
mtgx 9y ago
Time to start lobbying Arm. For instance, I think we already missed a big opportunity to have Arm develop its Firmware-M in Rust. That firmware is going to be used by billions of IoT devices in the future. Although I'm sure Arm is trying to make the C code as safe as possible, at that scale there will be plenty of bugs, especially since OEMs will get to use customized versions of it, too. https://developer.arm.com/products/architecture/platform-security-architecture https://developer.arm.com/products/architecture/platform-sec...
- carlmr 9y ago
  The last time I used ARM supplied drivers they were nice to get things started quickly, but they were of terrible quality (at least for the smaller Cortex M microcontrollers).
emilfihlman 9y ago
"Vendor support" for programming tools is cancerous and hurts development. We need to actively push away from such idiocy.
- AnimalMuppet 9y ago
  You're a hardware vendor. You've created a new embedded CPU chip. Since it's new, gcc doesn't support it yet - and may never, if it gets no sales. But nobody's going to buy it if there isn't a C compiler for it. So you, the hardware vendor, kind of have to do vendor-supported programming tools, or your new chip will never sell. So what's your alternative to vendor-supported tools? Only use the standard chips that are already supported? That doesn't sound like progress. Expect people to design in a chip where there are no tools? That's not going to fly. Expect gcc to support every brand-new chip, whether or not it has any sales? The gcc people seem unlikely to see it your way. So, what is your alternative?

eaurouge 9y ago

Specifically what level of support are you expecting from ARM, ST or TI?

wiremine 9y ago
Ideally I'd like to see Rust used to ship in production systems. I do a lot of IoT, and I don't see any of my customers green-lighting Rust until the silicon guys say "yes, we'll support Rust" and provide official HALs and support.
- petra 9y ago
  What about vendors wrapping their HAL's to rust with bindgen(or an improved version) ? will that be enough ?

kibwen 9y ago

I know this won't assuage your concerns about officialness, though it's still worth mentioning that Rust does have community-maintained HALs (https://github.com/japaric/embedded-hal https://github.com/japaric/embedded-hal ) and tools to generate APIs from official vendor-provided SVDs (https://docs.rs/svd2rust/0.12.0/svd2rust/ https://docs.rs/svd2rust/0.12.0/svd2rust/ ). There's also a few boards out there that do support Rust natively: Hail (https://www.tockos.org/blog/2017/introducing-hail/ https://www.tockos.org/blog/2017/introducing-hail/ ) and Tessel (https://www.tessel.io/ https://www.tessel.io/ ).

bb88 9y ago

> Having Rust support embedded is only half the story: we need to lobby/advocate for chip makers to support Rust. So one thing I noticed from the micropython world is that chip makers are not going to support micropython. But there are third party companies that are supporting python on specific microcontrollers. One problem the chip makers have right now is language frag. Rust is competing against go, python, kotlin/native, swift, javascript, and others. Rolling a tool chain is not free, because it needs to be updated over time for optimizations and code fixes.

wiremine 9y ago
Kotlin Native might have a chance, and it looks like they are targeting embedded. But the rest aren't good fits: Anything with a GC is a no-go for serious MCU development. You just can't optimize the code deep enough. Swift's reference count system might be interesting... would be curious if you could target Swift for something like a M4 or M3. Rust is the only low level systems language that really has a chance to complete with C/C++ in the space: it's mature, has a great community that's sizable, etc. (I'm talking about using Rust for professional embedded projects... I LOVE micropython as a hobby)
- bb88 9y ago
  > Anything with a GC is a no-go for serious MCU development. That's a really good point. Edited to add: But now that I think about it, Java was originally a micro controller language. Sun decided it was better for the enterprise. https://en.wikipedia.org/wiki/Java_(programming_language) https://en.wikipedia.org/wiki/Java_(programming_language) I'm not sure if they included the GC in the original version or not.

mtgx 9y ago

Time to start lobbying Arm. For instance, I think we already missed a big opportunity to have Arm develop its Firmware-M in Rust. That firmware is going to be used by billions of IoT devices in the future. Although I'm sure Arm is trying to make the C code as safe as possible, at that scale there will be plenty of bugs, especially since OEMs will get to use customized versions of it, too. https://developer.arm.com/products/architecture/platform-security-architecture https://developer.arm.com/products/architecture/platform-sec...

carlmr 9y ago
The last time I used ARM supplied drivers they were nice to get things started quickly, but they were of terrible quality (at least for the smaller Cortex M microcontrollers).

emilfihlman 9y ago

"Vendor support" for programming tools is cancerous and hurts development. We need to actively push away from such idiocy.

AnimalMuppet 9y ago
You're a hardware vendor. You've created a new embedded CPU chip. Since it's new, gcc doesn't support it yet - and may never, if it gets no sales. But nobody's going to buy it if there isn't a C compiler for it. So you, the hardware vendor, kind of have to do vendor-supported programming tools, or your new chip will never sell. So what's your alternative to vendor-supported tools? Only use the standard chips that are already supported? That doesn't sound like progress. Expect people to design in a chip where there are no tools? That's not going to fly. Expect gcc to support every brand-new chip, whether or not it has any sales? The gcc people seem unlikely to see it your way. So, what is your alternative?