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

@KurtE - @defragster - @MichaelMeissner

I did try to change the SPI clock down to 12Mhz but still exhibited the same behavior. Even tried at lower CPU clocks with no luck. However, playing around a little more I got it working by adding a single print statement to the eye movement loop, and fixed the whole issue
I would suspect just having a delay would work. Unless there is something else that the print does (perhaps turn on/off interrupts clears something).

When I had neopixels and the prop shield hooked up together with uncanny eyes, I found I needed to add a small delay between switching pins 11/13 between SPI mode and normal pin mode or else the first neopixel LED would stick.
 
@mjs513 @defragster

As mentioned something real screwy!

FYI - I have been playing around a little with (IF I made a RPI form factor board ;) ) What would I put on it...

I think I would strip off most everything of my other board...

Maybe optional power plug, VR (DC DC Converter) Switch to choose. All of the pins broke out with Row of pins on both sides of T4...

Plus RPI connector... I have one started ;) But the interesting thing is to figure out What T4 pins should route to RPI pins.

If you go off the RPI 40 pin connector: Interesting interactive site for pins: https://pinout.xyz/pinout/pin1_3v3_power#

You have 40 pins:
8 GND
2 +5v
2 3.3v pins
Which leaves: 28 possible IO pins.

You want:
KeDei - 19, 21, 23, 24, 26 - To be SPI pins Example: 11,12,12,10,9

If I want to try out the RaspiAudio board I mentioned, it shows I think what pins it uses: https://www.raspiaudio.com/raspiaudio-aiy
Which includes some I2S.

UART: I know I want pins 8, 10 to be UART - Not sure if Serial 1 or not.

I2C (Wire): Probably want pins 2-3 probably going to 18 and 19

They also mention EEPROM wire on pins 27,28..

PWM pins?
 
I would suspect just having a delay would work. Unless there is something else that the print does (perhaps turn on/off interrupts clears something).

When I had neopixels and the prop shield hooked up together with uncanny eyes, I found I needed to add a small delay between switching pins 11/13 between SPI mode and normal pin mode or else the first neopixel LED would stick.

@MichaelMeissner

The first thing I tried before playing with putting back the print's what to add a delay where the Serial.prints were, tried 5ms but no luck so something else going on that's screwy, that's why I tried to isolate it and see what would fix it even if its only fixing the symptom and not the actual problem.

As for the delay between pin switching I don't think that would cause us to loose USB on startup?

@KurtE and others - for now I am done with trying to figure out whats going on with uncannyeyes with the ST7735's going to try SSD1351's next. The fix may be above my pay grade :)
 
@mjs513 @defragster

As mentioned something real screwy!

FYI - I have been playing around a little with (IF I made a RPI form factor board ;) ) What would I put on it...

I think I would strip off most everything of my other board...

Maybe optional power plug, VR (DC DC Converter) Switch to choose. All of the pins broke out with Row of pins on both sides of T4...

Plus RPI connector... I have one started ;) But the interesting thing is to figure out What T4 pins should route to RPI pins.

If you go off the RPI 40 pin connector: Interesting interactive site for pins: https://pinout.xyz/pinout/pin1_3v3_power#

You have 40 pins:
8 GND
2 +5v
2 3.3v pins
Which leaves: 28 possible IO pins.

You want:
KeDei - 19, 21, 23, 24, 26 - To be SPI pins Example: 11,12,12,10,9

If I want to try out the RaspiAudio board I mentioned, it shows I think what pins it uses: https://www.raspiaudio.com/raspiaudio-aiy
Which includes some I2S.

UART: I know I want pins 8, 10 to be UART - Not sure if Serial 1 or not.

I2C (Wire): Probably want pins 2-3 probably going to 18 and 19

They also mention EEPROM wire on pins 27,28..

PWM pins?

Yeah - was thinking about modifying my display breakout board to accommodate the Pi header but didn't get there yet. Not really familiar with the Pi pinouts but for pwm - saw there are 3 PWM pins not sure which those would go to but there are several open pins that you could put a couple analog on as well as other serial?
 
@defragster @mjs513 - Second KeDei display arrived today, looks identical to other one I have. Both have R2 and not R1.
I moved the jumpers from the other display to the new one and touchpaint looks the same. :D
 
@mjs513 @defragster

As mentioned something real screwy!

FYI - I have been playing around a little with (IF I made a RPI form factor board ;) ) What would I put on it...

Here is a pinout of the standard Pi 40 pin layout

I think I would strip off most everything of my other board...

Maybe optional power plug, VR (DC DC Converter) Switch to choose. All of the pins broke out with Row of pins on both sides of T4...

Plus RPI connector... I have one started ;) But the interesting thing is to figure out What T4 pins should route to RPI pins.

If you go off the RPI 40 pin connector: Interesting interactive site for pins: https://pinout.xyz/pinout/pin1_3v3_power#

You have 40 pins:
8 GND
2 +5v
2 3.3v pins
Which leaves: 28 possible IO pins.

