I would like to take a crack at rewriting the firmware in Rust to get more familiar with embedded programming + Rust. AFAICT Rust has support for the STM32F4 (and stm32f405 is used as an example for https://github.com/adamgreig/stm32-rs), though I am not sure if there is additional support needed specifically for the STM32F405RGT6 in odrive. There is a support table here: https://stm32.agg.io/rs/STM32F405.html.
Assuming Rust supports the chip, it should generally be doable? What sort of issues do you forsee? What problems generally cropped up when writing the current firmware code?
Form what I heard about it, I like Rust, but I’ve never tried it.
I think there is nothing specific that would make it not doable in Rust, but I have no idea what issues you may get, sorry. A large part of the issues that are difficult to deal with are real-time, timing and concurrency issues.
I’ve started like this, porting core ODrive algorithm to ivory-tower framework in Haskell which can be used to generate safe C-code. You can find my effort at https://github.com/distrap/lambdadrive/ (I’ve started with early version of ODriveFirmware where it was quite possible to “extract” (or reverse engingeer) the core parts of BLDC firmware. With Oscars help and bunch of time spent studying BLDC control I’ve managed to port parts of the algorithm. My port can only do voltage controlled FOC while current control is still in the works. Compared to where ODrive is/was heading lambdadrive uses CAN bus and CANOpen as a communication protocol and aims to run single motor only.
This “lets-try-to-port-this” project evolved into creating a whole RepRap like project called DistRap for distributed rapid prototyping where nodes use CAN/CANOpen for communication to allow for scalability beyond single microcontroller control boards. I’ve used ODrive as a prototyping platform and now I’m experimenting with my own set of boards based on STM32F7s. Beyond servo control I’m also working on stepper and IO nodes - the very first actually useful DistRap project is a CANOpen driven reflow oven.
I would say that implementing a complete FOC is quite difficult even when porting such code. If you decide to go for it you can start implementing parts of the algorithm and then integrate these into complete FOC. For example you can easily drive BLDC with only advanced timer in 6PWM mode. Add DRV8301 SPI driver and you can test on actual ODrive board. The rest is way harder though and involves encoder, clarke/parke transforms and SVM.
While doing this I’ve realized that this little-known frawework has tons of potential (even compared to the embedded rust) so I’m currently writing book about it and adding a support for whole STM32 family. Sorry for hijacking this thread a bit, I really need to start my own blog|thread :).
Interesting! That is…more ambitious than what I am doing. My plan is to rewrite bits and pieces in Rust and keeping the rest in C, slowly converting everything in place. Rust interoperates well with C.
I really want to help with the firmware but can’t stand the lack of tests, having to edit source files to change defines, no option type, etc. Rust is just more pleasant for me to code in for fun and might encourage more contributions
