Modeling CPU frequency (Setting, calculating, sources)

[soypat]

This discussion centers on modeling CPU frequency at the TinyGo API level.

Things to take into consideration:

• MCUs sometimes have varying sources of frequency. Pico has a PLL for startup and then switches to crystal
• MCUs sometimes can switch sources of frequency mid program
• Low power mode: How do we design low power modes so that it is cohesive with the CPU Frequency modelling
  • Low power mode can interact with CPU frequency.
• Sometimes you need to do lots of calculation to get the values needed to set a CPU frequency, see current Pico implementation, it does a lot of calculation on the interp level of tinygo compiler and does not affect build size

Catalyst conversation: #5106 (comment)

[eliasnaur]

Can say a bit what you're trying to achieve? I guess the ability for user code to configure the CPU frequency at runtime, but why? Saving power? Is there really so much power to save compared to, say, running whatever task needs done at highest frequency and then going to sleep?

[burgrp]

That's true, but the peripherals should allow that.
It's application specific, so user knows what peripherals need reconfiguration. For example the sequence could look like:

machine.CPUFrequencyChanged(48E6)
runtime.ConfigureSystemTimer() 
machine.DefaultUART.Configure()

If it was build time, how do you specify the frequency, oscillator, whether and how to setup PLL etc..?

[eliasnaur]

With build configuration, the peripherals can assume machine.CPUFrequency is a constant and there is no need to reconfigure at all, simplifying the logic.

[burgrp]

In theory yes, but how it would look like in real? Can you write an example please?

[eliasnaur]

tinygo build -target pico2 -cpufrequency 200MHz ...

[burgrp]

Does it mean (please tell me no :) ), that you would add it here:
https://github.com/burgrp/tinygo/blob/py32/compileopts/options.go#L10-L18
then here:
https://github.com/burgrp/tinygo/blob/py32/compileopts/options.go#L23
then here:
https://github.com/burgrp/tinygo/blob/py32/main.go#L1726
then here:
https://github.com/burgrp/tinygo/blob/py32/compileopts/config.go#L105
and few more places.

And for other details, like oscillator, PLL etc... we would do the the same for other options?
And finally it will just enable a particular block of code, which will be compiled-in.
I'm afraid it's not flexible, there is no abstraction, can't cover all uses cases.
Sorry to say, but that's very poor design in my opinion...