jappel/VersaMCU
1
0
Fork 1
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions

Add lightweight READ_STATUS command to avoid blocking LED updates during polling

Browse source 
CONFIG_READ was being (ab)used by the Windows viewer's Live-Sync feature
to poll just the active profile every 1.5s, but the handler sends the
full 740-byte config as ~124 blocking chunk packets from inside
poll_vendor() -- which runs before updateLEDs() in the same loop
iteration (see the loop-order comment at the top of
CMainController.cpp). Every poll cycle stalled updateLEDs() long enough
that running Pulse/Blink animations visibly stuttered, since their
brightness is computed from an absolute millis() timestamp and jumps
forward once the stall clears instead of catching up smoothly.

Added USB_CMD_READ_STATUS (0x06) / USB_EVT_STATUS (0x86): a single NVM
read (no serial I/O) and one 8-byte reply packet with the active
profile in Data[1], no chunking. Documented in
doc/07_serial_protocol.md alongside why CONFIG_READ is unsuitable for
polling. CONFIG_READ stays as-is for actual full-dump use (e.g. "Vom
Board laden").

Verified on hardware after flashing via env:versapad_usb: READ_STATUS
returns the correct profile in ~well under CONFIG_READ's dump time,
Live-Sync no longer visibly disturbs LED animations.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
cjjohn 2026-08-07 15:37:21 +02:00
parent 01c5e0930e
commit 13c3e41c91
3 changed files with 34 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

17
doc/07_serial_protocol.md
View file

@ -37,6 +37,7 @@ Es gibt kein Framing, keinen Längenheader und keine Prüfsumme auf Paketebene.
| `0x02` | `CLEAR_LED_OVERRIDE` | Override entfernen |
| `0x03` | `SET_LED_BASE` | Base-Farbe im RAM setzen |
| `0x05` | `PING` | Antwort: `PONG` |
| `0x06` | `READ_STATUS` | Antwort: `STATUS` (Byte 1 = aktives Profil 0-2) |
| `0x10` | `CONFIG_BEGIN` | Config-Transfer starten |
| `0x11` | `CONFIG_DATA` | 6 Byte Config-Nutzdaten |
| `0x12` | `CONFIG_COMMIT` | Config pruefen und speichern |
@ -55,6 +56,7 @@ Es gibt kein Framing, keinen Längenheader und keine Prüfsumme auf Paketebene.
| `0x83` | `ENC_CW` | Encoder-Host-Action im Uhrzeigersinn |
| `0x84` | `ENC_CCW` | Encoder-Host-Action gegen Uhrzeigersinn |
| `0x85` | `PONG` | Antwort auf Ping |
| `0x86` | `STATUS` | Antwort auf `READ_STATUS`, Byte 1 = aktives Profil 0-2 |
| `0x90` | `CONFIG_ACK` | Config erfolgreich gespeichert |
| `0x91` | `CONFIG_NACK` | Config ungueltig oder NVM-Timeout |
| `0x92` | `CONFIG_BEGIN` | Config-Dump beginnt |
@ -131,6 +133,21 @@ Actiontypen/-daten, LED-Enums und kritische Animationsperioden.
Makro-Commit prüft die Vollständigkeit und alle HID-Keycodes. Die Makrotabelle
besitzt weiterhin keine eigene persistente CRC.
## READ_STATUS vs. CONFIG_READ fuer Polling
`CONFIG_READ` sendet den kompletten 740-Byte-Dump synchron und blockierend
aus `poll_vendor()`, bevor `updateLEDs()` im selben Loop-Durchlauf drankommt
(siehe Kommentar am Dateianfang von `CMainController.cpp`) – bei
wiederholtem Polling (z.B. Live-Sync in der Windows-App, die nur das aktive
Profil braucht) fuehrt das sichtbar zu ins Stocken geratenden LED-Pulse-
Animationen, weil `updateLEDs()` bei jedem Poll um die Dump-Dauer verzoegert
wird. `READ_STATUS` liest nur `active_profile` aus dem NVM-Config und
schickt ein einzelnes Paket zurueck – kein Chunking, keine mehrfachen
`SerialUSB.write()`-Aufrufe, kein spuerbarer Einfluss auf die
LED-Animation. Für periodisches Profil-Polling immer `READ_STATUS`
verwenden, `CONFIG_READ` nur fuer den tatsaechlichen vollen Dump (z.B.
"Vom Board laden" im Programmiermodus).
## Praktische Hinweise fuer die GUI
- nach `CONFIG_COMMIT` auf `CONFIG_ACK` oder `CONFIG_NACK` warten

12
src/CMainController.cpp
View file

@ -232,6 +232,18 @@ void CMainController::poll_vendor()
usb_serial_send(USB_EVT_PONG, 0);
break;
// Leichtgewichtiger Status (aktuell nur aktives Profil) – ein NVM-Read,
// ein 8-Byte-Paket zurück. Für Polling (Live-Sync) statt CONFIG_READ,
// das für den Dump ~124 blockierende Pakete braucht und dabei
// updateLEDs() so lange verzögert, dass Pulse-Animationen sichtbar stottern.
case USB_CMD_READ_STATUS:
{
SDeviceConfig cfg;
nvm_config_load(cfg);
usb_serial_send(USB_EVT_STATUS, cfg.active_profile);
break;
}
// Config-Übertragung: BEGIN → n×DATA → COMMIT
case USB_CMD_CONFIG_BEGIN:
// Neuen Empfang starten – bisherige Daten verwerfen

5
src/hal/usb_serial.h
View file

@ -30,6 +30,10 @@
// DATA: Data[1] = Chunk-Index (0-based), Data[2..7] = 6 Bytes Nutzdaten
// COMMIT: CRC prüfen + NVM schreiben + Buttons neu laden
#define USB_CMD_PING 0x05 // Board antwortet sofort mit USB_EVT_PONG
#define USB_CMD_READ_STATUS 0x06 // Board antwortet sofort mit USB_EVT_STATUS, Data[1] = aktives Profil (0-2).
// Leichtgewichtiger Ersatz für CONFIG_READ wenn nur das Profil interessiert
// (Live-Sync) -- CONFIG_READ blockiert poll_vendor() fuer ~124 Chunk-Pakete
// und verzoegert dadurch updateLEDs(), was als LED-Pulse-Stottern sichtbar wird.
#define USB_CMD_CONFIG_BEGIN 0x10
#define USB_CMD_CONFIG_DATA 0x11
#define USB_CMD_CONFIG_COMMIT 0x12
@ -46,6 +50,7 @@
#define USB_EVT_ENC_CW 0x83 // enc_id + Command-ID in Data[2..3]
#define USB_EVT_ENC_CCW 0x84 // enc_id + Command-ID in Data[2..3]
#define USB_EVT_PONG 0x85 // Antwort auf USB_CMD_PING
#define USB_EVT_STATUS 0x86 // Antwort auf USB_CMD_READ_STATUS, Data[1] = aktives Profil (0-2)
#define USB_EVT_CONFIG_ACK 0x90 // Config erfolgreich in NVM geschrieben
#define USB_EVT_CONFIG_NACK 0x91 // Config CRC/Magic ungültig – nicht geschrieben
#define USB_EVT_CONFIG_BEGIN 0x92 // Beginn Config-Dump: Data[1] = Chunk-Anzahl