You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm working on a open-source project that targets an stm32f205(rgt6, fwiw) in an application where memory safety is paramount. I'd really love to go full-Rust instead of some hybrid C-bootstrap-plus-Rust type of thing, and you guys have helpfully provided a PAC for the f2 family. Unfortunately, though, there's no proper HAL.
So far I've been giving it a good old college try on a fork of stm32f1xx-hal, using AN3427 as guidance to update it for the F2 series. I think I got the RCC changes done, but I'm finally realizing that the F1's AFIO is gone in F2 and maybe I should have started with F4 instead even though there's no handy application note for that.
Anyhow, it seems like I should probably ask the experts at this point. How hard actually is cooking up a HAL for the F2? Is doing so something anyone else has an interest in? Would a potential collaboration be in order?
My budget's not unlimited -- especially given that I still have to convince the rest of my team that Rust is the way to go here -- but it's possible that I'd be able to swing an arrangement to sponsor someone to do the port. Is that something anyone might be interested in?
(For context, my particular project needs the RCC (there's an external 8MHz crystal, and the CSS would be nice), the OTG_FS peripheral in device mode, and GPIO for some inputs, a couple of LEDs, and some bit-banging I have to do to drive an OLED screen. That's about it, though -- No USART/SPI/I2C/I2S or Ethernet or CRC/crypto/hash accel or anything fancy.)
The text was updated successfully, but these errors were encountered:
I think you could probably get very far just copying bits from the F4 HAL, which I think is mostly very similar to the F2. Some parts might be better from the F1. Given you only need a few simple peripherals, it might be easier to just write your own simple HAL using the PAC that directly covers your application needs. The USB part will most likely work out-the-box with https://github.com/stm32-rs/synopsys-usb-otg though you'll need to get the clock settings in RCC correct.
In my experience the F2 is a fairly rare device that I haven't seen many people use, so I don't know how many other users or collaborators might be lurking, but you never know...
It appears to be largely copied from F4 HAL but is still a work in progress. Not sure how active development is.
I'd be open to collaborating on an F2 HAL, however I wonder if this project needs to consider a common HAL, or at least a common one for F-series. Feels like maintainability is difficult with all the different HALs when some peripherals are the exact same. It seems like there is some inertia towards this with stm32-fmc, stm32-eth, and the USB crates.
I'm working on a open-source project that targets an stm32f205(rgt6, fwiw) in an application where memory safety is paramount. I'd really love to go full-Rust instead of some hybrid C-bootstrap-plus-Rust type of thing, and you guys have helpfully provided a PAC for the f2 family. Unfortunately, though, there's no proper HAL.
So far I've been giving it a good old college try on a fork of stm32f1xx-hal, using AN3427 as guidance to update it for the F2 series. I think I got the RCC changes done, but I'm finally realizing that the F1's AFIO is gone in F2 and maybe I should have started with F4 instead even though there's no handy application note for that.
Anyhow, it seems like I should probably ask the experts at this point. How hard actually is cooking up a HAL for the F2? Is doing so something anyone else has an interest in? Would a potential collaboration be in order?
My budget's not unlimited -- especially given that I still have to convince the rest of my team that Rust is the way to go here -- but it's possible that I'd be able to swing an arrangement to sponsor someone to do the port. Is that something anyone might be interested in?
(For context, my particular project needs the RCC (there's an external 8MHz crystal, and the CSS would be nice), the OTG_FS peripheral in device mode, and GPIO for some inputs, a couple of LEDs, and some bit-banging I have to do to drive an OLED screen. That's about it, though -- No USART/SPI/I2C/I2S or Ethernet or CRC/crypto/hash accel or anything fancy.)
The text was updated successfully, but these errors were encountered: