twisla/roro9stack
Public Access
1
0
Fork 0
Code Issues 51 Pull Requests 1 Actions Packages Releases 14 Activity

The main loop rests between passes (#40)

Browse Source 
It made 50,000 passes a second and kept core 1 100 % busy at rest. Keys
are buffered by the keyboard controller, the consoles and the radio have
their own tasks, and no Service ticks more often than every 50 ms, so
the loop now rests 5 ms after a pass with the screen on and 20 ms with
it off; never during a serial file transfer. Safe Mode's loop too.

Screen off: 50 passes a second and core 1 at 1 %; screen on: 167 and
10 %. The chip settles 4 C cooler (34.3 against 38.3). GNSS, Gemini, an
upload, the Sweep and the radio's interrupt all checked at the new pace.
`tasks` shows the loop's passes; Debug Builds: `loop spin on|off`.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EhqxQ49eCju4CzKYNjZzwT
This commit is contained in:
twisla
2026-10-06 03:08:02 +02:00
co-authored by Claude Opus 5.5
parent 9078ab9c39
commit 06a593293d
3 changed files with 62 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/milestones/S1.md
+22
View File
@@ -90,3 +90,25 @@ The App has five views, not four: Q121's network view is one of its own (Overvie
- **`tasks` on the console** sampled twice inside one command at first, a quarter second apart, and showed the loop at 1 %: it was asleep in the command's own wait. It now samples, lets the loop run for a second, and prints.
- **Low stack, flagged:** `IDLE0` (232 bytes left), `IDLE1` (328 to 352) and `spk_task` (256 to 264), all the framework's own tasks.
- **Cost:** 15.6 KB of flash for the App and the counters (1,742,723 bytes, release). Nothing while it's closed; about 2 KB of history and samples while it's open.
## The main loop rests (issue #40)
The loop polled the keyboard, ticked the Services, ran the consoles and redrew when needed, then came straight back: 50,000 passes a second, and core 1 100 % busy with the device idle and the screen off.
Nothing needs that. The keyboard controller buffers key events; the consoles and the radio have their own tasks or interrupts; no Service asks for a tick more often than every 50 ms. So after each pass the loop now rests: **5 ms with the screen on, 20 ms with it off**, and not at all during a serial file transfer (`sd put`), which reads its bytes from the loop. Safe Mode's loop rests 5 ms too. Debug Builds have `loop spin on|off` to bring the old behaviour back for comparison.
### Measured (2026-10-06, Debug Build, Wi-Fi connected, GNSS on, on USB power)
| | Spinning | Resting |
|---|---|---|
| Passes a second, screen off | 50,160 | 50 |
| Core 1 load, screen off | 100 % | 1 % |
| Passes a second, screen on (Launcher) | 1,203 | 167 |
| Core 1 load, screen on | 62 % | 10 % |
| Chip temperature at rest, settled | 38.3 C | 34.3 C |
| A 1.8 MB upload over the Debug Console | about 230 KB/s | 288 KB/s |
- Still working at this pace: GNSS (a 3D Fix, 22 satellites), a Gemini fetch (52 KB), the upload read back by SHA-256, the Sweep (still 606 to 610 ms a pass), the radio's DIO1 interrupt.
- **Not measured:** the current drawn (no meter on the battery line), and how typing feels on the real keyboard: a key now waits up to 5 ms for the loop, 20 ms if it's the one that wakes the screen.
- **The radio's noise floor didn't move** (-97 to -99 dBm at 125 kHz either way): the spinning loop wasn't the source (issue #20).
- **Not done:** real sleep. The framework is built without power management (`CONFIG_PM_ENABLE` is off), so an idle core only halts until the next interrupt. Automatic light sleep would need the framework rebuilt with it, Wi-Fi in modem sleep, and the USB serial port's behaviour checked. A next step if battery life calls for it.