ILI9488_t3 - Support for the ILI9488 on T3.x and beyond...

@...

Started doing the above update for the counted version (changed in fillRect, HLine, VLine, and drawFastH/VLine...

Now running it on TLC:
Code:
Benchmark                Time (microseconds)
Screen fill              2182109
Text                     163683
Lines                    1921780
Horiz/Vert Lines         179702
Rectangles (outline)     109453
Rectangles (filled)      5472139
Circles (filled)         1656675
Circles (outline)        1144773
Triangles (outline)      527821
Triangles (filled)       1987452
Rounded rects (outline)  381047
Rounded rects (filled)   6124822
Done!
Showing some improvements from above...
Pushed up WIP to TLC_And_Others_Speedups...

Actually if you compare the timings versus the current master branch:
Code:
Benchmark                Time (microseconds)
Screen fill              8222049
Text                     141225
Lines                    1512162
Horiz/Vert Lines         693357
Rectangles (outline)     381698
Rectangles (filled)      22552883
Circles (filled)         2440288
Circles (outline)        1344817
Triangles (outline)      334055
Triangles (filled)       6792542
Rounded rects (outline)  638986
Rounded rects (filled)   22217715
It is a little more dramatic.
 
Teensy 3.2 timings:

Current Master:
Code:
Benchmark                Time (microseconds)
Screen fill              1125906
Text                     22806
Lines                    194702
Horiz/Vert Lines         98556
Rectangles (outline)     52773
Rectangles (filled)      2722081
Circles (filled)         320964
Circles (outline)        191968
Triangles (outline)      45565
Triangles (filled)       880293
Rounded rects (outline)  94748
Rounded rects (filled)   3018257

WIP - Have not inlined functions yet but using the counted write16...
Code:
Benchmark                Time (microseconds)
Screen fill              916442
Text                     22186
Lines                    185441
Horiz/Vert Lines         74216
Rectangles (outline)     40873
Rectangles (filled)      2217830
Circles (filled)         274170
Circles (outline)        190159
Triangles (outline)      42772
Triangles (filled)       673674
Rounded rects (outline)  84186
Rounded rects (filled)   2406312
Done!
 
@KurtE - @defragster

Guess these would be baseline timings for T3.x and T$
Code:
[B]T$[/B]
Benchmark                Time (microseconds)
Screen fill              734499
Text                     16411
Lines                    211365
Horiz/Vert Lines         62177
Rectangles (outline)     34664
Rectangles (filled)      1775576
Circles (filled)         232640
Circles (outline)        178364
Triangles (outline)      45409
Triangles (filled)       564945
Rounded rects (outline)  74147
Rounded rects (filled)   1951860
Done!

Code:
[B]T3.2[/B]
Benchmark                Time (microseconds)
Screen fill              1125924
Text                     22799
Lines                    194697
Horiz/Vert Lines         98556
Rectangles (outline)     52774
Rectangles (filled)      2722062
Circles (filled)         320962
Circles (outline)        191968
Triangles (outline)      45569
Triangles (filled)       880304
Rounded rects (outline)  94743
Rounded rects (filled)   3018250
Done!

Code:
[B]T3.5[/B]
Benchmark                Time (microseconds)
Screen fill              1027245
Text                     18863
Lines                    159271
Horiz/Vert Lines         80375
Rectangles (outline)     45535
Rectangles (filled)      2482100
Circles (filled)         269807
Circles (outline)        157316
Triangles (outline)      36520
Triangles (filled)       695693
Rounded rects (outline)  77324
Rounded rects (filled)   2683266
Done!

Code:
[B]T3.6 (Teensy64)[/B]
Benchmark                Time (microseconds)
Screen fill              730910
Text                     13957
Lines                    136735
Horiz/Vert Lines         59114
Rectangles (outline)     32613
Rectangles (filled)      1766754
Circles (filled)         202309
Circles (outline)        126649
Triangles (outline)      30773
Triangles (filled)       530764
Rounded rects (outline)  59396
Rounded rects (filled)   1912628
Done!
 
Thanks Mike,

I just pushed up to the TLC_And_... branch changes for KinetisK - moved stuff to be inlined plus the change for reducing color conversions...
In case anyone wants to try them on T3.x boards...

Current timing on T3.2 is:

Code:
Benchmark                Time (microseconds)
Screen fill              915902
Text                     20976
Lines                    182761
Horiz/Vert Lines         74050
Rectangles (outline)     40831
Rectangles (filled)      2216187
Circles (filled)         263130
Circles (outline)        174230
Triangles (outline)      41050
Triangles (filled)       668732
Rounded rects (outline)  79863
Rounded rects (filled)   2401543
Not as dramatic as TLC, but still not too bad.

Next up try the T4, again Move functions to header...
 
T4 changes done - Did not notice any differences in speed...
Moving more of the TLC stuff back over to header last speed test:
Code:
Benchmark                Time (microseconds)
Screen fill              2145532
Text                     257228
Lines                    3512514
Horiz/Vert Lines         186286
Rectangles (outline)     120870
Rectangles (filled)      5389336
Circles (filled)         2317337
Circles (outline)        2550341
Triangles (outline)      834965
Triangles (filled)       2283635
Rounded rects (outline)  763143
Rounded rects (filled)   6250006

I ran on T3.5 and some reasonable speed ups I think
Code:
Benchmark                Time (microseconds)
Screen fill              732370
Text                     16914
Lines                    149756
Horiz/Vert Lines         59244
Rectangles (outline)     32673
Rectangles (filled)      1771869
Circles (filled)         210503
Circles (outline)        141709
Triangles (outline)      33717
Triangles (filled)       535282
Rounded rects (outline)  64518
Rounded rects (filled)   1920309

Next up check in the last part, maybe combine changes and Do PR

Created PR: https://github.com/mjs513/ILI9488_t3/pull
 
T4 changes done - Did not notice any differences in speed...
I am seeing a bunch of speed improvements - maybe not as much as the TLC but still a bit of a change.

Whenever you want to do the PR that's fine. Now I have to change the comments that the lib supports the TLC as well. :). Didn't mention anything that you could use the ILI9341 as well and the lib should work.
 
not sure if this was wrong or got missed - as it seems to allow 2 byte color transfer ?

Would be so nice if the 9488 would get into 2 byte color mode to reduce the SPI xfer!
I find this in the recently linked ili9488-unlocked.pdf:
4.9. DSI Transmission Data Format
4.9.1. 16-bit per Pixel, Long Packet, Data Type 00 1110 (0Eh)
Packed Pixel Stream 16-Bit Format is a Long packet, used to transmit image data formatted as 16-bit pixels to a
Video Mode display module. The packet consists of a DI byte, a two-byte WC, an ECC byte, a payload of length
WC bytes and a two-byte checksum. Pixel format is red (5 bits), green (6 bits), and blue (5 bits), in that order.
...
 
Thanks - Later may try some more updates - to counted outputs.
Some areas that I am looking at include text output...

May also try a few hacks, like Suppose I change write16BitColor:
Only showing the LC...

Code:
uint16_t last_color = 0;
uint8_t r = 0;
uint8_t g = 0;
uint8_t b = 0;

void ILI9488_t3::write16BitColor(uint16_t color, bool last_pixel){

  setDataMode();

  if (color == last_color) {
      outputToSPI(r);
      outputToSPIAlready8Bits(g);
      outputToSPIAlready8Bits(b);
  } else {
      r = (color & 0xF800) >> 11;
      r = (r * 255) / 31;
      outputToSPI(r);
      g = (color & 0x07E0) >> 5;
      g = (g * 255) / 63;
      outputToSPIAlready8Bits(g);
      b = color & 0x001F;
      b = (b * 255) / 31;
      outputToSPIAlready8Bits(b);
      last_color = color;
  }      
  if (last_pixel) {
      waitTransmitComplete();
  } 

}
I would obviously change the name of the variable... They could be static or member (probably member)... Again not sure if this will speed it up much..
But might also speed up the frame buffer output functions as well... Especially given there are often lots of the same color...
 
That could add up. So can 153K conditionals?

Code:
void ILI9488_t3::write16BitColorLastPixel(uint16_t color){ // new method
     write16BitColor(uint16_t color);
     waitTransmitComplete();
}

void ILI9488_t3::write16BitColor(uint16_t color){ [U]// , bool last_pixel){[/U]
  // ...
[U]// no last pixel test
//  if (last_pixel) {
//      waitTransmitComplete();
[/U]}

May not be that simple with all the variants? But quick look seems it does the normal - then : waitTransmitComplete();
 
On my last ideas - I think I will punt for now... Example with Fonts, the number of pixels to output at at time in one color is pretty small, so did not help
Also checking for pixels same color did not help...

Probably wait for new shiny thing to do more here.
 
@KurtE

Was going back through the SPI changes you made to test for the spi port. Can you explain to me what the heck these lines are doing:
Code:
 	uint32_t *pa = (uint32_t*)((void*)spi_port);
	_spi_hardware = (SPIClass::SPI_Hardware_t*)(void*)pa[1];
    #ifdef KINETISK
	_pkinetisk_spi = (KINETISK_SPI_t *)(void*)pa[0];
Guess I am at a loss of what pa[0] and pa[1] is suppose to be.
 
It is a really bad hack!

I wanted access to the internals of the SPI class. And for example the KINETISK version starts off the data associated with it, defined like:
Code:
private:
	KINETISK_SPI_t & port() { return *(KINETISK_SPI_t *)port_addr; }
	const SPI_Hardware_t & hardware() { return *(const SPI_Hardware_t *)hardware_addr; }
	void updateCTAR(uint32_t ctar);
	uintptr_t port_addr;
	uintptr_t hardware_addr;
	uint8_t miso_pin_index = 0;
	uint8_t mosi_pin_index = 0;
	uint8_t sck_pin_index = 0;
	uint8_t interruptMasksUsed = 0;
	uint32_t interruptMask[(NVIC_NUM_INTERRUPTS+31)/32] = {};
	uint32_t interruptSave[(NVIC_NUM_INTERRUPTS+31)/32] = {};
	#ifdef SPI_TRANSACTION_MISMATCH_LED
	uint8_t inTransactionFlag = 0;
	#endif
So the first uint32_t is the port_addr variable, the second one was the hardware_addr.

I was concerned at first the first pointer might be vtable, but there are no virtual functions...
So the first line: uint32_t *pa = (uint32_t*)((void*)spi_port);
Just casts our pointer of which SPI object we are using to be a pointer to uint32_t...

So if you look at where SPI0 as defined: SPIClass SPI((uintptr_t)&KINETISK_SPI0, (uintptr_t)&SPIClass::spi0_hardware);
And assuming we are using SPI object

Then the next line was out of order: spi_hardware = (SPIClass::SPI_Hardware_t*)(void*)pa[1];
But had same class type common to all three versions of the class, so in our case it returns the pointer: &SPIClass::spi0_hardware

Then the next line: _pkinetisk_spi = (KINETISK_SPI_t *)(void*)pa[0];
It returns the first 32 bits value of the data associated with SPI object and casts to the KINETISK_SPI_t * which again was passed in to the constructor: &KINETISK_SPI0

Again a real HACK!
 
@KurtE

Figured you wanted access to SPIclass but never in a million years would I have figured out that was what was going on. Going to have to absorb this now :)
 
