search

prenticedavid / MCUFRIEND_kbv

MCUFRIEND_kbv Library for Uno 2.4, 2.8, 3.5, 3.6, 3.95 inch mcufriend Shields
Other
361 stars 179 forks source link

Teensy 4.1 & SSD1963 - 16 Bit #171

Open evmini1973 opened 3 years ago

evmini1973 commented 3 years ago

Hello, Thank you for your great work on this code.
I am connecting a 7" TFT SainSmart with a SSD1963 controller to a Teensy 4.1. The display was originally connected to a Arduino DUE with the DUE specific shield, which is not in use any longer.

Attached below are the files I modified from the Library.

1) Using the SSD1963_800ALT Config (MCUFriend_KBV.C) - removed the SS_INVERT flag 2) Uncommented out the USE_SPECIAL in the shield.h file 3) I created a special Config in special.h called TEENSY_4_16BIG

Status: The display is working very well but it does not display any Red, only Blue and Green. Runs the graphics_testKBV very well but with no RED. Running at 600 MHz.

Question: Since the red data in the 565 config is only in the upper 8 bits of the 16 bit data write, is there something in the 16 bit write macros that looks incorrect? All of the lower 8 bit data seems to be working correctly.

mcufriend_special.zip

Dan

evmini1973 commented 3 years ago

Hi - I found the problem. I had the port (GPIO7 vs. GPIO9) mapping incorrect. Here is the correct mcufriend_special that works well. Sorry for the false alarm. using USE_TEENSY_4_16BIT config define. mcufriend_special.zip

Thanks again for your great library!

evmini1973 commented 3 years ago

Actual pin mapping with corrected GPIO SAINSMART DIsplay Interface to Teensy 4.1.zip port names

evmini1973 commented 3 years ago

The GraphicTest runs at 600Mhz showed a performance of 0.42 seconds.

prenticedavid commented 3 years ago

Oh shit. I have just gone through your code and tidied it up: e.g. added what appeared to be your pin mapping.

I am not sure if you need the pinMode() calls in GP_INIT()

Please can you try my SPECIAL. Report Adafruit_Tests performance. Correct readID() and correct SOFTWARE SCROLL

//####################################### TEENSY4_16BIT ############################

#elif defined(USE_TEENSY_4_16BIT)  // 16bit on a Teensy 4.1
#pragma message "Teensy 4 16bit Defines in Special Driver"
//LCD pins  |D15 |D14 |D13 |D12 |D11 |D10|D9 |D8 | |D7  |D6  |D5 |D4 |D3 |D2 |D1  |D0  | 
//MXRT pin  |9.29|9.28|9.19|9.18|7.12|7.2|7.1|7.0| |7.17|7.10|9.8|9.6|9.5|9.4|7.11|7.16| 
//4.x pins                                         |7   |6   |5  |4  |3   |2  |9  |8   |
//LCD pins  |RD  |WR  |RS  |CS  |RST |  A5
//MXRT pin  |6.18|6.19|6.23|6.22|6.17|6.16
//4.x pins  |14  |15  |16  |17  |18  |

#define USES_16BIT_BUS

#if defined(__IMXRT1062__)
#define WRITE_DELAY { WR_ACTIVE8;WR_ACTIVE8; }
#define IDLE_DELAY  { WR_IDLE2;WR_IDLE; }
#define READ_DELAY  { RD_ACTIVE16;RD_ACTIVE16; }
#else
#error unspecified delays
#endif

#define RD_PORT GPIO6
#define RD_PIN 18
#define WR_PORT GPIO6
#define WR_PIN 19
#define CD_PORT GPIO6
#define CD_PIN 23
#define CS_PORT GPIO6
#define CS_PIN 22
#define RESET_PORT GPIO6
#define RESET_PIN 17

