Closed yanshay closed 10 months ago
Did you run the code in release mode?
Did you run the code in release mode?
Now I did and it's much faster now. Clearing the screen takes 122.5milisec and Drawing the smily is 20.3 milisec. So if I'd work with a UI widget library, should I expect around 1/122.5msec = 8fps (since I think those libs redraw the entire screen every time)? Or is the embedded_graphics lib used in this demo not very optimized and I should expect better?
There are essentially 4 things to consider when it comes to speed:
1 - 3 are all in your hands, 4 is somewhere between the driver and embedded-graphics and what you draw and how.
As for your timings, when you say clearing the screen you mean via display.clear()
? That should preferably be "the fastest possible" in terms of your set SPI and MCU speeds given that it should really just push pixels after one window operation call.
I increased MCU clock speed (I thought by default it would be at max speed), and it indeed increased the speed. And increasing SPI clock it indeed increased speed as well. How do I know how much I can increase SPI? For MCU it's in the spec, but SPI I couldn't find, and noticed on another application that increasing speed to much draws screen distorted. I also noticed it's possible to initialize spi with or without cs/miso, does that make a difference in performance/correctness of data transfer?
I increased MCU clock speed (I thought by default it would be at max speed), and it indeed increased the speed. And increasing SPI clock it indeed increased speed as well. How do I know how much I can increase SPI? For MCU it's in the spec, but SPI I couldn't find, and noticed on another application that increasing speed to much draws screen distorted.
Correct, the max SPI speed (outside of the MCU itself) is per-device spec. Depends on your concrete display, it should be mentioned there.
I also noticed it's possible to initialize spi with or without cs/miso, does that make a difference in performance/correctness of data transfer?
MISO is unused atm. (reads are planned at some point tho), CS only matters if you share your SPI bus with multiple slave devices. Going CS-less technically could increase the speed by a very small margin due to HW "delays" between CS asserts but it'll probably be in nanoseconds per second kind of thing.
How do I know how much I can increase SPI? For MCU it's in the spec, but SPI I couldn't find, and noticed on another application that increasing speed to much draws screen distorted.
The official maximum SPI clock for the ILI9341 is only 10 MHz (see ILI9341 datasheet section 19.3.4), but it normally works with much higher clock rates. Other controllers, like the ST7789, support clock rates up to 62.5 MHz.
I'm closing this issue, in case you feel there's still some problem related to mipidsi
itself and its speed please reopen and add more details.
I was able to port the example 'spi-ili9486-esp32-c3' to esp32 (not c3) with ili9341 240x320 (module that include both ESP32 and display).
The example draws really slow, about 3 sec to clear the screen and another 3sec to draw the smily. Is this how it should be or should I configure something differently. Only thing related to timing I changed was to changed the frequency from 100kHz to 60Mhz as I saw in other code bases for this hw config. With 100kHz it was way way slower. When I increased more than 60Mhz I didn't see any difference.
I know the display is much faster because c++ code I have us pretty fast. But maybe the example should be slow because of how the drawing takes place?