You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The implementation of #3454 does not currently behave in an intuitive way when used in conjunction with Deep Sleep. In general, a "sub program" called by supervisor.set_next_file should behave in an identical way to a typical code.py program, so that code examples and copied projects can be used without thinking about whether they've been selected from a menu. However, current programs that use Deep Sleep in conjunction with set_next_file cannot store next file information, since deep sleep shuts down the memory. This means that a "sub-program" in a menu context will return to the menu after true deep sleeping, instead of re-entering the program as it would if it were the "primary" program. To make matters worse, if the deep sleep is fake (connected to usb), it will re-enter properly, making this even less consistent.
Solving this problem is more complicated than it looks. It requires that each port port has alarm.SleepMemory implemented, and needs an extra API to assign a particular region of SleepMemory for "system use" where the set_next_file filename can be stored. In addition, steps must be taken in Main to store the filename only when true deep sleep is entered, and to clear it when appropriate.
I've gotten started on this here, but my STM32 implementation is buggy and the other ports remain unfinished. It will also need an all-new implementation of RP2040 SleepMemory, described in #5081.
The text was updated successfully, but these errors were encountered:
The implementation of #3454 does not currently behave in an intuitive way when used in conjunction with Deep Sleep. In general, a "sub program" called by
supervisor.set_next_file
should behave in an identical way to a typicalcode.py
program, so that code examples and copied projects can be used without thinking about whether they've been selected from a menu. However, current programs that use Deep Sleep in conjunction withset_next_file
cannot store next file information, since deep sleep shuts down the memory. This means that a "sub-program" in a menu context will return to the menu after true deep sleeping, instead of re-entering the program as it would if it were the "primary" program. To make matters worse, if the deep sleep is fake (connected to usb), it will re-enter properly, making this even less consistent.Solving this problem is more complicated than it looks. It requires that each port port has
alarm.SleepMemory
implemented, and needs an extra API to assign a particular region of SleepMemory for "system use" where theset_next_file
filename can be stored. In addition, steps must be taken in Main to store the filename only when true deep sleep is entered, and to clear it when appropriate.I've gotten started on this here, but my STM32 implementation is buggy and the other ports remain unfinished. It will also need an all-new implementation of RP2040 SleepMemory, described in #5081.
The text was updated successfully, but these errors were encountered: