Best driver for ili9341 display

[Minyiky]

Hello everyone,

I am working on a project using an ili9341 display connected to a firebeetle esp32 board and am looking for a good ili9341 driver. I have been using the driver here (https://github.com/rdagger/micropython-ili9341) and the screen is working but incredibly slow, on the order of seconds to fully refresh the screen which seems excessive. I have tried building the lvgl micropython distro but cannot get it to make properly on two different PCs. I also flashed Lobo's build but I the couldn't connect to the board via REPL, I have included the results below:

Screenshot from 2020-11-27 16-34-01.png (58.8 KiB) Viewed 7580 times

Does anyone know of any other options (or what may be going wrong with these) or whether I am simply being unrealistic in my expectations?

Thanks a lot

[pythoncoder]

The Loboris port was abandoned long ago. It's probably best ignored.

Have you considered the SPI baudrate? The ili9341 can handle up to 10MHz for writes, and up to 6.66MHz for reads. If you choose one of the hardware buses the ESP32 can support these rates easily. You may find that speeds things up.

[Minyiky]

Thank you for the feedback, In the code I was using the baud rate was set to 40,000,000, above what you have mentioned, I have tried both lowering to 10,000,000 and increasing to 400,000,000 with no change in performance. As an extreme I set the baud rate much lower and that did indeed slow down the display rate.

It appears I am at the limit of the write speed but the display is still very slow, I am assuming that would be due to inefficient code?

Thanks again for the help

[pythoncoder]

It's hard for me to comment in detail as I haven't used the ili9341. However I have written drivers and a GUI for various other SPI connected displays. This is aimed at smaller displays than those supported by the ili9341. The drivers work by maintaining a frame buffer using the framebuf.FrameBuffer class. When the display is to be refreshed the entire buffer is copied to the display. To minimise RAM use I use 8 bit color. To make matters worse for performance, some displays don't support 8 bit color so conversion must be done "on the fly" when an update occurs.

Typical refresh time with conversion is around 40ms, at baudrates of around 10Mbps (exact figures vary with display type and platform).

If you're seeing times of seconds I therefore suspect that something odd is going on. The ili9341 driver should be more efficient as it uses the native graphics primitives on the chip. My driver for the RA8875 supports large displays in this way, and updates are fast.

It would help if you told us what kind of material you are displaying. Does it use the graphics primitives or are you sending large bitmaps?

I briefly looked at the ili9341 driver and, while I can see possible optimisations, I can't see anything which might explain such excruciating refresh delays. I would set about pinning down where the time is being spent. You might want to adorn methods in the driver with this decorator to pin down where the time is going.

I wouldn't use baudrates higher than 10MHz: this is the datasheet maximum.

[Minyiky]

Thank you for your detailed response, I had indeed seen your GUI before and it looked perfect if not for the display drivers.

I have done some investigation and timed some functions, it looks like the limitation is potentially to do with how the data is being sent, not making use of the frame buffer class but rather manually being sent over as chuncks.

Timing the display.clear() function gets a time of about 1100ms to write a completely black screen. Results are worse when looking at displaying an image. I am taking one of the RAW images from the repo which are preconverted pngs and so there shouldn't be any conversion needed at write time. When writing one to fill the screen I get a write time of 2680ms, over 2.5 seconds, which is a far cry from the 40ms you get, even allowing for the factor of a larger display.

I am very new to working with SPI displays so could be completely missing something but I appreciate the help you are offereing. How much work has to go into each of the drivers / would it be feasable for me to work on creating a driver to work with your GUI with some learning?

Edit:

I have been doing some more testing and was trying to get framebuf working, however I do not seem to have enough ram to store the buffer. On a fresh boot with no code running I am only seeing 105KiB free (the board specs say 512KiB RAM) while the buffer size would be 153KiB. Do you know of a way to work around this?

[pythoncoder]

I am currently actively considering supporting the ili9341, but there are issues.

These displays are too large for use with framebuf.FrameBuffer because of the size of the necessary buffer. The chip needs a dedicated GUI like my touch GUI for the official LCD160CR display. That is more involved than adding a driver to nano-gui as it needs to interface the chip's built-in graphics primitives to render the GUI widgets.

Further, the point in considering the ili9341 is to provide a touch interface; nano-gui with its super simple display drivers is strictly for small, non-touch displays.

And therein lies the rub, because the ili9341 does not support touch directly. Suppliers add touch overlays with different characteristics and interfaces.

Consequently, unlike my other touch GUIs, I would need to specify the exact type of touch overlay supported. My personal preference is for this unit which has a capacitive overlay with a sensible interface. Adafruit's resistive ones involve analogue signals and require the use of ADC's. This limits their utility on some platforms. Other suppliers may use different overlays and touch controllers.

Whatever choice I make will limit the appeal of my efforts to people prepared either to use the same model of display or to adapt my code for their unit. I find myself wondering whether this is worth pursuing.

I would point out that my GUI efforts are not suited to showing pictures. For performance and other reasons widgets use graphics primitives rather than icons. The only bitmap drawing is for rendering text and uses methods heavily optimised for minimal RAM use. Glyphs are 1-bit bitmaps - a pixel is on or off, with color supplied by the GUI code. My point here is that it's specialised and can't be generalised to rendering full-color bitmaps. If your requirement is to render PNG files I think you are best off ignoring my work and seeing what you can do to improve the performance of your existing driver.

[Minyiky]

It is interesting to hear that you are looking into support for ili9341 but am beggining to understan the difficulties involved.

I also understand what you mean about addiung touch support, I see a lot of displays with them, especially ili9341 ones, alhough for the project I am working on I don't need touch input and so luckily is not something I am having to worry about. Just as a reference the display I am using is the 2.2inch from adafruit.

In terms of suitability, I am not actually looking to display images (it was just a very easy test to run), the display would largely be text based with a few simple shapes and ideally a way of displaying a graph as well as a dial, both of which I believe your GUI has.

I will also certainly keep trying to work on the code I am using to see if I can make it any quicker.

[pythoncoder]

That display is too large to support in nano-gui. The frame buffer - with on-the-fly conversion - would require 320*240/1024=75KiB of contiguous RAM. I think your only practical option is the one you are taking, but I would be interested to know the outcome. Rendering seems unreasonably slow and it would be good to know the cause.

Graphics primitives and text rendering should be very quick...

[Minyiky]

I have been doing some work and have managed a solid rectangle to display in ~45ms which is plenty fast enough realistically. the isue is when ots of instructions must be sent, a very stark example of this is a 45 dgreeline vs a horizontal line, a 100 pixel horizontal line is being sent in one instruction loop, whil a similar length diagonal would take 100, and therefore is taking far longer, it would be far quicker to update the entire screen.

Do you know of a simple way around this, all I could think of is breaking down into chuncks, reading the current data in a rectangle around that chunk, and then updating it as a rectangle. I don't know if this is the best solution though. Alternatively is there a way to send tranparent pixels (I haven't seen anything but may be overlooking something)?

[uCTRL]

I am currently actively considering supporting the ili9341

I hope you do, its a very popular and reasonably good value TFT display.
I have and still am using them a lot in the arduino world, with SPI interface.
AFAIK the most popular touch controller is resistive XPT2046 with SPI interface.
There should be enough example drivers such as circuitpython, arduino, etc.