Not Sure, I have a different version of the board that only has the 20 pin connector... Actually wondering if it (the board I have) is actually compatible with the Arduino Mega boards...

But I think some might find interesting a part of their description for the board:

The pin32 (SDO) of 3.5 display module is also used by touch panel or SD card SPI interface, so we must cut off this pin to avoid conflict with the touch panel or SD card.
 
Wondering if I should pick up a second one of these displays...

Again wondering which version people are using?

Ebay?

BuyDisplay.com? Like this link: https://www.buydisplay.com/default/arduino-3-5-tft-lcd-touch-shield-serial-spi-example-for-mega-due
Was mentioned in a different thread...

Hi All,
I've been watching your posts over the past several weeks and decided to order this display a couple of weeks ago. According to the tracking info, it just arrived in Chicago so it should be here in the next couple of days. According to page 13 of the spec sheet (https://www.buydisplay.com/download/manual/ER-TFTM035-6_Datasheet.pdf) it has the serial SPI interface as well as multiple 8080 parallel interfaces. I'm anxious to try out some of your examples using my t3.6. Will let you know when I have it running. Meanwhile any pointers you might offer are appreciated.
Thanks,
Will
 
Wondering if I should pick up a second one of these displays...

Again wondering which version people are using?

Ebay?

BuyDisplay.com? Like this link: https://www.buydisplay.com/default/arduino-3-5-tft-lcd-touch-shield-serial-spi-example-for-mega-due
Was mentioned in a different thread...

