How about a 3.5 inch 480x320 tochscreen display?

If the day had 48hours I'd really like to try one of these RGB to HDMI or data-to HDMI chips on a T3.6
But that's impossible at the moment. Maybe next year.. i guess at least RGB to HDMI is somehow possible on the 3.6
 
Just taking a peak at the datasheet for the ILI9488, looks like it has Backlight control built in along with a PWM_OUT pin to drive the backlight LED. That would save us from needing a pin to PWM the Backlight. We would just have to add a fet to the breakout.
 
You can also consider the ili9481 displays I am able to control the display with a Teensy 3.5 in 16 bit mode at 65k colors(RGB565). with very fast screen updates.


I able to write all 16 IO pins:

Code:
void ILI9481_t3::setIO(uint16_t data)
{
    // lower 8 bits
    GPIOD_PCOR = 0xFF;
    GPIOD_PSOR = data & 0xFF; // DB 7, 6, 5, 4, 3, 2, 1, 0

    // upper 8 bits
    byte a = data >> 8;
    (a & 0x80) ? (CORE_PIN31_PORTSET = CORE_PIN31_BITMASK) : (CORE_PIN31_PORTCLEAR = CORE_PIN31_BITMASK); // DB_15
    (a & 0x40) ? (CORE_PIN32_PORTSET = CORE_PIN32_BITMASK) : (CORE_PIN32_PORTCLEAR = CORE_PIN32_BITMASK); // DB_14
    (a & 0x20) ? (CORE_PIN29_PORTSET = CORE_PIN29_BITMASK) : (CORE_PIN29_PORTCLEAR = CORE_PIN29_BITMASK); // DB_13
    (a & 0x10) ? (CORE_PIN30_PORTSET = CORE_PIN30_BITMASK) : (CORE_PIN30_PORTCLEAR = CORE_PIN30_BITMASK); // DB_12
    GPIOA_PCOR = 0x3C000;
    GPIOA_PSOR = (a & 0xF) << 14; // DB 11, 10, 9 , 8;
}


I am still trying to make it work in 262k mode though.
 
Last edited:
Waking this thread until a better answer … the T4 Beta thread shows interest in a larger display - the ili9488 is functional on T_3.6 and T4 - but 18 bit color is too many bytes for fast SPI updates - and the with a couple different 9488's under test - some seem to have issues. Touch XPT2036 works - but Display I got like Paul's {p#1470&1473} shows MISO not tristated - so reading Touch means cutting/not connecting the TFT's MISO then it works with write only display. Most recent notes cluttering T4 thread are here XX

The ILI9488's so far all want 18 bit color - if one were 'wired' to accept 8 and/or 16 bit that would drop the RAM/SPI hit - the PDF says it can be selected - but it seems there must be hardware bits set as well that preclude attempts to use 16 bit mode. So a better package is needed - 3.5" would be nice - higher res than 240x320 optional as 320x480 pixels are higher DPI and more numerous. Came across one that "works" on rPi - except it is missing the D/C pin and the PDF didn't show me commands/data working without that control bit?
 
I guess that it it’s time to think about a “Teensy G”, a graphics (sub-)processor which would communicate with whatever “main” Teensy through a simple command set, similar to the gfx libraries and which would then care about rendering, frame buffering and efficient high-speed communication with the TFT, taking all that load away from the principal MCU.
For 320*480, 24bit RGB (thinking for the future) and 8 bit alpha, one frame buffer would take 614400 bits of RAM...
 
Some time ago I collected links of various displays, including displays that have a smart processor on them. Some are a little on the pricey side.

Vizic Technologies

Newhaven Display

Gamedunio

Raspberry Pi controlled display
One option might be to use the Raspberry Pi as the driver. Unfortunately it can at times be hard to source the cheaper, smaller, less power hungry Pi Zero W in quantity (usually it is $5-10 for one at my local Microcenter, but the price goes up if you buy more than one, and in some places only quantity 1 orders are allowed). Lets see:
  • Rasberry Pi Zero W: $10
  • 32GB micro SD card: $4
  • ebay 3.5" resistive touch HDMI 480x320: $20


I suspect the Newhaven displays are probably the best for interfacing with Teensy.
 
The T4 already has a GPU with a fast interface. Paul mentioned a larger variant... my hope is, it has the required pins, then.. even if the GPU is not very powerful - the interface alone would be very helpful.
 
The T4 already has a GPU with a fast interface. Paul mentioned a larger variant... my hope is, it has the required pins, then.. even if the GPU is not very powerful - the interface alone would be very helpful.

Though I imagine there you want to get into having the ability to share memory with the display and/or use more pins in parallel to get around the SPI knothole of serially transferring 1 bit at a time.
 
Without having looked it up, I’d guess that in the meantime, a few TFT controllers with QSPI interface should be available, thus making the bottleneck four times wider...
 
Reviving this for the sake of info from Paul :)

