[AVR] CLKPR register : dynamic update of frequency
Hi,
i suggest some adds to change the frequency of AVR mcus with CLKPR register.
Tests have be done only with an ATTiny85 (in real and in simulide).
Suggested modifications can be found here : https://github.com/Coethium/SimulIDE-dev/tree/dev-CLKPR
Test files (ino, hex, sim) are joined with this topic.
Uploaded files:
Great!
will you do a PR?
But please include your copyright notice in the new files.
There are some things we can discuss, for example:
Do we really need to subclass McuPrescaled?
Seems that all devices using CLKPR use the same prescalers, and as you point in the code it's faster to just do a shift.
Hi,
Do we really need to subclass McuPrescaled?
Do you mean McuIntOsc became a subclass of McuPrescaled ?
With my firsts attempts, i tried with Prescalers list and index from XML ; so it was needed. Now you're right that not necessary. But after all, Internal Osc. are Prescaled, so IMHO it make sense. And maybe it could be useful in future refactor ? Do you prefer an AvrIntOsc class with it's own variables, not using herited m_prIndex and m_intOscFreq ?
But please include your copyright notice in the new files.
Done
will you do a PR?
Do you want it now, or when the discuss will be ended ?
About subclassing McuPrescaled:
Yes, it seems to me that AvrIntOsc is using just one variable from McuPrescaled, but this is not important and I'm not sure if will be of more use later.
Do you want it now, or when the discuss will be ended ?
I think you can do it now, then I can update my local repo and have a better look.
If we need some changes it can be done later anyway.
You're right : it uses only 1 variable, not 2 😉
(PR done)
Thank you, merged.
I made a little change yesterday (update initial freq on element creation).
I guess it needs some others changes, like at startup (reset ?). And what about if the user change the frequency as the simulation is running ?
I had a deeper look at this and I think I will do a bit of refactoring of all the MCU Frequency thing. Currently it is not well suited for dynamic frequency changes from the firmware.
You did part of it with the "force" parameter in eMcu::setFreq, but there are other issues to address, for example: which frequency will be saved.
So we need a clear differentiation from frequency settings and actual running frequency.
Also what you mention about the user changing the frequency as the simulation is running.
we need a clear differentiation from frequency settings and actual running frequency.
I totally agree ; in the current code i worked with m_intOscFreq being the "internal frequency" before Prescaler. I guess this is the one which need to be saved.
It could be used as RC Osc or PLL Osc (of course External clocks (by pin, by crystal) are not concerned by an "internal clock" ; and if the user sets a clock frequency, it must be ignored in these cases).
I think m_intOscFreq is a good candidate to represent the real (physical) internal frequency ; before any Prescale. The running frequency will be calculated on demand (cached as m_freq). When the user choose another frequency, this is like an overload of the internal frequency, so the chosen frequency has to de multiplied by the current Prescaler before updating m_intOscFreq.
Speaking of that, i think i bad positioned this last statement : i check the choice of the user when the Prescaler Register is modified ; but it's probably better never making a such check ; and just updating the internal frequency ASAP after the user change (with multiplication by the current prescaler, not the factory one).
Hi.
I did some changes to better support frequency changes from firmware.
I noticed some problems with frequency while testing which I didn't understand.
Finally I found that some MCUs, do some configurations based on fuses, and seems that this is translated to code by some compilers.
For example in Attiny85 (and others) division factor is set to 8 by default. So the frequency configured in properties widget is divided by 8.
To deal with these issues I added a property "Force this Frequency" (on by default), which block all frequency changes and force the frequency set in the UI.