-
Notifications
You must be signed in to change notification settings - Fork 899
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TFT speed improvements #4684
base: master
Are you sure you want to change the base?
TFT speed improvements #4684
Conversation
Great work, however there's only one platform left that actually uses TFT_eSPI - all other TFT drivers have been ported to use lovyanGFX. I'd be in favor to throw out the eSPI dependency alltogether and see if we can accelerate the lovyan framebuffer copy in a similar way. |
I assume we are using TFT_eSPI for the nRF board because lovyanGFX does not support nRF. This PR should give a similar many-multiple speedup on lovyanGFX / ESP32 as the TFTDisplay interface layer is used by both. I just need someone to check that as I don't have any ESP32 hardware myself. |
I've tested this code with T-Deck and the SenseCAP Indicator (both esp32-S3 and lovyanGFX) but it does not work at all with the Indicator (screen white) and on T-Deck the display either stays black, boots in a loop, or the screen appears after 10 secs (skipping the boot screen). Though, once it is there, it feels fast. Edit1: Edit2: |
Thanks for the feedback, it seems like I've still got work to do! @mverch67 are you able to capture a log from the Tdeck when it fails to boot? I'm particularly interested if you see "Not enough memory to create TFT line buffer" |
To get the esp log stack trace I enabled the USB mode for T-Deck, but now the T-Deck works all the time without any issue.
But I think all devices that use TFTDisplay should be checked (e.g. heltec-tracker, T-Watch, PICOmputer, ...) |
It seems to be crashing at the point where it mallocs the new line buffer. For a 320px wide screen this would be 640 bytes. Is the ESP32 really short on heap space? I don't have any ESP32 hardware to debug this, so I'm going to have to park this for now. Any suggestions are welcome |
0f5795c
to
83a9ab5
Compare
83a9ab5
to
c479951
Compare
Screen update performance with TFT displays is... slow. Particularly on nRF processors with the default Arduino SPI driver. This PR greatly improves TFT screen update speed. I have measured a 32x speedup with a 128x160 TFT screen running on a RAK4631.
Note I don't have any ESP32 boards to test with but I expect a similar improvement. Someone with a T-deck please check.
Issue 1:
The
TFTDisplay.cpp
translation layer uses a pixel-by-pixel screen update strategy which is simple but slow. The following strategy is implemented here:Not only does this speed up TFT screen updates, it also reduces idle CPU usage. The screen update function is called once every second and this PR is much more efficient processing unchanged frames.
I measure a 4x speed increase with the above changes on a nRF / RAK4631. ESP32s should experience a greater speedup as they already have support for SPI block transfers.
Issue 2:
The default Arduino SPI driver on nRF platforms does not support multi-byte transfers, limiting the effectiveness of the above improvements. I have forked the TFT_eSPI library to implement uint16, uint32, and large block transfers on nRF:
https://github.com/robertfisk/TFT_eSPI
Change the following line in your variant's
platformio.ini
lib_deps section from:bodmer/TFT_eSPI
to:
https://github.com/robertfisk/TFT_eSPI.git#nrf_faster_spi
This forked library takes the 4x speed boost up to a 32x speed boost on nRF platforms.
Bonus Speedboost
On nRF platforms, add the following line to your variant.h to increase the second SPI port's maximum speed from 8MHz to 32MHz:
#define SPI_32MHZ_INTERFACE 1
Then configure SPI_FREQUENCY to some number between 8000000 and 32000000 depending on the capability of your hardware.