Speeding up the ILI9488 SPI display (esp32)

[mnfisher]

Just playing with the parallel version - and, depressingly - it's quite a bit slower than the SPI version.
The SPI hardware must be very efficient (especially as it's having to write out 50% more data (24 bit cf 16). There may be a way to put the parallel interface into 4 or 8 bit mode?

Something also not right - I only get blue data ( ) Here I do a single cube (with and without modified background) Show orientations and repeatedly clear the display to a random (here read blue) colour. - Note I also got this with the demo program

ILI9488_Ben.fcfx

(241.34 KiB) Downloaded 728 times

Still to get the SD working - more playing later....

Martin

[mnfisher]

It looks as though it might be possible to use i2s to push the data to the display? That would speed things up - if there is a way to get i2s to 'toggle' the write pin.

Martin

[BenR]

Hi Martin,

Have you got the latest version of the ILI9488 component? I pushed some optimisations into it for the display.

Aha I see you're not using the parrallel component and instead rolling your own code. Well then I send out the 16-bit data like this.

Code: Select all

GPIO.out_w1ts = FCL_DAT;    //Write all the 1's
FCL_DAT = ~FCL_DAT;
GPIO.out_w1tc = FCL_DAT;       //Write all the 0's

FCL_DAT is my local 16-bit colour variable I'm sending out.

Display.jpg (59.04 KiB) Viewed 5398 times

It might be worth you trying the component and see if that's any better for you.

Here's the latest optimised component source.

GLCD_ILI9488.fcfx

(239.23 KiB) Downloaded 837 times

It looks like maybe the Flowcode port write code could do with a bit of improvement as currently it does it the recommended (and very slow) way of bit by bit. I'll see if I can use the method I've used in the component for the port writes.

I've also just pushed an update for the ESP32 definitions and the SD Card component to allow you to see/set the SD Mode I/O pins. Probably won't have worked without this as the S3 needs to be told which pins to use.

[mnfisher]

Thanks Ben,

That does indeed make a dramatic difference.. I'm still just getting the blue channel - so a bit more work needed

Yesterday I had a play with the ili9488 component from espressif at https://github.com/atanisoft/esp_lcd_ili9488 - almost got it to work in FC with just a little C code - this mimics the i80 interface (using DMA to write and the i2s hardware?). The initialisation seemed to work, but my attempts at writing the data to display didn't (nothing on the pins)

However - I think this is probably pretty good for now. Just need to cure the case of the blues

I tried two 'versions' of the display macro - writing the data inline (disabled - disable the following two macros if re-enabled) - and, as currently, using Write_Data16_Bus - it's good to localise this, but Display is the only place it's called from.

ILI9488_3.fcfx

(242.92 KiB) Downloaded 856 times

Next to try the new SD component --- Still fails with error 13 (tested with 8 and 128GB cards) -

Martin

[BenR]

Hi Martin,

Aha I know what the all blues are about I've had that too. In your initialise you might just need to ensure you have written to the higher byte using a output icon or similar. Otherwise the higher 8-bits are not defined as outputs.

e.g. your LCD_Write_Data8_Bus defines the lower 8-bits as outputs but not the upper 8 bits.

This is how I do it in the component at the top of the initialise function.

Display.jpg (49.58 KiB) Viewed 5389 times

I can then do the 8-bit command writes in the same high speed optimised way.

[mnfisher]

Thanks - yes that fixed it.

I tried : port_high = 0 which didn't work(?), but output of a8..a15 of 0 and suddenly the world is suddenly a more colourful place!

Marti

[mnfisher]

Slightly more neatly with a loop and

Code: Select all

gpio_set_direction(FCL_I, GPIO_MODE_OUTPUT);

The code manages to clear and redraw the display 5 times for one of the ILI9488 refresh cycles. Repeatedly clearing and displaying a new colour manages 5/6 'stripes' on the display - manages to clear and redraw too fast!

For anyone to play:

ILI9488_3.fcfx

(245.1 KiB) Downloaded 913 times

Now we need a way to check for 'vsync' to draw the next frame

Martin

[mnfisher]

Just tried a 'cube demo' and with the old component - this compiles and draws the cube (albeit (very) slowly).

Then did a library update (of the ILI_9488 component) and can no longer compile:

C:\ProgramData\MatrixTSL\FlowcodeV10\CAL\ESP\ESP_CAL_IO.h:91:78: note: in definition of macro 'SET_PORT_MASK'
91 | #define SET_PORT_MASK(p,m,v) FC_CAL_Port_Out_DDR (p, m, v)
| ^
C:\ProgramData\MatrixTSL\FlowcodeV10\CAL\ESP\ESP_CAL_IO.h:91:79: error: left-hand operand of comma expression has no effect [-Werror=unused-value]
91 | #define SET_PORT_MASK(p,m,v) FC_CAL_Port_Out_DDR (p, m, v)

amongst the many errors. Full database update didn't fix this unfortunately.

cube_test.fcfx

(23.26 KiB) Downloaded 859 times

Martin

[BenR]

Hi Martin,

Thanks looks like there's something up with the port writes that I'll look into for you.

This should hopefully work correctly with the speed optimisation and more importantly compile.

cube_test.fcfx

(23.25 KiB) Downloaded 841 times

As for making the cube spin faster could you instead draw the cube in white, frame delay, draw the cube in black, rotate the cube, repeat. Should be significantly faster then clearing the display each time. I imagine you already know this.

cube.jpg (52.56 KiB) Viewed 5328 times

[mnfisher]

Thanks Ben,

Does indeed compile now (what was I doing wrong?) - good improvement on speed (still a slideshow - keep pushing those improvements :-; )

Have doubts about my fullscreen 'clears' - the 'banding' might be an artefact of something else - though at the moment not sure what - black works AOK though!

Martin