Stm32f04x additions for RCC

[bentwire]

Please review. There are some leftovers from debugging still around, I will remove them.

I'm not quite sure how to do the feature flags for the clock builder, I could really use some help there, not sure how to set the code up. It is why I added flags to the RCC struct that I have not used yet...

Thanks!

Mike

[bentwire]

Oh I also have some code I modified from https://github.com/ah-/anne-key to work with the USB on the stm32f072, but I don't know if this is the correct crate for it, or if it should go in to a "usb-hal" crate with the code I have been messing with here: https://github.com/bentwire/stm32f072-usb

[david-sawatzke]

Your comments are quite inconsistent, especially the capitalization

[david-sawatzke]

Yeah, adding 072 support should be a separate PR. Having this as a feature while providing no functionality is quite misleading

[therealprof]

Hi @bentwire. Thanks a lot for your contribution. Additional clocking support is highly welcome, especially since this is the most tricky part of MCU programming. From your other comment I gather that you would like to enable USB support which would be fantastic feat! Is there any other use case you had in mind for it?

[bentwire]

Hi @bentwire. Thanks a lot for your contribution. Additional clocking support is highly welcome, especially since this is the most tricky part of MCU programming. From your other comment I gather that you would like to enable USB support which would be fantastic feat! Is there any other use case you had in mind for it?

Yeah I am attempting to get USB working, that is my main goal, basically I want to move from C to Rust for my STM32 based board designs. It is a hit and miss thing at the moment, ST's example code is all over the place, and the rust code I am working from is for a chip that is "just different enough" that it won't work as is :/

Thankfully though I have a Beagle 12 and a Nucleo-F072RB to test with.

Has anyone come up with a usb-hal yet?

[therealprof]

Yeah I am attempting to get USB working, that is my main goal, basically I want to move from C to Rust for my STM32 based board designs.

Fantastic. I started from the same spot just a year ago. USB is still on my bucket list, I made a secret santa project with could hugely benefit from USB on the STM32F042...

It is a hit and miss thing at the moment, ST's example code is all over the place, and the rust code I am working from is for a chip that is "just different enough" that it won't work as is :/

Well, as usual that depends where you're coming from; if you're a heavy HAL/LL user and know everything inside out then Rust might still look a bit pedestrian. If you're coming an RTOS which only has partial support then Rust could even have a very charming appeal.

Has anyone come up with a usb-hal yet?

There's something for the STM32F103: https://github.com/mvirkkunen/stm32f103xx-usb . From what I hear USB seems quite similar for a lot of STM32 chips and a lot of the descriptor stuff is independent of the hardware anyway so it might be possible to crate a common driver.

[bentwire]

It is a hit and miss thing at the moment, ST's example code is all over the place, and the rust code I am working from is for a chip that is "just different enough" that it won't work as is :/

Well, as usual that depends where you're coming from; if you're a heavy HAL/LL user and know everything inside out then Rust might still look a bit pedestrian. If you're coming an RTOS which only has partial support then Rust could even have a very charming appeal.

All of my STM32 code to date has been in C/C++, Lua, or ASM, bare metal (or STM's CubeMX-HAL), no RTOS. RTFM Looks very very nice to me from that perspective. I mainly came to Rust because I liked the compile time checks. Then I started coding in it, it is quite nice. :) I'm still learning quite a bit about the language though so please excuse some of my noobish mistakes.

There's something for the STM32F103: https://github.com/mvirkkunen/stm32f103xx-usb . From what I hear USB seems quite similar for a lot of STM32 chips and a lot of the descriptor stuff is independent of the hardware anyway so it might be possible to crate a common driver.

I will have to take a look at that. Yeah they are mostly similar, the 103 chip is one of the first gen to have USB so I think it may be quite different from the 042/072, the code I was starting with was for a l151 I believe which has a similar USB core, but for some reason the packet memory area is not accessed the same. According to the code the l151 packet area is only accessible as u16 on u32 boundaries (IE every other u16 is a valid memory location) and is 512 bytes, where as the 042/072 has a byte accessible PMA that is 1024 bytes wide. At least that is what the RM says... I am starting to think what the RM has for the 042/072 is wrong (it says it is u8 or u16 accessible) because I changed the PMA code to be u8 based instead of u16 and now things broke...

For reference See Page 887

[therealprof]

Then I started coding in it, it is quite nice. :) I'm still learning quite a bit about the language though so please excuse some of my noobish mistakes.

No worries. We all have to start somewhere. I'm also still learning a lot. ;)

I will have to take a look at that.

I believe People are already in the process of supporting other families, too. Most of us are hanging our on IRC in #rust-embedded and discussing things like USB on STM32.

[bentwire]

Was this ok to merge or did you want me to make more changes?

[therealprof]

Please rename this to HSI_DIV2 to clarify what it means

[therealprof]

It's adding 16 bytes of binary bloat to all applications but other than that looks great.

[therealprof]

Please address the nit and resolve the merge conflict, then this is good to go.

[bentwire]

I believe it should be good to go now.

Thanks!

[therealprof]

LGTM, thanks!