Skip to content
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

Open
robomancer-or opened this issue Jun 4, 2018 · 3 comments
Open

Add MCU support for STM32F437 (and friends) #2

robomancer-or opened this issue Jun 4, 2018 · 3 comments

Comments

@robomancer-or
Copy link

robomancer-or commented Jun 4, 2018

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?

@jcsoo
Copy link
Contributor

jcsoo commented Jun 4, 2018

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:

  • Add clock definitions (probably easiest to take the F74x ones and remove the ones that don't exist)
  • Add RCC gate definitions for peripherals (also copy and paste from F74x but look for changes)
  • Add RCC, Flash and Clock code in mcu/ext

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.

@robomancer-or
Copy link
Author

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?

@jcsoo
Copy link
Contributor

jcsoo commented Jun 4, 2018

I think the different hardware mix and reference manual is a good reason to have it as a separate MCU.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants