ILI9341 Performance Improvements

Ok, it's an old thread, but the question is still remaining ...

@DaveNI nice work with your faster display code!

But there is one problem: when writing text, the background is always white, because of the fact that the call of "getPixel" always returns "(255,255,255)". Is there any solution in sight?

Maybe just replace getPixel with getBgColor()? I think that should probably have the right effect.

I'd be really interested in seeing an updated one of these that works with the 'paletted mode'. Since all the data is stored in internal memory, just the area that changed could be sent to the display.

I wonder whether this is something that the graphics library could help with (keeping track of the area that changed) and then all the LCD libraries with offscreen buffers could take advantage of it.

Unfortunately not ... getPixel tries to achieve the color at the given coordinates x, y, while getBgColor()has no coordinates as parameters at all. The getPixelreturn value is always [255,255,255] not being aware of the selected color format.

I've looked through a dozen sources of different ILI9371drivers in the net - and compared to the implementation the code seems pretty correct. So it's not easy to analyze where the unuseable return values are from. I guess this might be a slightly wrong setting of the display mode, so it returns only the whitecolor.

The issue is that the 9341 driver is one-way - it never actually reads anything back from the 9341 at all (in fact on a few devices I've seen I don't think the MISO pin is connected at all) - so it has absolutely no way of getting the current pixel colour.

It'd be much easier to use the current background colour. After all, presumably you as the programmer know what colour the background will be where you're writing text, and can set it accordingly.

Well, the ILITEK ILI9341 specifications tells us another story - so you think that there are displays in the wild which do not support all the abilities the driver chip provides? This is bad new ... But I do not understand why there are modules available which provides a getPixel(x,y)function - so the function will not work at all, even in the module atatched here by @DaveNI - this is puzzling. But ok, so I will switch to "plan B" ... ;-)

BTW: did I mention that I love the Espruino? Great piece of work ... tiny, easy to handle, extremely flexible ... it's my IoT favorite ...

P.S.: After reading again also in the teensy forum, Paul Stoffregen is claiming that the readPixelfunction will work correctly ... I'll give it a try with my teensy 3.1 ...

Thanks!

I think the ILI9341 itself always work, but you may find that the MISO pin (the output from the ILI9341) isn't connected or even brought out on some displays.

On top of this, the Graphics.createCallback function doesn't allow you to specify a getPixel function at the moment, so it'll never work on Espruino unless you're using one of the boards with LCD support compiled into the chip (like the HY ones). You could write your own getPixel function that doesn't go through Graphics and stick it into @DaveNI's module if you desperately wanted though -but the 'Plan B' is probably more desirable as it's faster (and that's kind of the point of his module).

Check this for reading pixels back. It is correct that the hardware has to be connected of course... ;)

hi,
the ILI9341 needs some performance tweak to allow fast visible feedback after user interaction (button press).
imho the paletted driver is no solution, due to it's very slow .flip(). even when combined with .getModified() there remains the trade off between high memory consumption and low color depth. and mostly it is not necessary to keep the display data all the time in memory.

running just a partial display update, with data generated by Graphics.createArrayBuffer() does the job quite fine.
unfortunately the spi.write() blocks execution until everything sent. this prevents interlacing of drawing and spi output - which would bring some noteable performance boost.

is there any possibility to make the spi.write async?
either with a callback (which allows the app to do some buffer/job managerment), or at least with a simple option "please dont block" (so that the app hands over the buffer and forgets it)?

Hi - which device are you looking at using this on?

I think realistically having async SPI is some way down the priority list because of the complexity of handling DMA on all the different platforms Espruino is supported for, but yes - it would be a really big help in cases like these.

hi - i am using the EspruinoWIFI

Have you had any luck pushing higher bit rates on SPI? The display should be able to take data quite quickly, and the Espruino WiFi should be able to push data out at 10MHz or more?

i am using 5MHz; when setting to anything higher it still works, but does not work faster. seems that the espruino limits the SPI to 5MHZ?

and yes - i am using the connection plan from the official example http://www.espruino.com/ILI9341

I guess it's possible that Espruino struggles to keep the higher speed SPI fully loaded with data. There's an issue open for adding DMA (mainly for non-glitchy neopixels while getting WiFi data), and I just updated it to mention this: https://github.com/espruino/Espruino/issues/1212

I can't promise when I'll have time to do something about it though. At the moment I'm not sure what to suggest - however with the WiFi's extra RAM you could use the paletted version and:

• tweak it to use bigger RAM buffers
  
• Use Graphics.getModified to get the modified area, then drawImage to draw it into a new Graphics instance of the right size and write just that instance to the screen.
  
  

While it would add some delay to the output, it would provide a much smoother, less glitchy update - especially for button presses.

There is just not enough memory available in a regular Espruino envrironment to double the memory the ILI9341 has: 172KB. And that would be needed twice to make a dive and push out changed regions... In other words, this is way beyond the flip-operation-mode resources.

When working on ILI9341 driven displays, the main issue was to have overlay and recreate the are. I resorted to backup the display controller's memory, used the backed up area for some pop-up kind of thing, and then restore the area (see post ). Alternative is redrawing the whole screen if the area is 40+%. The modular UI code I have is enabling this function already. But as everything it is not really snappy. Snappy it would become when using 8..16 parallel data, but that's not really an option, since are talking SPI.