You want:
KeDei - 19, 21, 23, 24, 26 - To be SPI pins Example: 11,12,12,10,9

If I want to try out the RaspiAudio board I mentioned, it shows I think what pins it uses: https://www.raspiaudio.com/raspiaudio-aiy
Which includes some I2S.

UART: I know I want pins 8, 10 to be UART - Not sure if Serial 1 or not.

Serial1 might be the logical choice.

I2C (Wire): Probably want pins 2-3 probably going to 18 and 19

Yes, you probably would want to connect these to 18 and 19. IIRC, you might need pull-up resistors for i2c.

They also mention EEPROM wire on pins 27,28.

Thats a second i2c bus that is reserved for talking to the hat firmware. When I last looked at the Pi (maybe 2 years ago), they prohibited stacking more than one hat.

PWM pins?
Pi has 2 PWM pins (pins 32 and 33).

Pi also has a second SPI setup, pins 19-21.

Pi does not have analog support through the pins.

Adafruit makes a perma proto that has 24C32 I2C EEPROM soldered to the board that you can set to identify as a Rasberry Pi hat:
 
@defragster @mjs513 - Second KeDei display arrived today, looks identical to other one I have. Both have R2 and not R1.
I moved the jumpers from the other display to the new one and touchpaint looks the same. :D

Glad it worked - that is all we needed if it didn't :) wonder what would happen if there were no resistors - oh forget I said that :)
 
@KurtE - I know the feeling - once you start something you don't want to stop until it works :)

@defragster - I just made up a board yesterday and ordered them to test tri-state to see if it works. Probably won't get them until the end of the week to test.
View attachment 16436

If you want one to play with I send a couple when I get them - @KurtE if you want I can send a couple to you as well.

Excuse me. Is this board work for display and touch screen in the same time with teensy 3.6. I'm still have problem with it
 
As indicated in the thread - some do and some don't depending on wiring.

Not sure which version is there without pictures or product link.
 
Hi guys,
I'm looking to completely redesign my half dozen or so Teensy prototyping systems (with the impending arrival of the T4) and these will include a new display. I've been trying to follow this thread, but I have to admit I'm totally confused:
1) Is the library ready for "prime-time"? Or are there still serious gaps that make it still truly alpha/beta? I can work with (and help debug) minor issues, but I need to concentrate on the my applications coding...
2) Is there a recommended board(s) yet? I see a lot of discussion that some seem to work and some don't. Not much point in throwing money away ;)

Derek
 
Hi @DerekR,

There are several different conversations about different displays up on this thread:

The hopefully reasonably standard ILI9488 boards (not sure yet how different ILI9486 are).

Hardware: Some of these boards appear to probably have tristate on the MISO pin and some don't, i.e. they don't work well with other SPI devices. Which I believe includes the aliexpress. Some may have it. And of course some of them have different touch screen options.... So different libraries and the like would need to be used depending...
Which is why @mjs513 created a simple tristate board...

Software(https://github.com/mjs513/ILI9488_t3): I believe was working pretty well. It has most everything of my ILI9341_t3n, including frame buffer, Asynchronous updates, ... with some caveats.

Note: at one time @PaulStoffregen was looking into producing or sourcing a board. Not sure if that is a possibility or not.

a) There is no way (that I know of) to use 16 bit colors with these displays in SPI mode. So we map colors from 16 bits to 18 bits, when we do graphic operations. So while on ILI9341 when we output a color: it is 16 bits that get sent over SPI(565 format). But for these displays it is 24 bits that get sent. This also implies by simple calculations that updating the display takes a lot longer than ILI9341. 320x240*2=153600 to 320x480*3=460800 (i.e. 3 times slower)

b) Currently the software in frame buffer mode, is using sort of a built or defined color pallet as, up until T4 (beta 2 board), there was not enough memory on any board to easily make frame buffer. And to do dma to these devices I am needing to do some extra work to make them work. That is I have the Frame buffer, then I define two buffers to use with DMA, where 32 bits per pixel, and then the DMA code round robins between the two, and the DMA isr, when it completes one of these buffers, goes out and translates the frame buffer values through the pallet to fill in the buffer again with the next set of pixels....

...

Again this software so far is mainly been done as an experiment and while I believe things are working well, there could be issues. As with all things no guarantees of anything... But I am pretty sure that several of us will try to resolve issues if you run into them.


Then there is the KeDei RPI boards V6.3

Hardware:
A really strange beast. You can get them pretty cheap: https://www.ebay.com/itm/263427102486
Again same size display as ILI948x boards, but they are screwy! That is instead of having the display with normal display processor doing SPI, it uses 3 shift registers. It also has an XPT2046 chip on board. This communications with this board are really screwy. If you want to know more details, they are scattered in this thread. Some of which are in the readme file of my github project: https://github.com/KurtE/KeDeiRPI35_t3

Software(https://github.com/KurtE/KeDeiRPI35_t3) : We probably spent 10 times as much time as these displays warrant. But we were too stubborn to give up.

a) They are slow! That is for each thing we actually output, they are 4 bytes output and for each of these 4 byte groupings, we have to pulse the Touch screens Chip select pin, so we can not buffer these in FIFO queue.