// configure macros for the data pins
//G = #O7     i = #O9
#define GMASK ((1<<17) | (1<<10) | (1<<11) | (1<<16) | (1<<12) | (1<<2) | (1<<1) | (1<<0) )
#define IMASK ((1<<8) | (1<<6)  |  (1<<5) |  (1<<4) |  (1<<29) | (1<<28) | (1<<19) | (1<<18))

// First shift is bit position in data (0-8)  Second shift = port_bit - bit position --> 10=11-1 (for bit #1 in port bit #11
#define write_16(d) { \
        GPIO7_DR_CLEAR = GMASK; GPIO9_DR_CLEAR = IMASK; \
        GPIO7_DR_SET = (((d) & (1 << 0)) << 16) \
                     | (((d) & (1 << 1)) << 10) \
                     | (((d) & (1 << 6)) << 4) \
                     | (((d) & (1 << 7)) << 10) \
                     | (((d) & (1 << 8)) >> 8) \
                     | (((d) & (1 << 9)) >> 8) \
                     | (((d) & (1 << 10)) >> 8) \
                     | (((d) & (1 << 11)) << 1) ; \
        GPIO9_DR_SET = (((d) & (1 << 2)) << 2) \
                     | (((d) & (1 << 3)) << 2) \
                     | (((d) & (1 << 4)) << 2) \
                     | (((d) & (1 << 5)) << 3) \
                     | (((d) & (1 << 12)) << 6) \
                     | (((d) & (1 << 13)) << 6) \
                     | (((d) & (1 << 14)) << 14) \
                     | (((d) & (1 << 15)) << 14);\
        }
#define read_16()   ((((GPIO7_PSR & (1 << 16)) >> 16) \
                   | ((GPIO7_PSR & (1 << 11)) >> 10) \
                   | ((GPIO9_PSR & (1 << 4)) >> 2) \
                   | ((GPIO9_PSR & (1 << 5)) >> 2) \
                   | ((GPIO9_PSR & (1 << 6)) >> 2) \
                   | ((GPIO9_PSR & (1 << 8)) >> 3) \
                   | ((GPIO7_PSR & (1 << 10)) >> 4) \
                   | ((GPIO7_PSR & (1 << 17)) >> 10) \
                   | ((GPIO7_PSR & (1 <<  0)) << 8) \
                   | ((GPIO7_PSR & (1 <<  1)) << 8) \
                   | ((GPIO7_PSR & (1 <<  2)) << 8) \
                   | ((GPIO7_PSR & (1 << 12)) >> 1) \
                   | ((GPIO9_PSR & (1 << 18)) >> 6) \
                   | ((GPIO9_PSR & (1 << 19)) >> 6) \
                   | ((GPIO9_PSR & (1 << 28)) >> 14) \
                   | ((GPIO9_PSR & (1 << 29)) >> 14)))

#define setWriteDir() {GPIO7_GDIR |=  GMASK;GPIO9_GDIR |=  IMASK; }
#define setReadDir()  {GPIO7_GDIR &= ~GMASK;GPIO9_GDIR &= ~IMASK; }

// you need to set pinMode for extra LCD pins  |D15 |D14 |D13 |D12 |D11 |D10|D9 |D8 |
#define GPIO_INIT() { \
        for (int i = 2; i <= 12; i++) pinMode(i, OUTPUT); \
        for (int i = A0; i <= A4; i++) pinMode(i, OUTPUT); \
        for (int i = 32; i <= 36; i++) pinMode(i, OUTPUT); \
}

#define write8(x)     { write16(x & 0xFF); }  //added
#define write16(x)    { write_16(x); WRITE_DELAY; WR_STROBE; IDLE_DELAY; } //added from github example
#define READ_16(dst)  { RD_STROBE; READ_DELAY; dst = read_16(); RD_IDLE4; }
#define READ_8(dst)   { READ_16(dst); dst &= 0xFF; }

#define PASTE(x, y) x ## y

