-
Notifications
You must be signed in to change notification settings - Fork 215
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add STM32H7Rx/Sx #972
base: master
Are you sure you want to change the base?
Add STM32H7Rx/Sx #972
Conversation
just delete all those enums with "_clear_fields" stm32-rs/devices/stm32g071.yaml Line 6 in bc29551
|
Thanks, that seems like the best option. Any opinion on where they belong (in STM32H7 or a separate family)? |
I think keeping them in the stm32h7 crate is probably best, we also kept the stm32l4+ in the l4 crate and I think it's a similar distinction. It doesn't really matter what they have in common as nothing is shared between devices in a crate anyway; it's just about keeping each crate a reasonable size and having things where people expect to find them. |
As far as I can see, ST uses the same cube package and hal for L4 and L4+, so it's slightly different for these chips. But I'm perfectly fine with keeping them in the stm32h7 crate. I guess we can always split them off later if necessary? |
The "compare mmaps" step will continue to fail because of the new SVD files, I guess? |
Yep, for security reasons it can only run on the SVD files already present in the repository. Do you think this is otherwise ready for review? Have you been able to test it at all? |
|
It's definitely not perfect yet, but I hope it is a good enough starting point to be mergeable. I don't expect big issues with getting something to run, but maybe those are famous last words 😅 |
A simple blinky works. @adamgreig, is there anything you would like to see checked or tested in particular or are you okay with merging this now and then fixing potential issues in a follow-up PR? |
Thanks, looks good. The only thing I wanted to double check is deriving all the GPIOs from GPIOA. Typically GPIOA (and B) have a different reset value for MODER, OSPEEDR, and PUPDR than the other ports because of the JTAG/SWD pins there. IF everything derives from GPIOA, doing something like |
You are correct, that is indeed the case (the different reset value), I didn't know it mattered. |
I was looking into this and comparing with the other STM32H7 devices. I propose to fix this for the entire family, but maybe that should be a separate PR? |
I created #973 to fix the issue for the current STM32H7 devices. |
I'd like to add support for these newly released devices.
However, I am unsure if they should be added to the STM32H7 family or added as a separate family.
On their site, ST lists them under the "STM32H7" category, but for the rest they seem to treat them like a new family (with a separate Cube package and HAL).
What do you think?
One annoying thing about these new SVD's, is that they tend to use the bit position of a field as the name.
Example
I'm not sure how to solve this without manually overwriting the values with meaningful names.