TFT 3.5" display (320x480) ILI9488 or HXD8357D?

True; apologies for hijacking the thread, KurtE.

Back on topic, looking at the datasheet, the signals, timing, and command set seems very similar to ILI9341/ILI9488 (noting that I am mostly looking at the parallel transfer modes, not serial); as if these controllers are intended to be almost interchangeable..

Of course there is bound to be some low-level differences (at the library level, I mean), but a quick look didn't show any significant differences. Personally, I find the differences in the actual panels much bigger than the exact controller used.

(As an aside: I've been looking at certain Buydisplay IPS panels, namely a round 1.28" 240x240 one with a GC9A01 controller, and a 2.8" 240x320 one with ILI9341. They are well documented. The round one uses 4-pin serial/SPI, supports 12, 16 and 18 bits per pixel, and has a very similar command set to ILI9341/ILI9488; might make funny gag shades for parties. The 2.8" 240x320 has both serial and parallel pins to ILI9341 available on the flex cable, including all four IMn pins for transfer mode selection.)

KurtE, is there a particular difference between ILI9488 and HXD8357D, other than the existing library support, that you see?
 
@Nominal Animal - Differences I see between the controllers.

Mainly SPI 4 wire I believe supports 16 bit color mode where as it does not on ILI9488. So implies we can send 2 byte pixel values whereas for ILI9488 you have to send 3... So you cut down number of bytes transferred...

Other functionality appears to be pretty similar. At one point I thought one of them had Hardware horizontal scrolling... But I don't see it now.
 
Quick update: @mjs513 did the work to make a version of my(our) ILI9341_t3n library that works now with this HX... display.
Which is up at: https://github.com/mjs513/HX8357_t3n

I picked up my Adafruit display earlier today and started playing.... So far run graphic test as well as the demosauce examples (fixed a few simple edit changes)...

So far the display is pretty good and is showing the differences in speed as compared to the ILI9488 display as I expected.

Now back to playing
 
Noted, great, and much gratitude @mjs513!

The device I built one of those displays into was originally run with a mega2560, and despite using parallel mode, redraws were agonizingly slow. In contrast the kludge it's running with now using a Teensy 3.5 in place of the Mega the redraws are " okay ", but with the 3.5 i2c running in dma, the screen draws don't interrupt the midi-to-CV functions.

The device is 26 midi continuous controllers and 6 midi to CV channels.

Again, this attention to this display is very much appreciated.
 
Last edited:
@mjs513 added another delta to PR... The later add to ILI9341_t3n where in writeRect you can pass in CENTER, CENTER and it does the simple math of computing how to center the image...

Updated the quick and dirty clock program, which is now Annie Clock...
 

Attachments

  • ST77xx_clock-200211a.zip
    285.2 KB · Views: 77
@KurtE - Just did the merge for the PR fixes so should be up to date. Thanks for testing the changes.
 
@KurtE - were you able to locate this display elsewhere for less than 40 USD? It looks great but price wise....
Also, could you run the gauge test you put together for the 9431? I would love to to see how it compares. We already have a benchmark for the 9488 that you or someone else tested for me a few weeks back.
 
Hello guys
May be I missed it or don’t understand how it works but is not the big selling point of the HX driver the RAM buffer?
I have worked with a number of displays but no ware to the extent you guys have.
I all ways thought the holy grail was a display with a RAM buffer that big enough to draw and display one screen well the application controller is filling RAM with the next screen and just switch.
Really low over head for the application controller and no redrawing issues and life is good?

GeckospotNixie
 
Sorry I have no idea of what the selling points are of the HK...

Some of our work here so far is just playing around. My first thought on these was it would be nice to have a display with the same size and resolution of the ILI9488, which did not require me to send 18 bit color in SPI 4 wire mode. That is 3 bytes per pixel versus ILI94831 and others we can use the 16 bit (565) format and so far got it that far, plus using same code as we used for others so have the same graphic primitives, our own software frame buffer code, which includes the ability to update asynch using DMA... Also not sure how much farther to take this as the only source of these I have seen are from Adafruit and are considerably more expensive than the ILI9488 display.

However if there are features that hardware frames or pages or layer or??? that we are not taking advantage of, that would be great to know, and even better if some one had an example of it, such that we could Pull it in to the driver. The only display/driver that I have played with that had some of this is the RA8875 display where the driver from Sumotoy was setup to work with it. (Still works in our updated version). Note: with RA8875 with the 800x... resolution, you can only use layers if you restrict the display to 8 bit color. With their layers you have the option to tell which layer you are writing to, and then choose how to use the layers. Display one or the other, And, Or, ...

Software Frame buffers - Our code has this setup for many of these drivers. Which one of main points is it is easy to, write your update code and do several graphic primitives without having to worry about flicker and the like and when you are done with your updates, you can tell the system to draw out page. You can do this synchronous or using DMA....

With at at least one of these drivers, I added code for the Asynch, that if you have enough memory, you can play some games to double buffer. That is you can draw out your next page, tell the system to output that page using DMA, then tell the system here is a new frame buffer pointer, draw out your next page, wait until previous DMA has completed, then tell system to output that page, and switch the frame buff pointer back to the original pointer... BUT this code does nothing to keep these pages in sync. That is the code does not, copy the current contents of the one frame buffer to the new one. So either your code needs to do it or simply know it needs fill the whole new frame...

However note: with these larger displays: like HX with 480x320x2bytes per pixel = 307200 bytes, so there are not many of our current processors that have room for two of these buffers. Note: we have/had a version of the ILI9488 code where we setup palette so the frame buffer only has one byte per pixel and as such could use on T4 (beta 1) where we started playing with it which also allows it on T3.5/6... But again single one... Maybe when we have T4.1 with the ability for other memory may try out this double buffering using the other memory....

Again if there are features of the HK8357 that we are not using, it would be fun to know about them!
 
Quick update: @mjs513 did the work to make a version of my(our) ILI9341_t3n library that works now with this HX... display.
Which is up at: https://github.com/mjs513/HX8357_t3n

I picked up my Adafruit display earlier today and started playing.... So far run graphic test as well as the demosauce examples (fixed a few simple edit changes)...

So far the display is pretty good and is showing the differences in speed as compared to the ILI9488 display as I expected.

Jumping in here. I've been looking at the Adafruit display too, and wondered if the 8357 library was ready for prime time. I'm making a 3.5" o'scope (landscape mode) and the displays I've gotten from AliExpress & Ebay stink for viewing angle. Are these Adafruit displays better? I really only need a color palette or 16 bits, but speed is most important.

Also, do you mean that the 8357 is faster or slower than the ILI9488?

EDIT: I'll be using T3.2 not T4. I need the DAC output for some 12 bit crunchy audio goodness.
 
I got my Adafruit display in a few days ago. The size and clarity is so much better than the 2.8" ILI display - I love it!

But I am noticing that sometimes when I update the T4, the screen just goes white. I have to disconnect and reconnect 3v3 from the display to get it to start again.
I even have to toggle power to the whole unit (display and T4) at times.

I have it wired as follows
Code:
#define TFT_DC       9
#define TFT_CS      10
#define TFT_MOSI    11
#define TFT_MISO    12
#define TFT_SCLK    13
#define TFT_RST    255  // 255 = unused, connect to 3.3V
 
Try hooking up and using RST. I usually set it up for pin 8.

That seems to have worked, except I get a snow screen for a few milliseconds at startup. But I can just pull the backlight low at startup and then pull it high after the library initialises
 
Are they any recommended libraries to utilize the resistive touch and SD card slot on this display?

I understand the SD card shares SPI with the display controller, and it also has a touch controller built into it?

I found this touch screen library by Adafruit, but not an SD card library.
 
Just want to raise a possible issue with the HX library in conjunction with Snooze on a T4.0 using a digital pin as a wakeup interrupt.
Snooze will put the Teensy to sleep sleep but the wakeup interrupt does not function. If the display/HX library is not inisilized in the setup, Snooze works as expected.

Should I raise this as an issue on Github or can it be addressed here?
I wouldn't have a clue as to where to begin troubleshooting, but happy to try if guided how to/what to.
 
Back
Top