DotClockFramebuffer(bounce_rows=): cap the bounce buffers' size - #42
Merged
Merged
Conversation
Both bounce buffers come from internal DMA RAM, which Wi-Fi, TLS (hardware AES) and a USB host also need. At the default 20 rows an 800-wide panel takes 64 KB of it; on a Waveshare ESP32-S3-Touch-LCD-7 running Wi-Fi, a USB audio host and a Spotify Connect speaker beside the panel, the DMA-capable region sat at 24 bytes free, then esp-aes failed to allocate and Wi-Fi fell over. With bounce_rows=10 (32 KB) the same load keeps ~65 KB of DMA RAM free. bounce_rows is the upper bound the probe steps down from (default and maximum 20, minimum 4, as before); the "RAM is tight" notice and the error messages now name that bound. Boards that do not pass it are unchanged.
This was referenced Sep 25, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Both RGB bounce buffers come out of internal DMA RAM, which Wi-Fi, TLS (hardware AES) and a USB host need too. At the default 20 rows an 800-wide panel takes 64 KB of it.
On a Waveshare ESP32-S3-Touch-LCD-7 running Wi-Fi, a USB audio host and a Spotify Connect speaker beside the panel, the DMA-capable region sat at 24 bytes free. Then
esp-aes: Failed to allocate memoryand Wi-Fi dropped. Withbounce_rows=10(32 KB) the same load keeps ~58-65 KB of DMA RAM free (the speaker's debug endpoint,free_dma/min_dma).bounce_rows(keyword, 4..20, default 20) is the upper bound the probe steps down from. Boards that don't pass it are unchanged.Tested on the LCD-7 over several hours of playback plus UI navigation at 10 rows: the rest of the system stopped starving. The panel image itself has not been checked by eye yet. The companion board-config change is PyDevices/pydevices (branch
lcd7-bounce-rows). ItsTypeErrorfallback keeps older displayif builds working.