I'm ordering the 3.5" ILI9488 display from buydisplay.com
I'll connect it to an FPC breakout board for testing. I know there are some additional components required such as the driver transistor for the backlight, but I see other components on the 3.2 adapter you built in 2017 and would be interested in seeing a schematic if possible
 
Recently in the team we managed to install a 3.5 "FT813 HD screen, in the Teensy 4. After many hours of unveiling, we were able to link the Greiman SdFat beta library to the James 23X gameduino library, with the idea of ​​using the interface SDIO, as a means to store images, jpg or png, assets, cell arrangements and even videos in avi format with audio.The screen specifically is this: NHD-3.5-320240FT-CSXN-CTP, without using an external power source.

They are somewhat expensive screens, however they have good resolution, are visible under sunlight, moderate consumption and have a 20-pin head that facilitates installation on a PCB. The SPI 1 bus can be configured up to 45 MHz!, in order to activate the display interface.

Esta es la librería adaptada, incluye algunos ejemplos: https://github.com/FT81xMania/GD23ZUTX
 
Recently in the team we managed to install a 3.5 "FT813 HD screen, in the Teensy 4. After many hours of unveiling, we were able to link the Greiman SdFat beta library to the James 23X gameduino library, with the idea of ​​using the interface SDIO, as a means to store images, jpg or png, assets, cell arrangements and even videos in avi format with audio.The screen specifically is this: NHD-3.5-320240FT-CSXN-CTP, without using an external power source.

They are somewhat expensive screens, however they have good resolution, are visible under sunlight, moderate consumption and have a 20-pin head that facilitates installation on a PCB. The SPI 1 bus can be configured up to 45 MHz!, in order to activate the display interface.

Esta es la librería adaptada, incluye algunos ejemplos: https://github.com/FT81xMania/GD23ZUTX

It may have the upside of more GPU power (haven't looked into the details), but at 78 USD and a resolution of 320x240 it's not a relevant option, at least for my project.
 
Tft display w 5 points capacitive screens

Would like to ask the same. @paul, thank you for your consideration


Reviving this for the sake of info from Paul :)

I'm ordering the 3.5" ILI9488 display from buydisplay.com
I'll connect it to an FPC breakout board for testing. I know there are some additional components required such as the driver transistor for the backlight, but I see other components on the 3.2 adapter you built in 2017 and would be interested in seeing a schematic if possible
 
Funny enough, I eventually used an Adafruite HX8357 display for my first prototype, but placed an order for the ILI9488 last week and it's arriving later on today!
I'm looking forward to getting it to work - I'm following this schematic for wiring (Note the pin order is opposite on the buydisplay FPC) - there are minor differences, but the schematics seems pretty inline with the ILI9488 datasheed pin assignment
 
@Rezo - The one of theirs I have I think is one of these: https://www.buydisplay.com/lcd-3-5-...lay-module-optl-touch-screen-w-breakout-board
Don't remember if it has touch on it or not... If I remember correctly I purchased it through EBAY.

Personally I probably prefer the HX8357 over the ILI9488, at least if you are doing communications over SPI (4 pin), as if I remember correctly the HX8357 you can do 16 bit color writes to the screen. Where as the ILI9488 you do 18 bit colors (actually 24 bits) So things like fillScreen take 1.5 times as long.

Also with things like Frame buffer, I did not want to go through all of the work to somehow make the frame buffer to work with 24 bits and DMA, so instead by default it stores as the same 16 bits as the colors we use and then when the screen is updated, it converts the 16 bits to 24 bits to output. If the operation is DMA than, this is done a buffer at a time, first at the start up to fill the first buffers and start up the DMA operation, and then it triggers an ISR when a buffer output is complete, and it converts the next portion of the frame into the buffer... So system overhead there as well.

BUT I do have an option for T4.1 with external memory, where you can setup the Frame buffer for 32 bit pixels. Only 24 bits are used, conversation done when stored and DMA is setup to transfer 32 bits to the SPI.TDR register and SPI configured to transfer 24 bits out... So maybe wasted memory but no system overhead to output over DMA... I keep wanting to cleanup some of this code to allow it be configured by sketch instead of header file options... But I have not done so.
 
@Rezo - The one of theirs I have I think is one of these: https://www.buydisplay.com/lcd-3-5-...lay-module-optl-touch-screen-w-breakout-board
Don't remember if it has touch on it or not... If I remember correctly I purchased it through EBAY.

Personally I probably prefer the HX8357 over the ILI9488, at least if you are doing communications over SPI (4 pin), as if I remember correctly the HX8357 you can do 16 bit color writes to the screen. Where as the ILI9488 you do 18 bit colors (actually 24 bits) So things like fillScreen take 1.5 times as long.

Also with things like Frame buffer, I did not want to go through all of the work to somehow make the frame buffer to work with 24 bits and DMA, so instead by default it stores as the same 16 bits as the colors we use and then when the screen is updated, it converts the 16 bits to 24 bits to output. If the operation is DMA than, this is done a buffer at a time, first at the start up to fill the first buffers and start up the DMA operation, and then it triggers an ISR when a buffer output is complete, and it converts the next portion of the frame into the buffer... So system overhead there as well.