#define PIN_LOW(port, pin) PASTE(port, _DR_CLEAR) = (1<<(pin))
#define PIN_HIGH(port, pin) PASTE(port, _DR_SET) = (1<<(pin))
#define PIN_OUTPUT(port, pin) PASTE(port, _GDIR) |= (1<<(pin))
evmini1973 commented 3 years ago

Sorry I didn't get an update posted before you went through my code. Thanks for the cleanup and pin-mapping. I should have added that to be proper. With subsequent testing at 600 MHz, I found occasionally, the graphics controller would not initialize properly. Worked at 150 MHz reliably. After much trial-n-error, changed the write8(x) macro to the one in the attached instead of the version that leveraged the write16(x) block. now using this:

define write8(x) {write_8(x); WRITE_DELAY; WR_STROBE }

Things seem to be running well now. The benchmark test shows 0.52 seconds. A bit slower than before, so I may try to remove a few delays and see if anything breaks.
mcufriend_shield.zip

prenticedavid commented 3 years ago

No problem. My WRITE_DELAY macros are conservative. Intended for 66ns controllers like ILI9486. The SSD1963 is much faster. Look at the values at the top of the special.h file e.g. tWC = 26ns tWRH = 13ns

I don't have a Teensy4.1 so I have only tried 16-bit Parallel on Mega2560 and Due. I do have a SSD1963. Likewise I have only tried 16-bit Parallel on Mega2560 and Due.

Please can you report back with your Teensy4.1 timing experiments. Academic really. There is little point in Adafruit_Tests faster than 1 second. Especially since the SSD1963 screen has 5X more pixels than a regular 240x320 screen.

Oh, can you try with an empty GPIO_INIT() macro.? Most Arduino init() functions will set PORT pins to GPIO but sometimes they are set to ALTERNATE_FUNCTION. I have only just looked at your XSLX file. I don't have Microsoft Office. You had set all the pinMode calls correctly.

//LCD pins  |D15 |D14 |D13 |D12 |D11 |D10|D9 |D8 | |D7  |D6  |D5 |D4 |D3 |D2 |D1  |D0  | 
//MXRT pin  |9.29|9.28|9.19|9.18|7.12|7.2|7.1|7.0| |7.17|7.10|9.8|9.6|9.5|9.4|7.11|7.16| 
//4.x pins  |34  |35  |37  |36  |32  |12 |11 |10 | |7   |6   |5  |4  |3   |2  |9  |8   |

I am impressed. The write_8() and read_8() macros are a little fiddly to write. Yours were 100% correct.

My default Teensy 3.2 and Teensy 4.0 wiring matches the regular Uno Shield mapping. I have made Teensy to Uno Adapters that route the official Teensy digital pins to Arduino headers.

David.

evmini1973 commented 3 years ago

Hi David. Thank you for your kind words and help with this. I commented out the GPIO_INIT define in SPECIAL file and everything works properly.

I ran some experiments with changing the delays but nothing seems to help. I have observed that it seems to be an initialization timing issue. With the faster times, the display may not initialize properly, but if it does initialize, it then operates with no issue with the faster timing.

Does the initialization codes use the same port writing macros or others? Dan

evmini1973 commented 3 years ago

Updated Teensy 4.1 pin assignments. The Teensy 4.1 has more pins exposed than the 4.0 and some of those extra pins are used for the 16 LCD interface. Also, there was a typo in the earlier files, for D15-D12. These should be on GPIO-7.x

//LCD pins |D15 |D14 |D13 |D12 |D11 |D10|D9 |D8 | |D7 |D6 |D5 |D4 |D3 |D2 |D1 |D0 | //MXRT pin |7.29|7.28|7.19|7.18|7.12|7.2|7.1|7.0| |7.17|7.10|9.8|9.6|9.5|9.4|7.11|7.16| //4.1 pins |34 |35 |37 |36 |32 |12 |11 |10 | |7 |6 |5 |4 |3 |2 |9 |8 |

prenticedavid commented 3 years ago

Ah-ha. So the pin assignments are different:

