Open mungewell opened 6 months ago
I see that your patch is modifying src/rp2040/hardware_regs/include/hardware/regs/clocks.h
- FYI everything inside src/rp2040/hardware_regs
is autogenerated, so you'll have to move the changes you made there to some other file :wink:
And I also think we generally prefer Pull Requests, rather than patch files attached to Issues.
I presume you mean that they are generated from pico-sdk/src/rp2040/hardware_regs/rp2040.svd
.
How is that done? Can someone point me at a script? What I had added was a 'collation' of the 'SYS_CLK' dependants, not sure how to auto-gen that....
No problem for a PR, if I can figure it out.
I presume you mean that they are generated from
pico-sdk/src/rp2040/hardware_regs/rp2040.svd
.
Not quite. Both src/rp2040/hardware_regs/include/hardware/regs/
and src/rp2040/hardware_regs/rp2040.svd
are generated from the same internal data-files. (which are also used to generate the register tables in https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf )
How is that done? Can someone point me at a script?
This is done with internal (private) tooling.
From thread: https://github.com/orgs/micropython/discussions/14087
I am looking to keep the PIOs running during 'lightsleep()', as this will help my project save power. The CPU can pre-fill the FIFOs and then sleep, whilst the PIOs are processing the data.
ATM microPython 'lightsleep()' function calls the 'clock_init()' func after the CPU re-awakes, which causes the clocks to be reinitialized. This is 'bad' for me, as it overwrites the prior 'machine.freq(x)' call, but also potentially causes a glitch on the SYS clock - and therefore glitch on the PIO clocks.
This patch allows the passing of previously used
sleep_en0
andsleep_en1
values, which are used to determine whether SYS_CLOCK should be reinitialized, or skipped:20240314_sdk_keep_pios_running.patch.txt