6 ms·

I'm fortunate enough to have just landed on a new team working with embedded Rust. Here are some of my takes, in no particular order. The language and ecosyste

I'm fortunate enough to have just landed on a new team working with embedded Rust. Here are some of my takes, in no particular order. The language and ecosystem have come a long way in a very short time. It's easy to use safe `no_std` Rust on the stable toolchain for 98% of your code, and there are crates available for all kinds of things like memory management, register access, or even async runtimes. Compared with C, Rust is absolutely a game changer in terms of reliability/safety/productivity. Every line of C code is a potential liability, because humans make mistakes. Having a compiler that smacks me down is invaluable; it results in a safer and more reliable program, and it helps me get it right the first time. Like many others, my experience with Rust is nearly always "if it compiles, it works". This is _especially_ valuable for embedded programming, because debugging is often way harder when working with hardware. One major drawback is lack of support/engagement from hardware vendors. They pretty much assume you are using C, and all of their IDEs/SDKs/codegen tools/whatever are written with that assumption. This probably isn't going to change any time soon (ever?). What this means is that if you want to use Rust, you'll be on the hook for figuring out a lot of low-level things like linker scripts, boot sequence, or memory/clock initialization. Often this means reading or reverse-engineering the vendor's SDK to figure out how these work. If you're working at a big company on a serious product, you might have done this anyways. But for a hobbyist, this can be a huge barrier.

b20000 4y ago
so what you are saying, is that rust solves the issue of finding competent engineers. you can use a language like rust such that engineers don’t need to be any good. it reminds me of microsoft frontpage and all the other scripting languages and tools that have been created to solve this issue. but here we are in 2022 and nothing has changed. people still hand code css and html to get what they want. embedded software engineering is about understanding the hardware and leveraging its power through good architecture and smart thinking and understanding what the code you write will do. you can’t shortcut this by using a new programming language that does the work for you. you will still need to understand the low level details. so, learn C++ and familiarize yourself with the related embedded standards for reliability and safety. adding rust into the mix will now require you to maintain code in not one but multiple languages as you cannot get around C or C++ and possibly assembly. it’s already complicated enough as it is, and you should focus on understanding the principles instead of learning another set of syntax and implicit logic.
- crest 4y ago
  I take something very different from the grand-parent post: the language requires you to get the design mostly correct to even compile. Unexperienced developers won't be able to come up any non-trivial new designs of their own, but can reuse existing code and even experienced developers have to fight the language to get a prototype stood up, but once they've working code it's more reliable. Not every line of code could accidentally reconfigure your PLL or voltage regulator just enough to drive you insane debugging a glitching chip.
- cogman10 4y ago
  I don't think that's what GP was saying at all. The issue they bring up in more that hardware manufactures will have things like #define BLINKY_LIGHT_ADDR 0xDEADBEEF in a standard set of headers distributed with their toolkit. That magic address is where you write to turn a light on or off. Now, they will almost certainly also define that sort of thing in a datasheet, somewhere, but for the average embedded dev it's far simpler to pull in the SDK and use that. This isn't some sort of "good programmer bad programmer" filter. This is a "I don't want to read a 40 page pdf of a datasheet to find out what you named light 1 and where that address is"
  - bsder 4y ago
    It's worse than that. Something like your Bluetooth communication is dependent upon a C-based "communications stack" that demands to control the event loop and all the registers aren't even documented. "Where is the LED?" is easy to work around. "How do I put my BLE system into low power advertising mode?" may not even be possible without accessing the C library.
    - cogman10 4y ago
      Ah, good point. That would be rather tricky to solve.
    - steveklabnik 4y ago
      That’s a fun example, because while you’re right, that may also be changing. Android’s new Bluetooth stack is in Rust, in my understanding. We’ll see if more vendors provide even more stuff in Rust in the future!
