Skip to content

raspberrypi: Make port_idle_until_interrupt work#7201

Merged
jepler merged 2 commits into
adafruit:mainfrom
jepler:rp2040-light-sleep
Nov 15, 2022
Merged

raspberrypi: Make port_idle_until_interrupt work#7201
jepler merged 2 commits into
adafruit:mainfrom
jepler:rp2040-light-sleep

Conversation

@jepler

@jepler jepler commented Nov 12, 2022

Copy link
Copy Markdown

This needs thorough testing before it's merged, as we tried and reverted this once before (#5341 and #5356).

I think that besides checking for tinyusb having "something to do", the fact that port_interrupt_after_ticks and port_disable_tick weren't implemented that was causing a secondary problem.

I've tested this on a pico w over reboot-cycles and ctrl-c-cycles, with and without drive automounting, with and without serial repl open, and on a power-only connection.

I didn't notice the problem reported in #5356 after merely implementing port_idle_until_interrupt; but I did notice that sleeps in general would take over-long until "something" (like writing to the USB drive) happened; I think "something" was probably calling port_enable_tick(). When this problem was happening, sleeps would take a lot longer; for instance, sleep(.001) would take about 1/20s and sleep(.1) would take about 1/7s.

Closes: #5331

This needs thorough testing before it's merged, as we tried
and reverted this once before (adafruit#5341 and adafruit#5356).

I think that besides checking for tinyusb having "something to do",
the fact that `port_interrupt_after_ticks` and `port_disable_tick`
weren't implemented that was causing a secondary problem.

I've tested this on a pico w over reboot-cycles and ctrl-c-cycles,
with and without drive automounting, with and without serial repl open,
and on a power-only connection.

I didn't notice the problem reported in adafruit#5356 after merely implementing
port_idle_until_interrupt; but I did notice that sleeps in general would
take over-long until "something" (like writing to the USB drive) happened;
I think "something" was probably calling port_enable_tick(). When this
problem was happening, sleeps would take a lot longer; for instance,
`sleep(.001)` would take about 1/20s and `sleep(.1)` would take about 1/7s.
@jepler jepler marked this pull request as ready for review November 12, 2022 15:19
@jepler

jepler commented Nov 12, 2022

Copy link
Copy Markdown
Author

@Neradoc @microdev1 @urish if any of you have time & interest in testing out this branch it would be helpful!

@urish

urish commented Nov 15, 2022

Copy link
Copy Markdown

What kind of help do you need w/testing?

@jepler

jepler commented Nov 15, 2022

Copy link
Copy Markdown
Author

Just general testing, as the earlier occasion when we tried to enable WFI for light sleeping problems cropped up that the original submitter didn't find right away. I tried to test a number of scenarios that would "cover" normal usage but one always misses something...

@tannewt

tannewt commented Nov 15, 2022

Copy link
Copy Markdown
Member

This looks fine to me. I'm happy to test in main. :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Implement CPU sleep (WFI) when idle on RP2040

3 participants