Kurt,
My card came in yesterday. Unfortunately the LCD card has soldered jumpers that configure it to the shield that came with it. I had an old DUE that I was to use with it so I know it works. I could probably retrofit it but decided instead to order another card. There may be a way that I can interface my T3.6 to it but so far, no luck. If you look carefully you will see a link entitled, "For people who want the same screen but not in a shield, check out our 3.5" TFT breakout." I ordered a second LCD card this morning configured for 4-wire SPI. Should receive it in a couple of weeks.
Best,
Will
 
Hi,

Just for reference, I've used few ILI9488 from BuyDisplay and they work very well. But, the interface is // 8 bits.

BUY DISPLAY LINK

For curiosity, I ran the benchmark and got those numbers:

Code:
Screen fill	                    85561
Lines	                        63494
Horiz/Vert Lines	                6834
Rectangles (outline)	        3983
Rectangles (filled)	        208802
Circles (filled)	                40570
Circles (outline)	                52847
Triangles (outline)	        12858
Triangles (filled)	        41867
Rounded rects (outline)	16930
Rounded rects (filled)	        227683

NOTE: You can find the ILI9488 specification in v100 revision from Iliteck

Thanks!

Joel
 
Hi,

Just for reference, I've used few ILI9488 from BuyDisplay and they work very well. But, the interface is // 8 bits.