cogman10 4y ago
> One major drawback is lack of support/engagement from hardware vendors. They pretty much assume you are using C, and all of their IDEs/SDKs/codegen tools/whatever are written with that assumption. This probably isn't going to change any time soon (ever?). My assumption is that with the advent of rust getting into gcc, you will see at least some of these changes starting to make their way into toolchains. Probably not for the MSP430, but possibly for the next generation of embedded chips.
P_I_Staker 4y ago
Is rust interoperable with C and ASM? I would think it'd have to be. Some of those things (all of them?) are considerations the system designer needs to worry about regardless. It seems like you should be able to still use most of the stuff provided by the toolchain in a similar fashion. That said, trying to do a native implementation by porting the code, or just using a C/ASM bootloader could prove tricky for newcomers. Bootloaders are often black boxes. It could be flashing something written in COBAL, and it would be none the wiser. It seems like rust would need to provide a mechanism for entry pointing. I don't know how to handle memory mapping and linker scripting in rust. I'm not disagreeing that it could be a huge barrier, but theoretically it doesn't have to be that much, or at least most of it is stuff you'll often be dealing with anyway.

b20000 4y ago

so what you are saying, is that rust solves the issue of finding competent engineers. you can use a language like rust such that engineers don’t need to be any good. it reminds me of microsoft frontpage and all the other scripting languages and tools that have been created to solve this issue. but here we are in 2022 and nothing has changed. people still hand code css and html to get what they want. embedded software engineering is about understanding the hardware and leveraging its power through good architecture and smart thinking and understanding what the code you write will do. you can’t shortcut this by using a new programming language that does the work for you. you will still need to understand the low level details. so, learn C++ and familiarize yourself with the related embedded standards for reliability and safety. adding rust into the mix will now require you to maintain code in not one but multiple languages as you cannot get around C or C++ and possibly assembly. it’s already complicated enough as it is, and you should focus on understanding the principles instead of learning another set of syntax and implicit logic.

crest 4y ago
I take something very different from the grand-parent post: the language requires you to get the design mostly correct to even compile. Unexperienced developers won't be able to come up any non-trivial new designs of their own, but can reuse existing code and even experienced developers have to fight the language to get a prototype stood up, but once they've working code it's more reliable. Not every line of code could accidentally reconfigure your PLL or voltage regulator just enough to drive you insane debugging a glitching chip.
cogman10 4y ago
I don't think that's what GP was saying at all. The issue they bring up in more that hardware manufactures will have things like #define BLINKY_LIGHT_ADDR 0xDEADBEEF in a standard set of headers distributed with their toolkit. That magic address is where you write to turn a light on or off. Now, they will almost certainly also define that sort of thing in a datasheet, somewhere, but for the average embedded dev it's far simpler to pull in the SDK and use that. This isn't some sort of "good programmer bad programmer" filter. This is a "I don't want to read a 40 page pdf of a datasheet to find out what you named light 1 and where that address is"
- bsder 4y ago
  It's worse than that. Something like your Bluetooth communication is dependent upon a C-based "communications stack" that demands to control the event loop and all the registers aren't even documented. "Where is the LED?" is easy to work around. "How do I put my BLE system into low power advertising mode?" may not even be possible without accessing the C library.
  - cogman10 4y ago
    Ah, good point. That would be rather tricky to solve.
  - steveklabnik 4y ago
    That’s a fun example, because while you’re right, that may also be changing. Android’s new Bluetooth stack is in Rust, in my understanding. We’ll see if more vendors provide even more stuff in Rust in the future!

cogman10 4y ago

> One major drawback is lack of support/engagement from hardware vendors. They pretty much assume you are using C, and all of their IDEs/SDKs/codegen tools/whatever are written with that assumption. This probably isn't going to change any time soon (ever?). My assumption is that with the advent of rust getting into gcc, you will see at least some of these changes starting to make their way into toolchains. Probably not for the MSP430, but possibly for the next generation of embedded chips.

P_I_Staker 4y ago

Is rust interoperable with C and ASM? I would think it'd have to be. Some of those things (all of them?) are considerations the system designer needs to worry about regardless. It seems like you should be able to still use most of the stuff provided by the toolchain in a similar fashion. That said, trying to do a native implementation by porting the code, or just using a C/ASM bootloader could prove tricky for newcomers. Bootloaders are often black boxes. It could be flashing something written in COBAL, and it would be none the wiser. It seems like rust would need to provide a mechanism for entry pointing. I don't know how to handle memory mapping and linker scripting in rust. I'm not disagreeing that it could be a huge barrier, but theoretically it doesn't have to be that much, or at least most of it is stuff you'll often be dealing with anyway.