Rewrite stm32f4 setup with svd generated registers#18
Open
mitchmindtree wants to merge 2 commits into
Open
Conversation
@thalesfragoso this is the patch I mentioned on matrix. Curiously, @therealprof didn't need it, and you mentioned the current setup has worked for you in the past as well. Just to clarify, the board I'm testing is STM32F407G-DISC1 - but I imagine behaviour should be the same across F407s? As you mentioned it would need either a critical section or access to the `&RCC` and `&SYSCFG` passed as arguments to the function directly. I think I'd opt for the latter approach, and not call this from inside `Eth::new`, but rather have a separate `configure_rcc` (or something like this) that the user can call separately before `Eth::new` is called. If it's a separate function, the user can do ```rust configure_rcc(&p.RCC, &p.SYSCFG); ``` before they set the RCC clock speeds and call `freeze`. If we really wanted to make sure this was called prior to `Eth::new`, we could do so by returning some type from `configure_rcc` that must be passed as an argument to `Eth::new`. I'll double check the behaviour of `master` compared to this patch again tomorrow once I'm back at work on this. I thought I'd open this in the meantime in case you were curious!
Member
|
You should use |
Contributor
Author
Interestingly, there are quite a few entries related to Ethernet in the errata for the STM32F407. That said, it appears all of the known issues have been resolved prior to my revision (which appears to be revision I haven't yet had a chance to go through the bit const declarations, or to dig deeper into why the |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
@thalesfragoso this is the patch I mentioned on matrix. Curiously,
@therealprof didn't need it, and you mentioned the current setup has
worked for you in the past as well. Just to clarify, the board I'm
testing is STM32F407G-DISC1 - but I imagine behaviour should be the same
across F407s?
As you mentioned it would need either a critical section or access to
the
&RCCand&SYSCFGpassed as arguments to the function directly.I think I'd opt for the latter approach, and not call this from inside
Eth::new, but rather have a separateconfigure_rcc(or somethinglike this) that the user can call separately before
Eth::newiscalled. If it's a separate function, the user can do
before they set the RCC clock speeds and call
freeze. If we reallywanted to make sure this was called prior to
Eth::new, we could do soby returning some type from
configure_rccthat must be passed as anargument to
Eth::new.I'll double check the behaviour of
mastercompared to this patch againtomorrow once I'm back at work on this. I thought I'd open this in the
meantime in case you were curious!