//LCD pins  |D15 |D14 |D13 |D12 |D11 |D10|D9 |D8 | |D7  |D6  |D5 |D4 |D3 |D2 |D1  |D0  | 
//MXRT pin  |9.29|9.28|9.19|9.18|7.12|7.2|7.1|7.0| |7.17|7.10|9.8|9.6|9.5|9.4|7.11|7.16| 
//YOUR pin  |7.29|7.28|7.19|7.18|7.12|7.2|7.1|7.0| |7.17|7.10|9.8|9.6|9.5|9.4|7.11|7.16| 
//4.1 pins  |34  |35  |37  |36  |32  |12 |11 |10 | |7   |6   |5  |4  |3  |2  |9   |8   |

This makes GMASK, IMASK different. Likewise write_16() and read_16()

Simple enough to fix.

Incidentally, GitHub Message Editor is a bit of a pig when it comes to pasting, formatting code. I hope that you view those tables neatly aligned in Courier font.

All register writes should use the same timing. Sometimes Power Control registers need millisecond delays e.g. in the tft.begin() initialisation sequences. You might find that a different SSD1963 table works better with your 7 inch. I only have 5 inch Ebay 40-pin Module.

Yesterday my Raspberry Pico boards arrived. The Pico definitely requires a GPIO_INIT() macro to set all the pins to digital OUTPUT. From memory the Teensy 3.2 needed GPIO_INIT(). So I used it for Teensy 4.0 too. I will investigate whether it is still necessary. Mr Stoffrogen might have changed the Teensy init() code.

Do you have any pins left on the 4.1 for anything else ? 8080-16 parallel interface is pretty greedy. You need SPI bus for SD and Touch Controller i.e. more pins even if you use the Teensy SD.

Personally, I would investigate 8080-8 interface if the IM# pins are accessible.

David.

evmini1973 commented 3 years ago

Turns out the display was still have initialization problems. About 1 time out 10, it would fail to start. I think the problem is around the init_table function and the SSD1963 configuration (SSD1963_800ALT option) commands. After the reset, the controller is running at a default speed of 10 MHz. The first few config commands setup the PLL so the controller will operate at 120 MHz. With the faster Teensy, there seems to be possibility that the PLL configuration commands could be missed by the SSD1963 since they are coming at a very fast rate. Once the SSD1963 is running at 120 MHz, it has no problem keeping up with the commands and data. This explains why if the controller initialized properly, it would then operate just fine, but if it failed initialization, it had to be reset.

Resolution --- Added a delay(1) after the two write8(x) sends in the init_table() routine. I could then reduce the timing delays in the WRITE_DELAY in the MCUFRIEND_special.h file to just and WR_ACTIVE. Now the GRAPHICTEST_KBV completes in 0.41 seconds and the TFT is operational in just over 1 second.

With the TEENSY 4.1 I still have 12+ free I/O pins even with the 16 bit TFT bus. Some will go for the touchscreen interface and but I should have plenty at this point. The 4.1 has so many I/O!

Thank you again for all of your help with this great library!

prenticedavid commented 3 years ago

Please post your amended SSD1963_800ALT_regValues table. Yes, once the Manufacturer Registers have been set up, displays only receive regular User commands (from the MIPI set)

Do you have any other 40-pin displays? e.g. SSD1289, ILI9341, ... It would be nice to know how they perform with your 40-pin wiring. (I am assuming that you have a proper 40-pin Adapter. Hand-routeing individual wires is not practical.)

David.

evmini1973 commented 3 years ago

