<thalesfragoso[m]>
Hmm, in the H7, SDMMC1 can only access the AXI SRAM, while SDMMC2 can access AXI SRAM, SRAM1, 2 and 3
<thalesfragoso[m]>
Thanks for the consistency ST
<thalesfragoso[m]>
Very easy to write generic drivers without the user messing with the wrong RAM /s
delnoch[m] has quit [Quit: Idle for 30+ days]
<korken89[m]>
<adamgreig-m "korken89: maybe check out the H7"> Thanks
<korken89[m]>
The thing I see is that the "freeze" idea does not map well to the dynamic use of clocks in L series
<korken89[m]>
I wonder if this use of having clock configuration in "flux" can be encoded in a nice interface
<firefrommoonligh>
thalesfragoso: These inconsistencies occur all over the lineup. I've found the best approach is to handle on a case-by-case basis
<firefrommoonligh>
I think we're speaking too generally. Ie you need to decide what it is you're doing dynamically
<firefrommoonligh>
I: `freeze` is a misleading name for the reason you mention. Something like `init` or `setup` is more appropriate
<firefrommoonligh>
2: Eating `RCC` is a bad plan
<firefrommoonligh>
I: `freeze` is a misleading name for the reason you mention. Something like `init` or `setup` is more appropriate
<firefrommoonligh>
2: Owning `RCC` isn't a good idea, since it blocks the (safe) use of all sorts of functionality across the MCU, especially clock config.
<firefrommoonligh>
* I think we're speaking too generally. Ie you need to decide what it is you're doing dynamically
<firefrommoonligh>
* I think we're speaking too generally. Ie you need to decide what it is you're doing dynamically
<firefrommoonligh>
I: `freeze` is a misleading name for the reason you mention. Something like `init` or `setup` is more appropriate
<firefrommoonligh>
2: Owning the `RCC` reg block isn't a good idea
<firefrommoonligh>
Then additional code to re-set-up the original speed. Another case would be changing Flash wait states (Which in the HALs is done in the RCC module since it's dependent on clock speed). This is affected by both clock speed, and which regulator you're using, which you might have interest in changing
<firefrommoonligh>
*Perhaps it may be better to explicitly change clock speed instead of doing it in a `low_power_run` fn, given there are different ways to accomplish this. Or maybe that function could assume MSI or something, and leave you to do things manually if you prefer a diff way.
<firefrommoonligh>
And `lower_power_run` would just set the `LPR` bit or something
<firefrommoonligh>
For context, I copped out in stm32-hal and didn't implement low_power_run or any way to change clocks dynamically. It's not tough, but I'm uncertain how to make the API, given all the options
<firefrommoonligh>
* For context, I copped out in stm32-hal and didn't implement low_power_run or any way to change clocks dynamically. It's not tough for a given use case, but I'm uncertain how to make the API, given all the possible ones.
<firefrommoonligh>
edit: I guess you could change dynamically with the API I have by changing the `Clocks` struct fields and re-running `setup`
<firefrommoonligh>
I guess you could do it with the stm32-hal by changing your `Clocks` fields, then running `re_select_input(&clock_cfg, &mut dp.RCC)`
<firefrommoonligh>
Assuming you only need to changing the input source, PLL source, MSI speed etc
<korken89[m]>
Yeah, I think something like this could make more sense
<firefrommoonligh>
Try writing what you want in the PAC. If you're using a HAL that consumes RCC, you can get it back (unsafe) by stealing dp.
<firefrommoonligh>
Switches to HSI, kicks off MSI, reconfigures, switches back to MSI and re-kicks off HSI
<thalesfragoso[m]>
<thalesfragoso[m] "Hmm, in the H7, SDMMC1 can only "> I could check the buffer address and return an error if it isn't right, but not sure if I should
<thalesfragoso[m]>
I would need different code for each family... let me check which families have this IP
<thalesfragoso[m]>
Hmm, only the H7 and L4xx+, note the +, L4xx has another IP...
<korken89[m]>
<firefrommoonligh "Switches to HSI, kicks off MSI, "> Is there a reason to switch to MSI? In my local impls I was changing MSI while running from it, seems like it worked fine :)
<thalesfragoso[m]>
Didn't even know that existed
<firefrommoonligh>
L5 RM: `Warning: MSIRANGE can be modified when MSI is OFF (MSION=0) or when MSI is
<firefrommoonligh>
ready (MSIRDY=1). MSIRANGE must NOT be modified when MSI is ON and NOT
<firefrommoonligh>
ready (MSION=1 and MSIRDY=0)`
<firefrommoonligh>
Also applies to L4
<firefrommoonligh>
Oh nvm, I guess that means you're right, and you don't need to kick it off
<firefrommoonligh>
Changing the code
<therealprof[m]>
<korken89[m] "The thing I see is that the "fre"> I would assume the whole point of naming it freeze is because it doesn't change after initialisation.
<therealprof[m]>
<thalesfragoso[m] "Hmm, only the H7 and L4xx+, note"> L4 has a few subseries. Not sure which cores they're using for them.
<korken89[m]>
<firefrommoonligh "Oh nvm, I guess that means you'r"> :D I found it quite interesting that one can change it while running
<korken89[m]>
(would not have expected it)
<korken89[m]>
<therealprof[m] "I would assume the whole point o"> Yeah, I mean it makes sense how the clocks are often used
<korken89[m]>
I'm starting to get enough inspiration to try something like a ref-counted clock generator for the L series
<korken89[m]>
I just need to figure out how to keep the relation to peripherals
<korken89[m]>
Would be very neat if the handling of clocks was automatic, not sure how nice the code will be though :P
<korken89[m]>
(for the low power use case this is)
<korken89[m]>
There was a quite interesting proposal for the SAMD with a token based clock structure