-
Notifications
You must be signed in to change notification settings - Fork 67
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
Implement all SPI pins for STM32F303 #99
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for this PR! :) I left some comments, while checking against the reference manual (RM0316) and the datasheets of the devices (as they contain the alternate function mappings).
Regarding this section out of the reference manual:
On STM32F303x6/8 and STM32F328x8 devices, only SPI1 is available.
You did not really touch that code, but if you are already at it, you could make sure, that no SPI2+ is exposed to these devices, if you want.
I'm fine, if that means #[cfg(not(any(feature = "stm32f303x6", "stm32f303x8", ...)))]
for now, if you haven't got the time to recheck against all devices.
Also, I would be happy about a CHANGELOG entry :) |
Speaking of changelog entries... I can't seem to find any reference to STM32F301xB/C/D/E anywhere, only to STM32F301x6/8. The crate only lists the former, and not the latter. I'll probably just end up ignoring the 301 series for this PR, but I might come back to it in the future. Could also be worth opening an issue to reconcile the 301 crate features with the datasheets. |
I recently added the STM32F302xB/C/D/E as targets, because they where missing, so it's fine to add missing devices. But it seems like, that STM32F301xB/C/D/E devices do not exsist? At least they are not listed on st.com |
That's what I found too. So I think I'll just not touch the 301 series in this PR, but I'll go ahead and update the rest. |
28985e3
to
5fef9f5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your work and detailed commits. Sorry for the late review, I'll hope this is ok :)
LGTM. The missing stm32f302x[6,8]
features can be split out into another PR. Without adding these this is still a big improvement on the SPI situation!
Merge! |
Based on the datasheets for the 303x6/8, 303xb/c, and 303xd/e, the following pins and peripherals are supported: - SPI1 (6/8, b/c, and d/e): - SCK: PA5<AF5>, PB3<AF5> - MISO: PA6<AF5>, PB4<AF5> - MOSI: PA7<AF5>, PB5<AF5> - SPI2 (b/c and d/e): - SCK: PB13<AF5>, PF9<AF5>, PF10<AF5> - MISO: PB14<AF5> - MOSI: PB15<AF5> - Additional SPI2 Pin options (d/e only): - SCK: PF1<AF5> - MISO: PA10<AF5> - MOSI: PA11<AF5> - SPI3 (b/c and d/e): - SCK: PC10<AF6> - MISO: PC11<AF6> - MOSI: PC12<AF6> - Additional SPI3 Pin options (d/e only): - SCK: PB3<AF6> - MISO: PB4<AF6> - MOSI: PB5<AF6> - SPI4 (d/e only): - SCK: PE2<AF5>, PE12<AF5> - MISO: PE5<AF5>, PE13<AF5> - MOSI: PE6<AF5>, PE14<AF5>
I rebased it onto master and resolved the Changelog issue. |
Based on the datasheets for the 302x6/8, 302xb/c, and 302xd/e, the following pins and peripherals are supported: - SPI1 (b/c, and d/e): - SCK: PA5<AF5>, PB3<AF5> - MISO: PA6<AF5>, PB4<AF5> - MOSI: PA7<AF5>, PB5<AF5> - SPI2 (6/8, b/c and d/e): - SCK: PB13<AF5> - MISO: PB14<AF5> - MOSI: PB15<AF5> - Additional SPI2 Pin options (6/8 and d/e): - SCK: PF1<AF5> - MISO: PA10<AF5> - MOSI: PA11<AF5> - Additional SPI2 Pin options (b/c and d/e): - SCK: PF9<AF5>, PF10<AF5> - SPI3 (6/8, b/c and d/e): - SCK: PB3<AF6>, PC10<AF6> - MISO: PB4<AF6>, PC11<AF6> - MOSI: PB5<AF6>, PC12<AF6> - SPI4 (d/e only): - SCK: PE2<AF5>, PE12<AF5> - MISO: PE5<AF5>, PE13<AF5> - MOSI: PE6<AF5>, PE14<AF5> Note that this HAL doesn't currently have features for the 302x6/8 processors, so those peripherals aren't usable at the moment.
Based on the datasheet, the following pins and peripherals are supported: - SPI2: - SCK: PB13<AF5>, PF1<AF5> - MISO: PA10<AF5>, PB14<AF5> - MOSI: PA11<AF5>, PB15<AF5> - SPI3: - SCK: PB3<AF6> - MISO: PB4<AF6> - MOSI: PB5<AF6>
Based on the datasheet, the following pins and peripherals are supported: - SPI1: - SCK: PA5<AF5>, PB3<AF5> - MISO: PA6<AF5>, PB4<AF5> - MOSI: PA7<AF5>, PB5<AF5>
Based on the datasheet, the following pins and peripherals are supported: - SPI1: - SCK: PA5<AF5>, PB3<AF5> - MISO: PA6<AF5>, PB4<AF5> - MOSI: PA7<AF5>, PB5<AF5> - SPI2: - SCK: PB13<AF5>, PF9<AF5>, PF10<AF5> - MISO: PB14<AF5> - MOSI: PB15<AF5> - SPI3: - SCK: PC10<AF6> - MISO: PC11<AF6> - MOSI: PC12<AF6>
Based on the datasheets for the 373 and 378, the following pins and peripherals are supported on both processors: - SPI1: - SCK: PA5<AF5>, PA12<AF6>, PB3<AF5>, PC7<AF5> - MISO: PA6<AF5>, PA13<AF6>, PB4<AF5>, PC8<AF5> - MOSI: PA7<AF5>, PB0<AF5>, PB5<AF5>, PC9<AF5>, PF6<AF5> - SPI2: - SCK: PA8<AF5>, PB8<AF5>, PB10<AF5>, PD7<AF5>, PD8<AF5> - MISO: PA9<AF5>, PB14<AF5>, PC2<AF5>, PD3<AF5> - MOSI: PA10<AF5>, PB15<AF5>, PC3<AF5>, PD4<AF5> - SPI3: - SCK: PA1<AF6>, PB3<AF6>, PC10<AF6> - MISO: PA2<AF6>, PB4<AF6>, PC11<AF6> - MOSI: PA3<AF6>, PB5<AF6>, PC12<AF6>
Based on the datasheet, the following pins and peripherals are supported: - SPI1: - SCK: PA5<AF5>, PB3<AF5> - MISO: PA6<AF5>, PB4<AF5> - MOSI: PA7<AF5>, PB5<AF5> - SPI2: - SCK: PB13<AF5>, PF1<AF5>, PF9<AF5>, PF10<AF5> - MISO: PA10<AF5>, PB14<AF5> - MOSI: PA11<AF5>, PB15<AF5> - SPI3: - SCK: PB3<AF6>, PC10<AF6> - MISO: PB4<AF6>, PC11<AF6> - MOSI: PB5<AF6>, PC12<AF6> - SPI4: - SCK: PE2<AF5>, PE12<AF5> - MISO: PE5<AF5>, PE13<AF5> - MOSI: PE6<AF5>, PE14<AF5>
Based on the datasheet, the following pins and peripherals are supported: - SPI1: - SCK: PA5<AF5>, PB3<AF5> - MISO: PA6<AF5>, PB4<AF5> - MOSI: PA7<AF5>, PB5<AF5>
I needed to use PB3 as SPI1 SCK for a project, and noticed that it was in the HAL, but commented out. I went through the datasheet for the STM32F303xD/E and saw no reason why it needed to be excluded, and, indeed, my program does work using it.
While I was at it, I figured I could update the rest of the SPI HAL to allow all of the pins that the chip does. If this is the right approach, I wouldn't mind doing the same type of update for the rest of the supported chips. I could add on to this PR, or make those additions in a later (or multiple later) PRs, whichever works better for you.