- 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>
The Nano's periodic full redraw blocked for ~0.8 s. A frame that arrived
meanwhile overflowed its 64-byte serial buffer; lost bytes in a bitmap
shift the rest of the image (picture moved up), and diff frames never
repaired it.
- Nano: all drawing (frames, effects, the dot refresh) runs from update()
in ~1 ms slices; the refresh pauses while a frame is received or shown
- New commands: C (reply with the image checksum) and I (refresh minutes,
EEPROM)
- ESP32: NanoMonitor asks for the checksum after frames and sends the whole
image again on a mismatch, missing answer or Nano restart; counts ERR
replies. Periodic whole-image resync.
- Settings: "Dot refresh" and "Image resync" intervals (settings v5,
v4 records are migrated)
- System tab: loop timing, free memory, frame check counts
- test_driver: the real driver against a simulated panel
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
mangavalkandClaude Opus 5.5