b) as such while we started from the ILI9488 code above, it does not support the asynchronous updates (DMA), As sort of pointless, as would probably have to interrupt for each pixel....
 
Apologies if this has already been discussed - has anyone tried the new Adafruit IPS LCD with this library? https://www.adafruit.com/product/4311

I'm in a similar situation to DerekR... with T4 coming, I want a better display for my application, and I am considering this library and display combination. I guess I will know soon enough since I've ordered one of the displays to test with.
 
Apologies if this has already been discussed - has anyone tried the new Adafruit IPS LCD with this library? https://www.adafruit.com/product/4311

I'm in a similar situation to DerekR... with T4 coming, I want a better display for my application, and I am considering this library and display combination. I guess I will know soon enough since I've ordered one of the displays to test with.

Nope, I don't have one yet ;) Also not sure where I can order from... Adafruit does not send to mailbox.... And don't see it yet up on Amazon, or Digikey, or Mouser ...

Obviously should work with the Adafruit_ST7735/89 library.

As for our version, maybe not yet. Would need to see what they do different with the init code. Most of the rest should work the same.
 
Nope, I don't have one yet ;) Also not sure where I can order from... Adafruit does not send to mailbox.... And don't see it yet up on Amazon, or Digikey, or Mouser ...

Obviously should work with the Adafruit_ST7735/89 library.

As for our version, maybe not yet. Would need to see what they do different with the init code. Most of the rest should work the same.

There is an ebay seller in Berlin that has some of the square version of the display (240x240), but I don't see the new 320x240 display yet. I don't know if they send to a mailbox:

That display is also at digikey:
 
There is an ebay seller in Berlin that has some of the square version of the display (240x240), but I don't see the new 320x240 display yet. I don't know if they send to a mailbox:

That display is also at digikey:

Thanks Michael,

Yep - I already have the one from 240x240 by Adafruit (through Digikey).
Mouser also has the square one: https://www.mouser.com/ProductDetai...r3BLCQWqPFUpLnJOdOn9IjqbAfWumrDKDAwnSRq95Gg==
Amazon: https://smile.amazon.com/Adafruit-240x240-Angle-Display-MicroSD/dp/B07D95V2V5/


But so far I have not found any with the 240x320 version. Hopefully soon.
 
I've played around with a couple of ILI9488 displays with the parallel interface and the UTFT display library. I bought an SPI display but have been traveling for most of the last month and have only had time to unpack it from the box. I'm just now getting ready to try it out with your ILI9488_t3 library. I anticipate that the SPI interface is much slower than the 8/16-bit parallel interface. Is there any interest on integrating a parallel interface capability into the ILI9488_t3 library?
Thanks!
 
Initial testing with the Adafruit 2.0" IPS LCD is extremely positive. It's blazing fast on T3.6.

I believe GraphicsTest.ino should be utilizing the whole screen, but there seems to be a chunk off to the side that does not get drawn to. Adafruit's library seemingly had the same problem.

Colors are off as well. Link to a picture to hopefully explain better: https://imgur.com/a/aNpXTVB

This display looks great in person. If I can tame the issues, this could be the solution I need.

Edit: defines changed to:
#define ILI9341_TFTWIDTH 320
#define ILI9341_TFTHEIGHT 240

And it is playing much more nicely.
 
Last edited:
I think I have the color sorted as well. In ILI9341_t3.cpp, I changed line 275 from:

writedata8_last(MADCTL_MX | MADCTL_BGR);

to:

writedata8_last(MADCTL_MX | MADCTL_RGB);

And made sure to include "tft.setRotation(0);" in my code so the above line is executed, and boom, the #defined colors are correct now. I'll have to try bitmaps later.

Question: Do I understand correctly that DMA *is* working on T3.6?
 
@wcalver

Not 100% sure what display you are using. The only thing I saw posted was a link to this display https://www.adafruit.com/product/4311 which uses a ST7789 chip as the driver as @MichaelMeissner pointed out in post #489. If that is the display you are using you better switching to that driver. @KurtE has it working on the 240x320 display (dma still a work in progress with that chip but it does work). See this post for the link to the GitHub repository
 
@wcalver

Not 100% sure what display you are using. The only thing I saw posted was a link to this display https://www.adafruit.com/product/4311 which uses a ST7789 chip as the driver as @MichaelMeissner pointed out in post #489. If that is the display you are using you better switching to that driver. @KurtE has it working on the 240x320 display (dma still a work in progress with that chip but it does work). See this post for the link to the GitHub repository

This is indeed the display I'm using. Over the weekend I was able to compile and use the ILI9341_t3n library to pretty good success. As far as I can tell, the frame buffer is being allocated and DMA is being used to update the display. When I originally posted, I didn't realize there were both ILI9341_t3 and ILI9341_t3n libraries, hence my confusion.

Great job to Kurt and any other contributors. I can't wait to see how it runs on the T4!! :)
 
Back
Top