Can i migrate from C to rust for pic18, esp32, rp2040 and PC targets?

[cedric!]

I'm using C to make programs for various microcontrollers (pic18, esp32, rp2040). While developing these programs, I also run this microcontroller C code on a PC by stubbing out all the microcontroller specific functions. On the PC i then setup scenario's, run the microcontroller code, and check with the  C test framework unity[1] if the microcontroller C code has run correctly.

I also run the C code natively in the microcontrollers. Then I use a debugger to set breakpoints, and to inspect the internal state of the program. The debugger also decodes the memory, so I can see what the peripherals are doing.

Finally I use a CICD script to first run a testsuite on a server, and then compile the microcontroller code.

This all works fine, but C has some disadvantages compared to rust. (like memory safety and so on).

Therefore I would like to migrate from C to rust. Is this feasible?

A)Does rust have a compiler for all my microcontrollers?
B)Does rust have a debugger for all my microcontrollers?

[1] https://www.throwtheswitch.org/unity

[Siwastaja]

Rust does not even have a standard. Memory safety is an attitude, not a language feature. You are looking for a silver bullet which does not exist.

[SiliconWizard]

Not just that, but the time invested to start doing (and keep doing) anything useful will never pay for itself. Invest just 1/4 of that time to improve your tooling and the way you approach software design and you'll be way better off IMO.

But yes, we're right into yet another wave of silver bullets, like C++ was supposed to be, then Java, then Agile stuff, you name it.

Now that's just a couple people's opinions here. If you're serious about making that "switch", by all means, try it. See for yourself and come back in a few months with your results. That will speak more loudly whatever your outcome is than any hype on social media or from politics (since yes, even politics got involved lately.)

[hans]

PIC18 has a proprietary compiler. It doesn't even support C99 properly. Archiac stuff.

ESP32 has some variants, and there is Rust tooling for it. However the cargo crates (libraries) are community built and don't support all features yet. E.g. WiFi works but Bluetooth is still unsupported. The reason being those protocol stacks need to be ported over.

RP2040 is "just" another ARM Cortex chip so I would expect that to just work. However the RP2040 board with WiFi also uses some extensive protocol stack, so not sure if thats supported yet.

So certainly Rust is gaining some traction. But these are mostly stories I've heard from my brother in law that wrote firmware for some hobby project we did together.
I haven't seen him using a debugger for anything, but thats probably something to do because I didn't supply him with a JTAG cable. (he normally writes website backends, so is with printf-debugging)

[baldurn]

Don't mind the people above that are stuck in the C era and who don't want to learn anything new. Besides memory safety, fearless concurrency is super relevant for MCU programming.

The rust tooling can do everything that you asked, including debugging, conditional compiling and testing.

The PIC is probably not supported but the other MCUs are.

Embedded Rust is not fully mature, which you will primarily feel by that the libraries for MCUs differ widely and there might be frequent API changes. On the other hand C does not have a standard either.

[cedric!]

PIC18 has a proprietary compiler. It doesn't even support C99 properly. Archiac stuff.

Agreed. It's also the microcontroller my employer has chosen for some reason. As far as I can tell there's also no open source compiler for it, as the pic18 line of SDCC isn't maintained anymore [1]
[1] https://sdcc.sourceforge.net/

Rust uses the LLVM framework. LLVM doesn't support pic16 anymore [2], and as far as I can see it doesn't pic 18. So rust is impossible until that changes.
[2] https://discourse.llvm.org/t/pic16-removal-details/20754

ESP32 has some variants, and there is Rust tooling for it. However the cargo crates (libraries) are community built and don't support all features yet. E.g. WiFi works but Bluetooth is still unsupported. The reason being those protocol stacks need to be ported over.

Yes As far as I know the ESP32 IDF is released under the Apache-2.0 license, so there's nothing stopping somebody to port it to rust.

RP2040 is "just" another ARM Cortex chip so I would expect that to just work. However the RP2040 board with WiFi also uses some extensive protocol stack, so not sure if that's supported yet.

Here's [3] some guy detailing debugging using one RP2040 to debug another RP2040 running a rust program. The RP2040 crate [4] doesn't mention wifi nor buetooth
[3] https://reltech.substack.com/p/getting-started-with-rust-on-a-raspberry
[4] https://docs.rs/rp2040/latest/rp2040/

So certainly Rust is gaining some traction. But these are mostly stories I've heard from my brother in law that wrote firmware for some hobby project we did together.
I haven't seen him using a debugger for anything, but thats probably something to do because I didn't supply him with a JTAG cable. (he normally writes website backends, so is with printf-debugging)

I'm not smart enough to debug a program without a debugger. That's why I ported the microcontroller programs I write to C++QT, so i can debug them on a PC. This has the drawback that the code is running on a "dead" microcontroller, but it's surprising how little hardware has to be simulated to be able to inspect the logic of the program.

[cedric!]

Don't mind the people above that are stuck in the C era and who don't want to learn anything new. Besides memory safety, fearless concurrency is super relevant for MCU programming.

The rust tooling can do everything that you asked, including debugging, conditional compiling and testing.

The PIC is probably not supported but the other MCUs are.

Embedded Rust is not fully mature, which you will primarily feel by that the libraries for MCUs differ widely and there might be frequent API changes. On the other hand C does not have a standard either.

In my microcontroller I don't use any libraries. Every driver and abstraction layer is my own, so that has to be recreated anyway. I can't say I'm smart enough yet to keep my own API's stable.

The PIC18 not being supported is a showstopper, and I guess that's a very big task.

[dobsonr741]

My problem with Rust on MCU is the excess use of unwrap(), in a way that  it completely ignores the value Optionals intended to bring.

[Rick Law]

... ...
But yes, we're right into yet another wave of silver bullets, like C++ was supposed to be, then Java, then Agile stuff, you name it.
... ...

AI will be the next wave of silver bullet.  You merely have to tell the AI system blah blah blah and out comes a ready to run binary that you can install...

[uliano]

My problem with Rust on MCU is the excess use of unwrap(), in a way that  it completely ignores the value Optionals intended to bring.

What is the alternative? pop up a message to the user?

At least you get a panic and don't keep goin' on with uninitialized stuff.