←back to thread

205 points michidk | 1 comments | | HN request time: 0.202s | source
Show context
myrmidon ◴[] No.41835579[source]
A very important point that the article neglects is that for a lot of embedded platforms, you have to heavily rely on the hardware manufacturers libraries and tooling. All of that stuff is typically gonna be targeted at C.

Without this, using even very simple hardware interfaces (like an SPI/I2C bus) is gonna be a huge pain, because you'll have to comb through reference manuals and register descriptions for your processor and piece everything together yourself instead of just calling a few API functions (this is also very error-prone and using Rust is not really gonna help one bit).

The only chance to get even halfway decent rust integration is to pick one of the like 3 most popular hardware platforms among hobby enthusiasts (think ESP32, raspberry pico), which is simply not viable for a LOT of embedded applications.

So I still think its probably a really bad idea for a typical embedded-shop to fully go for rust right now-- the downsides from lacking tooling/libraries, reduced developer pool and the need to train extant devs appear very hard to overcome to me.

replies(7): >>41835630 #>>41835713 #>>41836762 #>>41836918 #>>41838862 #>>41839785 #>>41841075 #
1. vvanders ◴[] No.41838862[source]
Even with the vendor libraries last time I had to poke at a CAN bus I ended up having to go to that same level because the C helper libraries omitted key features of the interface.

There's a number of micros these days where the same libraries are provided using SVD[1] that will generate interfaces which is handy.

[1] https://docs.rs/svd2rust/latest/svd2rust/