BUY DISPLAY LINK

For curiosity, I ran the benchmark and got those numbers:

Code:
Screen fill	                    85561
Lines	                        63494
Horiz/Vert Lines	                6834
Rectangles (outline)	        3983
Rectangles (filled)	        208802
Circles (filled)	                40570
Circles (outline)	                52847
Triangles (outline)	        12858
Triangles (filled)	        41867
Rounded rects (outline)	16930
Rounded rects (filled)	        227683

NOTE: You can find the ILI9488 specification in v100 revision from Iliteck

Thanks!

Joel
Hi Joel,

My display is configured for 16-bits. I hooked it up to the Arduino DUE and the display looks great. Instead of trying to modifying the display I ordered a second one configured for the serial interface. I thought that, since I had it, I'd try driving it with a T36 using the 16-bit interface. The first step is building the interface. This is as far as I gotten so far.
image1.jpg
Your performance looks good. When I finish I will share the performance numbers for the 16-bit interface. Anything in the way of software mods you made to the library that you can share with your 8-bit interface is most appreciated. That's my next task.

Thanks!
Will
 
Hi Joel,

My display is configured for 16-bits. I hooked it up to the Arduino DUE and the display looks great. Instead of trying to modifying the display I ordered a second one configured for the serial interface. I thought that, since I had it, I'd try driving it with a T36 using the 16-bit interface. The first step is building the interface. This is as far as I gotten so far.
View attachment 16570
Your performance looks good. When I finish I will share the performance numbers for the 16-bit interface. Anything in the way of software mods you made to the library that you can share with your 8-bit interface is most appreciated. That's my next task.

Thanks!
Will

The 16-bit ILI9488 LCD TFT I purchased from Buy Display came with a demo software based on the UTFT library. Using that library, here is how I defined the T3.6 16-bit interface:
* Data bits were mapped as follows:
* Bit: bit15 bit14 bit13 bit12 bit11 bit10 bit9 bit8 bit7 bit6 bit5 bit4 bit3 bit2 bit1 bit0
* Port: C7 C6 C5 C4 C3 C2 C1 C0 D7 D6 D5 D4 D3 D2 D1 D0
* Pin: 12 11 13 10 9 23 22 15 5 21 20 6 8 7 14 2
*
* Control bits mapped as follows:
* CNTL: RS WR CS RST
* Port: B3 B2 B1 B0
* Pin: 18 19 17 16

Since the display was shipped with a board that plugged directly into a DUE, I decided to use that as my starting point since I had something that worked and to compare it against. I looked at the ILI9488_t3 library but that appears set up only for use with the SPI serial interface. Otherwise I would run the benchmark. Is there a version of that library that supports a parallel interface that someone could point me to?

I copied the lastest version of the UTFT library from http://www.rinkydinkelectronics.com/library.php?id=51, folded in the modifications to the library from Buy Display, modified the library for my configuration, hooked up my ribbon cable interface and was able to run the demo sketches. The display runs fine with the T3.6 running at 240 MHz. The T3.6 was running the UTFT_Demo_480x320 sketch at a 16-bit word update rate of 350 ns. Not surprisingly, it runs about an order of magnitude faster than the DUE.

Tried to upload an updated zip file version of the UTFT library but the upload kept failing. Had to remove the "Documentation" and the "Tools" folders (these are available from the link above) so the zip file would fit. The UTFT library in Teensy is seriously out of date.


Willie

View attachment UTFT.zip
 

Attachments

  • HW_MK66FX1M0.h
    5 KB · Views: 74
Last edited:
Back
Top