Hello, Here is the SSD1963_800ALT setup in MCUFRIEND_kbv.

   static const uint8_t SSD1963_800ALT_regValues[] PROGMEM = {

        (0xE2), 3, 0x23, 0x02, 0x04,        //PLL multiplier, set PLL clock to 120M
        (0xE0), 1, 0x01,    // PLL enable
        TFTLCD_DELAY8, 10,  //was 10  #1
        (0xE0), 1, 0x03,    //
        TFTLCD_DELAY8, 10,  //was 10   #2
        (0x01), 0,            //Soft Reset
        TFTLCD_DELAY8, 100,  //100 #5
        (0xE6), 3, 0x04, 0x93, 0xE0,        //PLL setting for PCLK, depends on resolution
        (0xB0), 7, 0x00, 0x00, 0x03, 0x1F, 0x01, 0xDF, 0x00,        //LCD SPECIFICATION
        (0xB4), 8, 0x03, 0xA0, 0x00, 0x2E, 0x30, 0x00, 0x0F, 0x00,  //HSYNC HT=928, HPS=46, HPW=48, LPS=15
        (0xB6), 7, 0x02, 0x0D, 0x00, 0x10, 0x10, 0x00, 0x08,        //VSYNC VT=525, VPS=16, VPW=16, FPS=8
        (0xBA), 1, 0x0F,    //GPIO[3:0] out 1
        (0xB8), 2, 0x07, 0x01,      //GPIO3=input, GPIO[2:0]=output
        (0xF0), 1, 0x03,    //pixel data interface
        TFTLCD_DELAY8, 1,  //was 1  #4
        0x28, 0,            //Display Off
        0x11, 0,            //Sleep Out
        TFTLCD_DELAY8, 100,  //was 100 #3
        0x29, 0,            //Display On
        (0xBE), 6, 0x06, 0xF0, 0x01, 0xF0, 0x00, 0x00,      //set PWM for B/L
        (0xD0), 1, 0x0D,
    };

I do not have any other displays to test with, just the 7" SAINSMART. I did hand-wire the 21+ data signals, solder to a connector for the display.

Next stop is the radio and CANBUS interfaces. Thank you again for all of your great work and support on this.

Dan

evmini1973 commented 3 years ago

Bug discovered in the write_16 routine in mcufriend_special.h.

the 9th & 10th bits were being incorrect shifted to the right. should read:

                 | (((d) & (1 << 9)) >> 9) \
                 | (((d) & (1 << 10)) >> 9) \

(not shifts of >>8) MCUFRIEND_kbv.zip

Corrected version attached. This fixed an issue discovered with showBMP with 565 data where the highest top Green bits were being jumbled (G4) and lost (G5 highest order).

prenticedavid commented 3 years ago 
//LCD pins  |D15 |D14 |D13 |D12 |D11 |D10|D9 |D8 | |D7  |D6  |D5 |D4 |D3 |D2 |D1  |D0  | 
//MXRT pin  |9.29|9.28|9.19|9.18|7.12|7.2|7.1|7.0| |7.17|7.10|9.8|9.6|9.5|9.4|7.11|7.16| 
//YOUR pin  |7.29|7.28|7.19|7.18|7.12|7.2|7.1|7.0| |7.17|7.10|9.8|9.6|9.5|9.4|7.11|7.16| 

                     | (((d) & (1 << 8)) >> 8) \      //b8 -> 7.0
                     | (((d) & (1 << 9)) >> 8) \      //b9 -> 7.1
                     | (((d) & (1 << 10)) >> 8) \     //b10 -> 7.2
                     | (((d) & (1 << 11)) << 1) ; \   //b11 -> 7.12

                   | ((GPIO7_PSR & (1 <<  0)) << 8) \   //7.0 -> b8
                   | ((GPIO7_PSR & (1 <<  1)) << 8) \   //7.1 -> b9
                   | ((GPIO7_PSR & (1 <<  2)) << 8) \   //7.2 -> b10
                   | ((GPIO7_PSR & (1 << 12)) >> 1) \   //7.12 -> b11

Looks ok to me.

prenticedavid commented 3 years ago

Bump. I looked at your ZIP.

                     | (((d) & (1 << 8)) >> 8) \      //b8 -> 7.0 
                     | (((d) & (1 << 9)) >> 9) \      //b9 -> 7.0
                     | (((d) & (1 << 10)) >> 9) \     //b10 -> 7.1
                     | (((d) & (1 << 11)) << 1)  \    //b11 -> 7.12

