-
Notifications
You must be signed in to change notification settings - Fork 4
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 MCU support for STM32F437 (and friends) #2
Comments
Commit cd9a345 imports the MCU definitions that I created for the STM32F40x and STM32F42x that are used in the Discovery-STM32F4 and Nucleo-F429zi boards. I don't know that these two MCUs really need to be separate, and I'm not sure how different they are from the STM32F437. The MCU crates build successfully but I haven't had a chance to test them on real boards yet. The main work that needs to be done on them is:
Once that's done, it should be easy to add board definitions for the Discovery and Nucleo. A bigger task is to refactor more of the peripherals to put them into the stm32-common crate, but that should be it's own issue. Also, I should start looking into doing per-variant peripheral overrides so that we can enable / disable peripherals and/or fields. I don't want to go too far with this (it's not too big a deal to maintain a separate MCU definition) but there are a lot of variants that simply have a different number of peripherals. |
There are some differences between the 40x and the 42x, specifically with regard to flash, onboard crypto, and a few other things. As for between 429 and 437, they're closer, but each has hardware that the other doesn't. Is that enough justification to have it as its own MCU? |
I think the different hardware mix and reference manual is a good reason to have it as a separate MCU. |
Programming Manual: http://www.st.com/content/ccc/resource/technical/document/programming_manual/6c/3a/cb/e7/e4/ea/44/9b/DM00046982.pdf/files/DM00046982.pdf/jcr:content/translations/en.DM00046982.pdf
Reference Manual: http://www.st.com/content/ccc/resource/technical/document/reference_manual/3d/6d/5a/66/b4/99/40/d4/DM00031020.pdf/files/DM00031020.pdf/jcr:content/translations/en.DM00031020.pdf
Datasheet: http://www.st.com/resource/en/datasheet/stm32f437vg.pdf
The STM32F4xx chips overlap quite a lot, if there's a way to avoid duplicating a lot of code/effort we should probably do that. Would it be better to start with the most featurefull chip (439?) and have variants that disable stuff, or would it be better to start with the least featureful chip (405? 401?) and build up the more featureful ones?
Is there a mechanism for inheritance / overriding?
The text was updated successfully, but these errors were encountered: