I'm intrigued by the potential for rust in the embedded space. As
a platform for experimentation, I purchased an STM32 F4 discovery
board. I chose the F4 model to match the CPU on typical racing
drone flight controllers without realising the higher level of
support for the corresponding F3 discovery board.
I was initially running svd2rust for the STM32F407 device, but I've
subsequently found the STM32F4 support in the generic stm32-rs crate
and I've got to the stage where I've got trivial demos working. I'm
now starting to look at the HAL layer, amd I'm unsure which way to
go. I noticed that the stm32f429-hal crate exists, but it's a fork of
the stm32f30x-hal crate, and it's not clear to what extent the forked
features work or have been tested.
I'm tempted to create a new hal crate of my own, which will start
empty and into which I will incrementally port and test features from
the stm32f30x-hal.
Thoughts? Is this a reasonably approach? I'm impressed with the
svd2rust tooling to automate low level API generation, but it seems
there's still a lot of work required to get embedded_hal support for
an unsupported device.
I think your approach sounds reasonable, at least for now. Maybe it's worth asking the author of the HAL you were looking at how well-tested those forked parts are.
I think it would be ideal if there was a coordinated effort to provide HAL-level support for STM32 microcontrollers in general, basically what Adam is doing but one abstraction level higher (we recently started such an effort for Nordic chips). I'm not very familiar with STM32, but from what I've heard, there are enough differences to make this very difficult. So it's understandable that people generally start their own HALs instead, forking and stealing bits from other HAL as applicable.
@timbod Sorry for the late reply. I've actually started working on a universal STM32F4 HAL implementation and published the current (early) work here: https://crates.io/crates/stm32f4xx-hal
Currently it supports STM32F407 and STM32F429 with a number of features (clock setup, GPIO, partially (not all available combinations instantiated) Serial and I2C)). The goal here is to support all MCUs of the STM32F4 in one crate since they mostly differ in available peripherals, pin mapping and memory which can all be selected using feature gates and a custom memory.x in the crate using it.
Please have a look, let me know what you think. It's in the early stages but I've also written 2 board support crates for the STM32F4 DISCOVERY (STM32F407) and STM32F429I DISCOVERY (STM32F429) using it and providing some examples as a proof of concept which I'm going to release soon, too.
Any feedback and of course PRs are quite welcome.
Things that will need doing include setting up CI, fixing bugs (e.g. I2C is a bit shaky at higher clock speeds and surprisingly slow; need to check with an oscilloscope later), providing more functionality and the missing peripheral mappings, refactoring of duplicated code into macros, etc...
@hannobraun Actually the chips within one family are quite familiar, however STM currently has 12 main families (and within those there're tons of individual peripherals) so the jobs is still somewhat tedious. I'm trying to get the ball rolling with the STM32F4 family (although I do have more interest in other families, this one is the series where I have the most different boards with Ethernet support which I'm quite interested in ).
Unfortunately this does not cover the STM32F3 family but IIRC the peripheral interface is quite different from the STM32F4 (I do have some STM32F3 equipment here but I've never worked with that family so far)...
This looks great - thanks so much for the follow up post.
Assuming you are ok with this, I'll add a link to your stm23f4xx-hal at
I'm keen to contribute (at least once I come up to speed in this environment), and your project looks like the suitably general framework in which to do this.
).