diff --git a/doc/07_serial_protocol.md b/doc/07_serial_protocol.md index 05c74cc..d593641 100644 --- a/doc/07_serial_protocol.md +++ b/doc/07_serial_protocol.md @@ -37,7 +37,6 @@ 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 | @@ -56,7 +55,6 @@ 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 | @@ -133,21 +131,6 @@ 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 diff --git a/src/CMainController.cpp b/src/CMainController.cpp index ec7fe8a..c695788 100644 --- a/src/CMainController.cpp +++ b/src/CMainController.cpp @@ -232,18 +232,6 @@ 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 diff --git a/src/hal/usb_serial.h b/src/hal/usb_serial.h index d0121b0..e54c2ee 100644 --- a/src/hal/usb_serial.h +++ b/src/hal/usb_serial.h @@ -30,10 +30,6 @@ // 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 @@ -50,7 +46,6 @@ #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