ILI948x_t41_p - a parallel display driver for Teensy 4.1

Rezo said:
I got my 3.97" NT35510 display in, 8/16 bit parallel, 800*480 resolution at 16bpp.
Which branch of @mjs513 fork should I use? gfx_flexio ?
Do I need @KurtE new FlexIO library?
And does DMA work on 16 bit bus? or is only 8 bit supported?
Click to expand...
this is the correct branch:
github.com

GitHub - mjs513/ILI948x_t4x_p at ILI948x_t4x_p

A basic display driver for ILI948X series on a Teensy Micromod - GitHub - mjs513/ILI948x_t4x_p at ILI948x_t4x_p
github.com github.com

plus you will need the GFX lib:
github.com

GitHub - mjs513/Teensy_Parallel_GFX

Contribute to mjs513/Teensy_Parallel_GFX development by creating an account on GitHub.
github.com github.com

and will need @KurtEs updated Flexio lib
 
Quick update, As I mentioned yesterday, have been playing with the HX8357D display I purchased several years ago from Adafruit. I updated the wiring to use 8 bit.

I had/have it partially working using this library, but have now split it off to it's own:
github.com

GitHub - KurtE/HX8357_t4x_p: Parallel version HX8457_t3n

Parallel version HX8457_t3n . Contribute to KurtE/HX8357_t4x_p development by creating an account on GitHub.
github.com github.com
It is not perfect yet... But I do have a lot of the one test sketch for things running:
1721783864581.png

But some of the code is screwing up when trying to output the screen using Frame Buffer.
St

1721783890992.png


Investigating.


The FontTest4 is working. Several more things to try...

I did order one of the ones mentioned:
4" inch (3.97")TFT LCD Display Module 480X800 Optional Touch Screen
Interface
Pin Header Connection-8080 8-bit Parallel
Power Supply (Typ.)
VDD=5V
Touch Panel(Attached by default)
4“Capacitive Touch Panel with Controller		ER-TFTM040-1-3662-8BIT8080-5V-5590
I ordered at 8 bit, but like the others, can adapt to 16 bit with jumpers/resistors...

Back to playing
 
Would like to see 16 bit DMA working - going to require a lot of messing around with the dma channel config and implementation (we had to fill the shifter buffers in backwards due to the some odd reason in the 8 bit bus width)

But will be useful, especially on the higher res screens
 
Last edited:
Rezo said:
Would like to see 16 bit DMA working - going to require a lot of messing around with the dma channel config and implementation (we had to fill the shifter buffers in backwards due to the some odd reason in the 8 bit bus width)

But will be useful, especially on the higher res screens
Click to expand...
We have some of this working on RA8876... Other thread. I may try setting up for version with ILI948x. Might try reconfiguring one of the buy display ones.

Fill in shifters backwards, I saw that, and found it needed as well when I was setting up for T4 version. Not sure
why, but guessing, maybe if you fill in forward, by the time you fill in the last one, the first one needs data and everything gets messed up...
 
