RP2040 with ST7789 240x320 display slow refresh using pushSprite() (220ms) #2899
Replies: 6 comments 3 replies
-
Pushing the sprite should be fast (circa 35ms). So the delay is probably due to the complexity of the graphics being drawn, maybe font loading etc. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the reply. Yes that's about what I've calculated. Yet doing a simple program simply filling the sprite with black or white it takes about 200ms + to push to the display. I set up a really simple test:
which outputs:
I'll stick a signal analyser on the SPI bus and see if I can tell what's happening. |
Beta Was this translation helpful? Give feedback.
-
Here are some capture from my Logic device: This is a full pushSprite capture with a white sprite 320x240 |
Beta Was this translation helpful? Give feedback.
-
There is no fillScreen function for sprites, use fillSprite. Due to class inheritance the screen will be cleared instead, thus the screen will be updated twice per loop in the above sketch. This should be noticeable in the logic analyser output. Using an 8 bit sprite will be slower as every 8 bit pixel has to be converted to 16 bits and checked to see if is a transparent colour. Running the cpu at 133MHz automatically reduces the maximum SPI rate to 24MHz, see here. Running at 125MHz cpu clock may increase render speed. Run the Read_User_Setup sketch to check the SPI frequency set in the users setup file, note that that is not necessarily the frequency implemented as noted in link above. Also valid SPI clock rates are integer divisions of the cpu frequency, so at 125MHz cpu clock a setting of 40MHz in the setup file actually ends up being 32.25MHz. |
Beta Was this translation helpful? Give feedback.
-
Hi, Yes sorry when I wrote my test example I missed the fillScreen / fillSprite issue, I had not been using this in my full code though. However I have re-written the test code and there is no change to refresh rate. I can confirm I'm running at 125Mhz, I had read the post about clock speed on the RP2040. I have run the test with a 16bit colour depth but still no change in refresh rate. I'm sure I had it running quite fast at one point then noticed it had slowed right down. I have re-installed the lib fresh just to make sure I hadn't tweaked a setting but still can't figure this out. enabling PIO mode makes no difference.
|
Beta Was this translation helpful? Give feedback.
-
OK, I have solved the issue which is board related. As stated at the top I'm using the Longan RP2040 CANBed board, and after doing some digging around in the TDT_eSPI header files I noticed that the board was using the TFT_eSPI_Generic.h files! So it seems the Longan boards.txt does not define the architecture ARDUINO_ARCH_RP2040 and thus the faster SPI routines were not being used! It does define ARDUINO_RASPBERRY_PI_PICO so I'm using that to force architecture at the top of the TFT_eSPI.h header, using:
I'm now getting tft.fillScreen() in about 40mS I added the following to the TFT_eSPI.h header as a warning:
|
Beta Was this translation helpful? Give feedback.
-
Hi, this is my setup:
RP2040 CANbed board with 2" 240x320 ST7789 display attached. I am using a TFT_eSprite image to write to then pushing the whole image to the display. my clock settings are:
#define SPI_FREQUENCY 40000000
#define SPI_READ_FREQUENCY 20000000
#define SPI_TOUCH_FREQUENCY 2500000
This is working fine but it takes about 220ms to refresh the display, does this seem right? I was expecting a faster refresh rate than this. I have tried defining the PIO mode but this makes no difference to pushSprite() speed.
Any advise apperciated.
Beta Was this translation helpful? Give feedback.
All reactions