Nur geaenderte Zellen schreiben -- gegen das Flackern im Sekundentakt

Seit der Einzelpositionierung blitzten bei jeder Aktualisierung willkuerliche
Pixel auf, in beiden Zeilen. Ursache ist die Telegrammlaenge: Eine volle Zeile
kostet mit einzeln gesetzten Zeichen rund 100 Bytes statt 20, bei 19200 Baud
und 8E1 (11 Bit je Byte) dauerte ein kompletter Bildwechsel damit rund 300 ms.
Die Anzeige stellt schon waehrend des Empfangs dar, also war der Aufbau zu
sehen -- im Sekundentakt ein Drittel der Zeit.

Von einer Sekunde zur naechsten aendert sich aber fast nichts: "18h36m56s" ->
"18h36m57s" ist eine einzige Ziffer, die Deklination steht meist still.
show_lines vergleicht deshalb gegen den zuletzt dargestellten Inhalt und
schreibt nur die betroffenen Zellen; eine unveraenderte Zeile erzeugt gar kein
Telegramm mehr. Am Geraet gemessen: 306 ms -> 66 ms je Bildwechsel.

Dabei am Geraet aufgefallen und mitbehoben: Dem "s" hinter den Sekunden fehlten
die linken Pixel, dem "m" hinter den Minuten ebenso -- beides Zeichen direkt
rechts von einer Stelle, die sich gerade geaendert hatte. Die Anzeige malt je
Zeichen 7 px breit (daher auch der 7-px-Auto-Vorschub), gesetzt wird aber auf
6-px-Raster: Ein neu geschriebenes Zeichen loescht die erste Pixelspalte seines
rechten Nachbarn. Beim vollstaendigen Neuaufbau fiel das nie auf, weil der
Nachbar gleich danach ohnehin neu gemalt wurde. _zelle_faellig zieht ihn jetzt
mit.

Weitere Details:
- clear() verwirft den gemerkten Inhalt, sonst haelt der Vergleich Zellen
  faelschlich fuer vorhanden und die Anzeige bliebe teilweise leer.
- Schlaegt ein Telegramm fehl, wird der gemerkte Inhalt der Zeile verworfen --
  was angekommen ist, ist dann ungewiss.
- Der Zeichensatz wird nur noch bei der ersten Ausgabe einer Zeile gesetzt. Das
  spart nicht nur Bytes: Jeder Wechsel beschaedigt die Home-Zelle. Findet doch
  einer statt (neues Gradzeichen), wird die oberste Zeile vollstaendig
  nachgezogen.

Zu beiden Befunden gibt es Tests mit Gegenprobe (mit der alten Fassung schlagen
sie fehl). 155 Tests gruen, am Geraet bestaetigt: ruhig, keine fehlenden Pixel.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-07-27 17:18:11 +02:00
parent 41f5eb1821
commit dae7694a07
4 changed files with 306 additions and 58 deletions
+24 -5
View File
@@ -321,11 +321,30 @@ die Reihenfolge der Telegramme statt der Reihenfolge innerhalb eines Telegramms.
mitwandernder Offset könnte das nicht; dafür ist die Zentrierung nur auf eine
halbe Zelle (3 px) genau, wenn die Restbreite ungerade ist.
- **Zyklische Updates flimmerfrei:** `show_lines` löscht nicht bei jeder Aktualisierung,
sondern überschreibt die Zeilen an Ort und Stelle (auf volle Breite aufgefüllt).
`clear=True` nur beim ersten Bild. Wichtig: Zeilen dürfen **nicht breiter** als
`CHARS_PER_LINE` aufgefüllt werden, sonst bricht das Füll-Leerzeichen um und
beschädigt die andere Zeile.
- **Es wird nur geschrieben, was sich geändert hat.** `show_lines` vergleicht gegen
den zuletzt dargestellten Inhalt und schickt nur die betroffenen Zellen; eine
unveränderte Zeile erzeugt gar kein Telegramm. `clear=True` nur beim ersten Bild
und nach einem Verbindungsabriss.
Das ist nicht nur Sparsamkeit, sondern der Grund für eine ruhige Anzeige. Mit
Einzelpositionierung kostet eine volle Zeile rund 100 Bytes statt 20; bei 19200
Baud mit 8E1 (11 Bit je Byte) dauerte ein kompletter Bildwechsel damit **rund
300 ms**. Die Anzeige stellt schon während des Empfangs dar, also war der Aufbau
als Flackern zu sehen — bei Aktualisierung im Sekundentakt ein Drittel der Zeit.
Von einer Sekunde zur nächsten ändert sich aber fast nichts: `18h36m56s` →
`18h36m57s` ist eine einzige Ziffer. Am Gerät gemessen (2026-07-27):
**306 ms → 66 ms** pro Bildwechsel.
- **Der rechte Nachbar wird mitgeschrieben.** Die Anzeige malt je Zeichen 7 px
breit (daher der 7-px-Auto-Vorschub), gesetzt wird aber auf 6-px-Raster. Ein neu
geschriebenes Zeichen löscht deshalb die erste Pixelspalte des Zeichens rechts
daneben. Beim vollständigen Neuaufbau fiel das nie auf, weil der Nachbar gleich
danach ohnehin neu gemalt wurde — beim Schreiben einzelner Zellen blieb er
beschädigt stehen: dem `s` hinter den Sekunden fehlten die linken Pixel, dem `m`
hinter den Minuten ebenso. `_zelle_faellig` zieht den rechten Nachbarn deshalb mit.
- Wichtig bleibt: Zeilen dürfen **nicht breiter** als `CHARS_PER_LINE` aufgefüllt
werden, sonst bricht das Füll-Leerzeichen um und beschädigt die andere Zeile.
## Präzision (Low / High)