977308ef80
User reported only 2 frames rendering after the SPI batching change. Diagnosis: the previous flush triggers (CS-line HIGH, buffer >=4096) were both event-driven. Adafruit_ILI9341's ESP32 backend manages CS via digitalWrite — i.e. through the GPIO peripheral, NOT the SPI peripheral's hardware CS pin. So the CS-line-HIGH event from picsimlab_spi_event NEVER fires for this driver. The buffer only flushes when it hits 4096 bytes. Frame 1: 38 400 bytes from drawRGBBitmap → 9 flushes at 4096-byte boundaries → last 192 bytes stay in the buffer. Status bar adds some bytes too → maybe one more flush. Frame 2: same. But by frame 3 the firmware is running ahead of the flush rhythm and somehow the buffer pattern wedges in a state where no flush completes (likely a partial buffer that sits between transactions while the firmware briefly waits on the next fb_get). Hard to reproduce deterministically — but the symptom matches. Fix: add a 50 ms periodic flush thread. Independent of any event, it acquires the lock and flushes whatever's pending. Bounds the worst-case latency at 50 ms (= 20 fps ceiling, more than enough for the emulator). Triple-trigger now: 1. CS HIGH (fast path for hardware-CS drivers) 2. Buffer >= 4096 (safety for big transactions) 3. 50 ms timer (catches GPIO-CS drivers, prevents stalls) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| app | ||
| scripts | ||
| sdk | ||
| tests | ||
| .env.example | ||
| Dockerfile | ||
| debug_qemu.py | ||
| mcp_server.py | ||
| mcp_sse_server.py | ||
| requirements.txt | ||