BUT I do have an option for T4.1 with external memory, where you can setup the Frame buffer for 32 bit pixels. Only 24 bits are used, conversation done when stored and DMA is setup to transfer 32 bits to the SPI.TDR register and SPI configured to transfer 24 bits out... So maybe wasted memory but no system overhead to output over DMA... I keep wanting to cleanup some of this code to allow it be configured by sketch instead of header file options... But I have not done so.


I'm willing to try the 9488 just because it's a third of the price, has capacitive touch and they can be ordered as bare displays and not as a shield (I've designed PCBs to surface mount the T4.1 behind the display using SMD header pins to keep a low profile)
I am using the T4 with the HX display but I purchased two T4.1's with the PSRAM chips for the option of a bigger frame buffer for the 9488 - has the library been updated to utilize the extra RAM or is it something still being worked on?
 
has the library been updated to utilize the extra RAM or is it something still being worked on?
Yes and someday yes ;)

That is today, with the library, if you look at the header file you will see:
Code:
//#define ENABLE_EXT_DMA_UPDATES  // This is only valid for those T4.1 which have external memory.
If you uncomment it, then this option is enabled on ALL t4.1s... So it will only work on those T4.1 that have the memory. I HATE these types of options.

Over time, I would like to have an option or sub-class or ??? where you can define if you wish the TFT to use 1 byte 2 bytes or 4 bytes per pixel in the Frame buffer.
Today with T3.5/T3.6, 1 byte is the only option and we have a pallet(Palate) for those of us who are spelling challenged. For T4/T4.1 without extra memory, you can do 1 or 2... With ones with extra memory you have all 3 options.

I can totally understand the price difference, but just wanted to give you a heads up on the speed differences.
 
That is today, with the library, if you look at the header file you will see:
Code:
//#define ENABLE_EXT_DMA_UPDATES  // This is only valid for those T4.1 which have external memory.
If you uncomment it, then this option is enabled on ALL t4.1s... So it will only work on those T4.1 that have the memory. I HATE these types of options.
I understand you - if you can get it to be configurable in the constructor it will make config much easier for the user, but at the moment I think people are competent enough to uncomment that line

Over time, I would like to have an option or sub-class or ??? where you can define if you wish the TFT to use 1 byte 2 bytes or 4 bytes per pixel in the Frame buffer.
Today with T3.5/T3.6, 1 byte is the only option and we have a pallet(Palate) for those of us who are spelling challenged. For T4/T4.1 without extra memory, you can do 1 or 2... With ones with extra memory you have all 3 options.

I can totally understand the price difference, but just wanted to give you a heads up on the speed differences.
So even with the extra RAM and writing more bits at a time its till slower? I guess the only bottleneck is the SPI bus after all. But, I have seen someone here running the 9488 at 80Mhz! I can get the HX to run at 32Mhz at most and it looks exactly the same as it does at 26Mhz. Anything higher, it stops displaying.

Perhaps one of these days someone will be able to get one of these displays running using 16 bit parallel - I guess that will speed things up, and can easily be done with the available digital outputs on the 4.1
I would really love to see a true 24 bit display running without to many peripherals around it, but I don't see that happening anytime soon.
For now, 4 wire SPI will suffice! :)
 

Yes, but without the GPU :D in a perfect world the Teensy would handle that, but the same TFT, yes.

I got to soldering the FPC connector to an Adafruit breakout board - my first time soldering an SMD component and at such a small pitch (0.5mm) - quite proud of myself!
IMG_4166.jpg

And I also created a pinout for the Adafruit/ILI9488 as the pin order is backwards on the ILI9488 :confused:
The even/odd consecutive-opposite numbers was quite confusing TBH but I eventually got it done without a glitch
ILI9488_BREAKOUT_PINS.jpg

Will continue tomorrow and hopefully update that it is working
 
A quick update from my side:

I got the display to work, but it's quite unstable. At first, the pads/pins would start crackling and smoking as soon as I'd power it up, and this happened only on adjacent 3v3/GND pins. This would also cause the backlight to flicker as there seems to be excessive current draw from what I suspect are micro solder shorts on the FPC connector.

So I grabbed the other FPC breakout board I had along with a new connector and it seems to be working "Okay" yet still not too stable. I was able to run the demosuace sketch and confirm that the display does in fact work.

I think the best way to continue testing this is to fabricate some PCBs with a T4/4.1 socket and an FPC to get it to work properly and stable as I have way too many jumper wires and I'm not even terminating the unused pins as I should be doing.

Anyways, a fair success as far as I see it!
 
what I suspect are micro solder shorts on the FPC connector.

My experience suggests once down to 0.5mm pitch you need to use stencil/solder-paste/oven for reliable results,
you need that strictly rationed amount of solder per pad.
 
Back
Top