UPDATE:
Got my NT35510 in a few days ago - wired it up and got 16 bit polling working in minuets|
Played around with DMA settings (my LSB's and MSBs were swapped) and could not get it to play ball, so I copied the DMA config from the RA library that @wwatson @KurtE and @mjs513 have been working on, and that it working too
Running at 30Mhz ( very unstable at lower speeds with the 30cm wires I have) on the Devboard v5 and it's defiantly quick

Will plug in SDRAM and LVGL soon to do some benchmarking
Once cleaned up a bit, will upload to Github
 
Rezo said:
Got my NT35510 in a few days ago -
Click to expand...
Looks like the one I ordered, made it today to the United State (Los Angeles)... So probably by the end of the week.

For what it is worth, I updated one of the BuyDisplay ILI9488 boards to be 16bit flexIO and I am updating the library to work with it.

I have a lot of it working now:
1722199857825.png


Took a while to be able to get any of the readPixel/readRect to work properly.
But figured out that for each two pixels: it shifts in 3 16 bit packets. and If for example I put those
3 words into an array and look at the bytes: The bytes are ordered: G R R B B G

Now checking on the DMA output... Later may also try it on T4.1... with another display I purchased from Amazon awhile ago.
Although I don't believe that one has a READ pin...

EDIT: Should mention I pushed it up into a new WIP branch on @mjs513 fork:
github.com

GitHub - mjs513/ILI948x_t4x_p at BUS_WIDTH_16

A basic display driver for ILI948X series on a Teensy Micromod - GitHub - mjs513/ILI948x_t4x_p at BUS_WIDTH_16
github.com github.com
 
KurtE said:
Took a while to be able to get any of the readPixel/readRect to work properly.
But figured out that for each two pixels: it shifts in 3 16 bit packets. and If for example I put those
3 words into an array and look at the bytes: The bytes are ordered: G R R B B G
Click to expand...
I think you are seeing this odd order because you are swapping half-words in the buffer output using SHIFTBUFBYS
I had originally implemented that as when reading 8 bits, it was pushing the data to the upper 8 bits of the buffer, and I simply read the words swapped to read it out into a 16/8 bit integer.

Rezo said:
Rezo said:
Got my NT35510 in a few days ago -
Click to expand...
Looks like the one I ordered, made it today to the United State (Los Angeles)... So probably by the end of the week.
Click to expand...

So you got one on the way too? Amazing! Just note the commands are 16 bit values, so you might need to adapt the init command function to work with longer commands.
As mentioned I was able to get polling working as well as DMA, but when testing DMA with LVGL I was getting a lot of artifacts and instability (might be related to the long wires I am using)
I have an RM68120 here which is presumably dead, but going to try and revive it with 16 bit parallel as well.
 
Rezo said:
I think you are seeing this odd order because you are swapping half-words in the buffer output using SHIFTBUFBYS
I had originally implemented that as when reading 8 bits, it was pushing the data to the upper 8 bits of the buffer, and I simply read the words swapped to read it out into a 16/8 bit integer.
Click to expand...
The code is reading in 16 bits at a time... The 16 bit code currently does:
C++: 
} else if (_bus_width == 16) {
        static uint8_t read_debug_count = 10;
        static uint16_t debug_read_data[192];

        uint8_t debug_read_index = 0;
        uint16_t w[3];
        uint8_t *b = (uint8_t*)w;
        while (count_pixels) {
            waitReadShiftStat(__LINE__);
            w[0] = p->SHIFTBUF[_read_shifter] >> 16;

            waitReadShiftStat(__LINE__);
            w[1] = p->SHIFTBUF[_read_shifter] >> 16;

            if (count_pixels != 1) {
                waitReadShiftStat(__LINE__);
                w[2] = p->SHIFTBUF[_read_shifter] >> 16;

                *pcolors++ = color565(b[1], b[0], b[3]);
                *pcolors++ = color565(b[2], b[5], b[4]);
                count_pixels -= 2;
            } else {
                // not sure which byte the B will be on? guessing high byte of 2nd word...
                *pcolors++ = color565(b[1], b[0], b[3]);
                count_pixels --;
            }
            if (debug_read_index < 192) {
                debug_read_data[debug_read_index++] = w[0];
                debug_read_data[debug_read_index++] = w[1];
                debug_read_data[debug_read_index++] = w[2];
            }
        }
        if (read_debug_count) {
            read_debug_count--;
            Serial.printf("Dummy: %x %04x %04x %04x\n", dummy, debug_read_data[0], debug_read_data[1], debug_read_data[2]);
            MemoryHexDump(Serial, debug_read_data, debug_read_index * 2, true, "\nRaw Read Data:\n");
        }
But I probably could instead use the swap half words instead of needing the extra shift... Half of the above is debug stuff.
As took awhile to figure out the form layout of the data in 16 bit mode. The PDF on the display was not very clear
1722253335429.png

I am also trying to hook up one of the ones I picked up from amazon like HiLetgo to an T41 and it is showing some image, but not good yet.

1722253497116.png

This one does not have a READ pin, so adjusting the code. It also has level shifters on it so maybe timing, maybe signals not registering properly...

Rezo said:
So you got one on the way too? Amazing! Just note the commands are 16 bit values, so you might need to adapt the init command function to work with longer commands.
Click to expand...
Guessing it may be a week before it gets here and I have a chance to pick it up in town... But will play some. As I mentioned it was ordered configured for 8 bits...
 
I completely rewired it on T4.1.. with new longer wires... As to keep from one coming off at different times... And not much different
IMG_1937.jpeg
 
It did not crash mine did not work any better...


Code: 
PROGMEM const uint8_t ILI9486_POS_init_commands[] = {
    2, 50, 0x01, 0x00,
    2, 0, 0x28, 0x00,

    // Power Control 1
    3, 0, 0xC0, 0x0d, 0x0d,

    // Power Control 2
    3, 0, 0xC1, 0x43, 0x00,

    // Power Control 3
    2, 0, 0xC2, 0x00,

    // VCOM Control
    3, 0, 0xC5, 0x00, 0x48,

    // Display Function Control
    4, 0, 0xB6, 0x00,
        0x22,           // 0x42 = Rotate display 180 deg.
        0x3B,

    // PGAMCTRL (Positive Gamma Control)
    16, 0, 0xE0, 0x0f, 0x24, 0x1c, 0x0a, 0x0f, 0x08, 0x43, 0x88, 0x32, 0x0f, 0x10, 0x06, 0x0f, 0x07, 0x00,

    // NGAMCTRL (Negative Gamma Control)
    16, 0, 0xE1, 0x0F, 0x38, 0x30, 0x09, 0x0f, 0x0f, 0x4e, 0x77, 0x3c, 0x07, 0x10, 0x05, 0x23, 0x1b, 0x00,

    // Display Inversion OFF, 0x21 = ON
    1, 0, 0x20,

    // Memory Access Control
    2, 0, 0x36, 0x0A,

    // Interface Pixel Format
    2, 0, 0x3A, 0x55,

    1, 150, 0x11,

    1, 25, 0x29,
    0};
Code: 
    case ILI9486_POS:
    {
        addr = ILI9486_POS_init_commands;

        MADCTL[0] = MADCTL_MX | MADCTL_BGR;
        MADCTL[1] = MADCTL_MV | MADCTL_BGR;
        MADCTL[2] = MADCTL_MY | MADCTL_BGR;
        MADCTL[3] = MADCTL_MX | MADCTL_MY | MADCTL_MV | MADCTL_BGR;
        MADCTL[4] = MADCTL_MY | MADCTL_MV | MADCTL_BGR;
        Serial.print("ILI9486_POS Initialized\n");
    } break;

And of course add ILI9486_POS to the enum ...

The other one shipped should be here tomorrow... so should be able to try it in the next few days
 
KurtE said:
It did not crash mine did not work any better...
Click to expand...
Did the same thing and cant figure out why its not working been looking and no idea.

Did notice this:

Code: 
    Order: BGR
    interface pixel format: 24 bit

24bit pixel format? Looks like its just a fall through.
 
readRect fixed - Had not updated the ILI9486 readRect code to handle the 16 bit bus.
Code was pushed up. I also updated the Readme in this branch to mention some of the udates,
like pin numbers for T4.1 and T4, plus mention 16 bit mode and that we support most of the SPI methods now as well.

@mjs513 Wondering if we should PR this back into our versions main branch
 
Rezo said:
@KurtE did you get the NT35510 in yet?
Looking forward to seeing an implementation over a 16 bit bus with DMA
Click to expand...
Yes - I picked it up today... Will play soon. It is interesting that the commands are 16 bit as I believe you mentioned.
I see there is an Adafruit library for it, although only 16 bit Parallel from a couple of years ago.
 
You must log in or register to reply here.
Back
Top