11 ms·

Should you Rust in embedded yet?

164 points by blacksmythe 9y ago

wiremine 9y ago
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?
kibwen 9y ago
If anyone out there is an embedded developer curious about how Rust works in this space in practice, or a non-embedded developer curious about how to develop on embedded, there's a really fantastic (and free) ebook, "Discover the world of microcontrollers through Rust" (https://www.reddit.com/r/rust/comments/80doqg/discovery_discover_the_world_of_microcontrollers/ https://www.reddit.com/r/rust/comments/80doqg/discovery_disc... ), by Jorge Aparicio (the premier guru of embedded Rust development), and recently updated for 2018.
davidw 9y ago
One definition of "embedded" is: does the user treat it like an appliance or like a computer? If it's the former, it's 'embedded' even if it uses a reasonably powerful processor or does not have hard real time requirements. I use Erlang for that kind of thing and it works well. Rust is, I think, more performant, so if that works for you and what you need, go for it.
- dnautics 9y ago
  what do you think of nerves?
  - davidw 9y ago
    I recall hearing about it a while back; looks like it has made progress? Seems worth a look!
keithnz 9y ago
I'm completely in this boat at the moment. We are doing a hardware refresh of our embedded platform and I'm looking at the feasability of using Rust. I'm at the point where I think it is close to being viable, but seems very young. Most likely we will go with a platform that can support rust, and write the low level modules with the intent of using rust, but not use Rust just yet, but do a side project to asseses the viability of doing as much of the software in Rust as we can. ( and get the devs learning Rust ). I am what I like to call a multi stack developer, so I'm super comfortable with a lot of languages and platforms, but the embedded devs I work with are microcontroller focused C devs and it will take some time to be convinced, conceptually they like the idea, but as soon as they try and write something serious they are going to feel frustrated and likely make a mess. But Rust has a LOT to offer the embedded world.
- bb88 9y ago
  Keep in mind that at some level, something has to be unsafe, unless you've got hard mathematical proofs that your code works as compiled.
  - Sylos 9y ago
    Doesn't mean you shouldn't try to lessen the amount of code that's unsafe. That way you have at least a fighting chance at getting your unsafe code bugfree.