Since all MIPI commands are 8-bit the b8-b15 mapping will not affect commands. However b8-b10 are the most significant GREEN bits in a 565 format pixel.

You won't notice anything for plain colour graphics. But colour photos will look weird.

Although I don't expect many people to use 8080-16 interface on a Teensy4.1 it would be nice to resolve this.

David.

evmini1973 commented 3 years ago

David, Yes, that is exactly what happened which is why the misplaced bits were not detected until I displayed a 24 bit bitmap. The greens were off. With the corrected mapping all is good. From this post: link to earlier post Thanks again.

prenticedavid commented 3 years ago

I still disagree. But I am going to the pub.

David.

evmini1973 commented 3 years ago

My Bad. I had 7.1 and 7.2 swapped in the pin descriptions which complicated things. You were exactly correct. Attached are the 3 files with the correct mcufrience_special.h Thank you for your careful eye. I also doubled checked the read_16 function to confirm is aligns with the correct pin definitions. Though, I don't have any code to test the read_16.

MCUFRIEND_kbv.zip

DunnettProjects commented 2 years ago

Hi Guys,

Newbie here, I hope I'm asking for help in the right place. I have an SSD1963 capacitive touch screen that is working fine with the supplied library & examples on a Mega + shield. I want to hook it up to my Teensy 4.1 with 8bit interface, with the intention of learning LVGL - but I'm out of my depth with setting up the drivers & libraries to suit.

I'm currently using Arduino IDE + Teensy Loader, with the latest MCUFRIEND_kbv, UTFT & LVGL libraries. The Teensy 4.1 and Touch screen are currently wired up with same pin configuration as listed in your files post earlier. SSD1963 Display.zip has all the support files associated with the touchscreen. Any help and advice would be much appreciated.

Ryan

evmini1973 commented 2 years ago

Hello, Ryan, No real advice. Hopefully, the documentation is sufficient. It's been a while since I worked on this. It's been very stable. Dan

On Mon, Dec 13, 2021 at 1:03 AM DunnettProjects @.***> wrote:

Hi Guys,

Newbie here, I hope I'm asking for help in the right place. I have an SSD1963 capacitive touch screen that is working fine with the supplied library & examples on a Mega + shield. I want to hook it up to my Teensy 4.1 with 8bit interface, with the intention of learning LVGL - but I'm out of my depth with setting up the drivers & libraries to suit.

I'm currently using Arduino IDE + Teensy Loader, with the latest MCUFRIEND_kbv, UTFT & LVGL libraries. The Teensy 4.1 and Touch screen are currently wired up with same pin configuration as listed in your files post earlier. SSD1963 Display.zip https://github.com/prenticedavid/MCUFRIEND_kbv/files/7702187/SSD1963.Display.zip has all the support files associated with the touchscreen. Any help and advice would be much appreciated.

Ryan

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/prenticedavid/MCUFRIEND_kbv/issues/171#issuecomment-992248392, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD4G2GDBTAD4CI77YYWYSM3UQWZHVANCNFSM42TL7E5A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

DetectiveFine commented 2 years ago

Hi all!

It doesn't work for me either, just a white screen. Maybe someone could attach a complete project file!?

prenticedavid commented 2 years ago

Please provide a link for the actual screen that you have bought. Please wire the pins appropriately 

//LCD pins  |D15 |D14 |D13 |D12 |D11 |D10|D9 |D8 | |D7  |D6  |D5 |D4 |D3 |D2 |D1  |D0  | 
//MXRT pin  |7.29|7.28|7.19|7.18|7.12|7.1|7.2|7.0| |7.17|7.10|9.8|9.6|9.5|9.4|7.11|7.16| 
//4.1 pins  |34  |35  |37  |36  |32  |12 |11 |10 | |7   |6   |5  |4  |3  |2  |9   |8   |

