LCD-7: 14 MHz pixel clock and 10-row bounce buffers, so Wi-Fi and USB survive the panel - #96
Merged
Merged
Conversation
…and USB At displayif's default 20 rows the panel takes 64 KB of internal DMA RAM. On this board with Wi-Fi, TLS and a USB audio host up (spotapi's remote and an earful speaker playing into a P4 sound card), the DMA-capable region sat at 24 bytes free; esp-aes then failed to allocate and Wi-Fi dropped. 10 rows (32 KB) keeps ~65 KB free under the same load. Needs displayif's bounce_rows (PyDevices/displayif, branch dcfb-bounce-rows); older builds ignore it via the TypeError fallback.
At 16 MHz the RGB scanout's PSRAM traffic (or its emissions; the effect is the same) wrecked the board's own Wi-Fi: 10-33 % ping loss with the panel running and 0 % with it stopped, at the same -77 dBm, and TLS downloads that stalled until the server reset the connection. At 14 MHz: 1.7 % loss and five of five 500 KB downloads at 176-237 KB/s (12 MHz: 250-306 KB/s, 29 Hz). 14 MHz keeps the refresh at ~34 Hz.
bdbarnett
added a commit
to PyDevices/micropython-pydevices
that referenced
this pull request
Sep 25, 2026
…g.lcd7) (#15) The 4.3" board's sdkconfig.board and partition table (same chip, memory and flash layout; boards flashed as the 4.3 keep their filesystem), then this board's fragment, appended last so it wins: - SPIRAM_MALLOC_ALWAYSINTERNAL 8192 -> 512, fewer Wi-Fi RX buffers, a 16 KB TCP window: internal DMA RAM, which the RGB panel's bounce buffers, the Wi-Fi driver, hardware AES and the USB host all need, sat at 24 bytes free with the shared settings, then esp-aes failed and Wi-Fi dropped. - FREERTOS_HZ 100 -> 1000: sleep_ms() under a tick busy-waits with the GIL held, keeping the UI thread 54 % busy while idle. Measured 2026-09-25 with spotapi's remote on the panel and earful streaming into a USB sound card (earful docs/lcd-7.md). Built from this directory the sdkconfig is identical to the image those measurements ran on. The board's board_config.py side is PyDevices/pydevices#96 (bounce_rows=10, 14 MHz).
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.
Two board-config changes for the Waveshare ESP32-S3-Touch-LCD-7, found while making it stream Spotify into a P4 USB sound card while running a Spotify remote UI:
14 MHz pixel clock (was 16). At 16 MHz the RGB scanout wrecked the board's own Wi-Fi at the same -77 dBm: 10-33 % ping loss with the panel running, 0 % with scanout stopped, and TLS downloads that stalled until the server reset them. At 14 MHz: 1.7 % loss and five of five 500 KB downloads at 176-237 KB/s (12 MHz was similar). Refresh drops to ~34 Hz; the image has not been checked by eye for flicker yet.
bounce_rows=10. At displayif's default 20 rows the panel takes 64 KB of internal DMA RAM. With Wi-Fi, TLS and a USB host up, the DMA-capable region sat at 24 bytes free and Wi-Fi fell over. 10 rows (32 KB) keeps ~60 KB free. This needs PyDevices/displayif#42; older displayif builds hit theTypeErrorfallback and keep their default.Independent of #77 (EXIO5, same file, different lines).