_sh 9y ago
Embedded developer here, ARM Cortex-M4 microcontrollers. I've been keeping an eye on Rust for the embedded space and although there has been a lot of movement in that area--particularly in the last couple of months--I'm not sure the value proposition fits the microcontroller market, where of course C is king. While Rust has much to offer as a programming paradigm in general, the main value is in the borrow-checker (the linked transcript cites 'memory bugs' as the most common class of bugs). Embedded software practitioners long ago abandoned dynamic memory allocation and with it the 'use-after-free' and 'out-of-bounds access' bugs, instead re-defining the problem as one of latency (e.g. you'll need to process that static buffer before it gets re-used by your UART interrupt). Take away the borrow-checker, and Rust looks less compelling. In time, Rust will find its niche in the embedded space, most likely occupying the high-level RPi/BBB/iMX SoC layer and perhaps working its way down to microcontrollers. As wiremine points out, it will require vendor support--moving away from your vendor's toolchain is a world of hurt that seasoned embedded developers just won't even consider. Pragmatism reigns: time-to-market and a cheap BoM are the main metrics, programming language a distant 10th.
- pknopf 9y ago
  Why is C king? Why not C++? The difference is just a compiler, and you can use C in C++.
  - dingo_bat 9y ago
    I don't know why. But it's true.
  - bb88 9y ago
    Here's a rant by Linus Torvalds. Take the politics and snark with a grain of salt. His technical arguments, however, are spot on. http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/linus
    - Inityx 9y ago
      I'm not sure how much water his argument here holds anymore. C++ has changed A LOT since 2007; idiomatic C++11 is an extremely different language from C++03, and C++20 is almost unrecognizable to an early C++ developer.
lpasselin 9y ago
Any progress with ti's c2000 series in rust?
- tov_objorkin 9y ago
  Oh, ti c/c+ compiler is such a joke, not event c99 supported. I was thinking about rust to C compiler [1], but thats require c11 support. 1. https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc
  - lpasselin 9y ago
    C99 is supported but it is not the default.
sureaboutthis 9y ago
I hate, hate, HATE papers or talks or anything of this nature that begin by justifying the obvious to the knowledgeable! In this case, "Why does embedded matter?" Sheesh. Then there is that law of titles with a question where the answer is always, "no". >Yes. As long as it supports your hardware and you are willing to put up with a less stable toolchain and less nature ecosystem in exchange for the safety guarantees.

164 points by blacksmythe 9y ago

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?

kibwen 9y ago

If anyone out there is an embedded developer curious about how Rust works in this space in practice, or a non-embedded developer curious about how to develop on embedded, there's a really fantastic (and free) ebook, "Discover the world of microcontrollers through Rust" (https://www.reddit.com/r/rust/comments/80doqg/discovery_discover_the_world_of_microcontrollers/ https://www.reddit.com/r/rust/comments/80doqg/discovery_disc... ), by Jorge Aparicio (the premier guru of embedded Rust development), and recently updated for 2018.

davidw 9y ago

One definition of "embedded" is: does the user treat it like an appliance or like a computer? If it's the former, it's 'embedded' even if it uses a reasonably powerful processor or does not have hard real time requirements. I use Erlang for that kind of thing and it works well. Rust is, I think, more performant, so if that works for you and what you need, go for it.

dnautics 9y ago
what do you think of nerves?
- davidw 9y ago
  I recall hearing about it a while back; looks like it has made progress? Seems worth a look!

keithnz 9y ago

I'm completely in this boat at the moment. We are doing a hardware refresh of our embedded platform and I'm looking at the feasability of using Rust. I'm at the point where I think it is close to being viable, but seems very young. Most likely we will go with a platform that can support rust, and write the low level modules with the intent of using rust, but not use Rust just yet, but do a side project to asseses the viability of doing as much of the software in Rust as we can. ( and get the devs learning Rust ). I am what I like to call a multi stack developer, so I'm super comfortable with a lot of languages and platforms, but the embedded devs I work with are microcontroller focused C devs and it will take some time to be convinced, conceptually they like the idea, but as soon as they try and write something serious they are going to feel frustrated and likely make a mess. But Rust has a LOT to offer the embedded world.

bb88 9y ago
Keep in mind that at some level, something has to be unsafe, unless you've got hard mathematical proofs that your code works as compiled.
- Sylos 9y ago
  Doesn't mean you shouldn't try to lessen the amount of code that's unsafe. That way you have at least a fighting chance at getting your unsafe code bugfree.

_sh 9y ago

Embedded developer here, ARM Cortex-M4 microcontrollers. I've been keeping an eye on Rust for the embedded space and although there has been a lot of movement in that area--particularly in the last couple of months--I'm not sure the value proposition fits the microcontroller market, where of course C is king. While Rust has much to offer as a programming paradigm in general, the main value is in the borrow-checker (the linked transcript cites 'memory bugs' as the most common class of bugs). Embedded software practitioners long ago abandoned dynamic memory allocation and with it the 'use-after-free' and 'out-of-bounds access' bugs, instead re-defining the problem as one of latency (e.g. you'll need to process that static buffer before it gets re-used by your UART interrupt). Take away the borrow-checker, and Rust looks less compelling. In time, Rust will find its niche in the embedded space, most likely occupying the high-level RPi/BBB/iMX SoC layer and perhaps working its way down to microcontrollers. As wiremine points out, it will require vendor support--moving away from your vendor's toolchain is a world of hurt that seasoned embedded developers just won't even consider. Pragmatism reigns: time-to-market and a cheap BoM are the main metrics, programming language a distant 10th.

pknopf 9y ago
Why is C king? Why not C++? The difference is just a compiler, and you can use C in C++.
- dingo_bat 9y ago
  I don't know why. But it's true.
- bb88 9y ago
  Here's a rant by Linus Torvalds. Take the politics and snark with a grain of salt. His technical arguments, however, are spot on. http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/linus
  - Inityx 9y ago
    I'm not sure how much water his argument here holds anymore. C++ has changed A LOT since 2007; idiomatic C++11 is an extremely different language from C++03, and C++20 is almost unrecognizable to an early C++ developer.

lpasselin 9y ago

Any progress with ti's c2000 series in rust?

tov_objorkin 9y ago
Oh, ti c/c+ compiler is such a joke, not event c99 supported. I was thinking about rust to C compiler [1], but thats require c11 support. 1. https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc
- lpasselin 9y ago
  C99 is supported but it is not the default.

sureaboutthis 9y ago

I hate, hate, HATE papers or talks or anything of this nature that begin by justifying the obvious to the knowledgeable! In this case, "Why does embedded matter?" Sheesh. Then there is that law of titles with a question where the answer is always, "no". >Yes. As long as it supports your hardware and you are willing to put up with a less stable toolchain and less nature ecosystem in exchange for the safety guarantees.