Fix dense images on the Nano and the off image in slow mode

- Nano: B data is drawn fast enough for the serial line. A hex digit arrives
  every 87 us; with a division and four drawPixel() calls per digit a lit
  digit took about 105 us, so dense frames (all yellow, the panda bitmap)
  overflowed the 64 byte receive buffer: frames not shown or wrong, "Line
  too long", frame check repairs that failed the same way. Now the parser
  counts columns and rows and BROSE9323::drawDots() sets the 4 dots
  (about 20 us).
- ESP32: Power off and the start of the night draw the off image also when
  slow mode had the power off already (it powers on for it, once)
- Tests: drawDots() against drawPixel(), off image in slow mode
- Version 2.19.3

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
mangavalkandClaude Opus 5.5 committed 2026-10-22 00:24:14 +02:00
1 parent 41af2944bc
commit 7a28e34380
13 files changed
+130 -17

No files matched your search

+2 -1
View File
@@ -49,7 +49,8 @@ Arduino core, EEPROM and the display driver are replaced by fakes in
- **Nothing blocks.** Every frame (also instant ones, `D1`) is flipped from `update()` in
slices of about 1 ms, so `loop()` keeps reading the serial port. A blocking redraw used
to overflow the 64-byte receive buffer; the lost bytes shifted the rest of a bitmap
(the picture moved up and left) and nothing repaired it.
(the picture moved up and left) and nothing repaired it. Bitmap data is drawn as fast as
it arrives too (one hex digit every 87 µs); dense images used to be slower than that.
- **Every 2 minutes** (`I` command, stored in EEPROM, 0 = never) it flips every dot once
more, with one pulse, to fix dots that got stuck. This also runs in slices, only while
no frame is being received or shown, and continues where it was after a frame.