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

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

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