Run LCD_ID_readreg.ino and you should see the correct ID e.g.

reg(0x00A1) 01 57 61 01 FF  RD_DDB SSD1963

Then run graphictest_kbv.ino from out of the box. It should run the SSD1963 in 8-bit mode.

Please post links to the actual screen that you have bought. Please write meaningful messages. "doesn't work" is not much good to anyone.

If and when you have verified wiring and verified 8-bit operation we can attempt evmini1973's USE_TEENSY_4_16BIT special

DetectiveFine commented 2 years ago

Thanks for the reply!

I checked the connections many times. I use Teensy 4.1 and VSCode

DP: Display 5 inch TFT Arduino Touch Shield w/SSD1963 PDF: ER-TFTM050-5

LCD_ID_readreg.ino connection and result:

#define LCD_RST 17
#define LCD_CS 22
#define LCD_RS 23
#define LCD_WR 19
#define LCD_RD 18

#define LCD_D0 8
#define LCD_D1 9
#define LCD_D2 2
#define LCD_D3 3
#define LCD_D4 4
#define LCD_D5 5
#define LCD_D6 6
#define LCD_D7 7

Result:


controllers either read as single 16-bit
e.g. the ID is at readReg(0)
or as a sequence of 8-bit values
in special locations (first is dummy)

reg(0x0000) 00 00       ID: ILI9320, ILI9325, ILI9335, ...
reg(0x0004) 00 00 00 00 Manufacturer ID
reg(0x0009) 00 00 00 00 00      Status Register
reg(0x000A) 08 08       Get Power Mode
reg(0x000C) 00 00       Get Pixel Format
reg(0x0061) 00 00       RDID1 HX8347-G
reg(0x0062) 00 00       RDID2 HX8347-G
reg(0x0063) 00 00       RDID3 HX8347-G
reg(0x0064) 00 00       RDID1 HX8347-A
reg(0x0065) 00 00       RDID2 HX8347-A
reg(0x0066) 00 00       RDID3 HX8347-A
reg(0x0067) 00 00       RDID Himax HX8347-A
reg(0x0070) 00 00       Panel Himax HX8347-A
reg(0x00A1) 01 57 61 01 FF      RD_DDB SSD1963
reg(0x00B0) 00 00       RGB Interface Signal Control
reg(0x00B4) 00 00       Inversion Control
reg(0x00B6) 00 00 00 00 00      Display Control
reg(0x00B7) 01 EF       Entry Mode Set
reg(0x00BF) 00 00 00 00 00 00   ILI9481, HX8357-B
reg(0x00C0) 00 00 00 00 00 00 00 00 00  Panel Control
reg(0x00C8) 00 00 00 00 00 00 00 00 00 00 00 00 00      GAMMA       
reg(0x00CC) 00 00       Panel Control
reg(0x00D0) 00 00 00    Power Control
reg(0x00D2) 00 00 00 00 00      NVM Read
reg(0x00D3) 00 00 00 00 ILI9341, ILI9488
reg(0x00D4) 00 00 00 00 Novatek ID
reg(0x00DA) 00 00       RDID1
reg(0x00DB) 00 00       RDID2
reg(0x00DC) 00 00       RDID3
reg(0x00E0) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     GAMMA-A-P
reg(0x00E1) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     GAMMA-A-N
reg(0x00EF) 00 00 00 00 00 00   ILI9327
reg(0x00F2) 00 00 00 00 00 00 00 00 00 00 00 00 Adjust Control 2      
reg(0x00F6) 00 00 00 00 Interface Control```
prenticedavid commented 2 years ago

You have

#define LCD_RST 17 //A3 when expected A4 (D18)
#define LCD_CS 22  //A8 when expected A3 (D17)
#define LCD_RS 23  //A9 when expected A2 (D16)
#define LCD_WR 19  //A5 when expected A1 (D15)
#define LCD_RD 18  //A4 when expected A0 (D14)

I suggest that you use the expected pins i.e.

//LCD pins  |D15 |D14 |D13 |D12 |D11 |D10|D9 |D8 | |D7  |D6  |D5 |D4 |D3 |D2 |D1  |D0  | 
//MXRT pin  |7.29|7.28|7.19|7.18|7.12|7.1|7.2|7.0| |7.17|7.10|9.8|9.6|9.5|9.4|7.11|7.16| 
//4.1 pins  |34  |35  |37  |36  |32  |12 |11 |10 | |7   |6   |5  |4  |3  |2  |9   |8   |

//LCD pins  |RD  |WR  |RS  |CS  |RST |  A5
//MXRT pin  |6.18|6.19|6.23|6.22|6.17|6.16
//4.x pins  |14  |15  |16  |17  |18  |

If you want to use custom wiring you should say so in the first place. LCD_ID_readreg.ino only verifies the wiring. It does not use MCUFRIEND_kbv class. It only uses digitalWrite() The MCUFRIEND_kbv class wiring is always hard coded in shield.h or special.h at compile time. You can't change in constructor() or runtime.

You also need to find the appropriate GPIO6, GPIO7, GPIO9 bits that correspond to any custom wiring. e.g. by quoting Digital pin number and looking up in core_pins.h For example Arduino Digital pin D23 from core_pins.h is GPIO6.25 

#define CORE_PIN23_BIT      25
#define CORE_PIN23_PORTREG  GPIO6_DR
// and D28 is GPIO8.18
#define CORE_PIN28_BIT      18
#define CORE_PIN28_PORTREG  GPIO8_DR

As a silly question. Why do you want to use 16-bit in the first place ? 8-bit should be plenty fast enough.

David.

DetectiveFine commented 2 years ago

I tried Teensy 4.0 8bit parallel mode, it works! With the pins you suggested.

mcufriend_shield.h file, other pins are defined. Are these overlooked?

I want to use LVGL that's why I thought 16bit parallel, more FPS. There another problem. This may not belong here. The picture is falls apart.

/* Display flushing */
void my_disp_flush( lv_disp_drv_t *disp, const lv_area_t *area, lv_color_t *color_p )
{
    uint16_t w = (area->x2 - area->x1 + 1);
    uint16_t h = (area->y2 - area->y1 + 1);

    tft.startWrite();
    tft.setAddrWindow(area->x1, area->y1, w, h);
    tft.pushColors((uint16_t *)&color_p->full, (w * h), true);
    tft.endWrite();

    lv_disp_flush_ready(disp);
}

This works, but it draws terribly slowly.

/* Display flushing */
void my_disp_flush( lv_disp_drv_t *disp, const lv_area_t *area, lv_color_t *color_p )
{
    int32_t x, y;
    for(y = area->y1; y <= area->y2; y++) {
        for(x = area->x1; x <= area->x2; x++) {

            tft.drawPixel(x, y, *((uint16_t *)color_p));
            color_p++;
        }
    }

    lv_disp_flush_ready( disp );
}
prenticedavid commented 2 years ago

I tried Teensy 4.0 8bit parallel mode, it works! With the pins you suggested.

I am only using the standard Shield pin wiring i.e. data bus on D2-D9, control on A0-A4. The Teensy4.1 has the A0-A4 pins clearly marked on the official "pinout". The D2-D9, D14-D18 pins are printed on the pcb.

I suggest that you run ALL of the library examples. Make notes with pencil and paper. If you have a problem you can quote the example by name. Copy-paste any output from the Serial Terminal. Describe your problem.

I don't have a Teensy 4.1. I only have 3.2 and 4.0. But I am familiar with my own examples.

There is no point in trying to write your own code until you have verified that the library examples are working 100%.

And there is even less point in writing calls to non-existent methods e.g. tft.startWrite();

Yes, it would be nice to get feedback for the 8-bit SSD1963. Likewise we can try the USE_TEENSY_4_16BIT special. And get proper feedback.

David.