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

Thanks @defragster - unfortunately in this case I don't think it is even making it to setup()... I believe it was crashing in the bootloader...

Will try again later, right now moving displays to other board...
 
Actually it is crashing on T3B2 (older one without jumper) - Tried on different one with jumper and it appears to run... At least I am getting debug info... So will move tests over to different board!

unfortunately in this case I don't think it is even making it to setup()... I believe it was crashing in the bootloader...

I'm confused. Is this about T4 beta? I see "T3B2". Was that meant to be "T4B2"?

If something crashes on the latest T4 beta hardware, please post a detailed report on the T4 beta thread. I believe I do have a couple of those ILI9488 displays sitting around somewhere...
 
I wondered where the FAULT print was - but you noted garbage chars - hoped maybe it was just corrupting the Serial4 out.

It seems @mjs513 was getting failures in [bootloader … startup.c::ResetHandler()] - that is tough to trap - Serial4 can be online before setup() - but USB after. And if it is in the area of " //printf("before C++ constructors\n"); " - using code with data and arrays or .begin setup - would be stuck too.

That commented printf('constructors') and the one after might add to the picture if it repro's - I haven't triggered such behavior.

What I found so far was common between T3.x's and T4 - I don't see some of the same startup _hook()'s for T4 yet:
Code:
void startup_early_hook(void)		__attribute__ ((weak, alias("startup_default_early_hook")));
void startup_late_hook(void)		__attribute__ ((weak, alias("startup_default_late_hook")));

Paul asked about adding hook()'s - maybe a new one once? But assume no C code is live until after 'constructors'? And it would be mute for such early failures except maybe through Serial# with bitbang/PJRC out code.

Probably something there worth investigating/understanding with mem segment copy or init causing a reset during startup()? I wonder if the same code has problems on T_3.6? Probably not given it may not repro on all T4's?
 
I'm confused. Is this about T4 beta? I see "T3B2". Was that meant to be "T4B2"?

If something crashes on the latest T4 beta hardware, please post a detailed report on the T4 beta thread. I believe I do have a couple of those ILI9488 displays sitting around somewhere...

I noted my T3B2 confusion too - and by 'without' JUMPER is that the 'white wire'? Without white wire - or Newer Rev #21 final PCB - it could be a Serial# UART power issue affecting boot.
 
I'm confused. Is this about T4 beta? I see "T3B2". Was that meant to be "T4B2"?

If something crashes on the latest T4 beta hardware, please post a detailed report on the T4 beta thread. I believe I do have a couple of those ILI9488 displays sitting around somewhere...

Paul. Not sure if you saw post #3493 where I caused fault using Eigen and it enters bootloader.
 
Sorry :eek: - I meant T4B2 (pre brownout fixed version) - Pretty sure it is not Serial brownout issue as I can reprogram things on it like blink, or graphictest... And it also faults even when not plugged into breakout board...

Will post more on T4 thread. Not sure what else to test with it. Same image works on other T4...

Although I changed a few things and maybe happening with other as well...
 
@KurtE - no displays but I put the 7X Serial# breakout ( 14 pins at 3+V ) on the T4B4 - both white wire Mod - and it showed no issues - as posted on T4 thread with the eyes sketch and it didn't have any issue - so it doesn't seem to be brownout related.

@mjs513 - yeah that was the one the recent Eigen where you saw reset/bootloader issue.
 
@defragster - Hard to know what caused these both to get into the state, that it would not run that specific program, but would load and run others. And then once I changed it significantly enough it would load again... My guess is it could be some screwy timing thingy or maybe some exact size write at some specific location or, maybe a voltage spike/brownout as maybe I was plugging in or unplugging one of the displays or...

@mjs513 and ... With that RPI display, as I mentioned, I think I will try to setup an RPI to be able to at least use this display... and then try to capture the signals in Logic Analyzer.
So I keep meaning to pull out one of my RPI3 boards and set it up. Need to find the instructions on how to make these displays work.

Or I could wait until my RPI 4 arrives. Should be here within a week. (I ordered the 2GB version).
 
For the heck of it today, I hooked up that strange RPI TFT display to an RPI3, and then setup logic Analyzer to capture some of their initial SPI conversation.

Here is a location where I believe they are filling the screen... Or at least a rectangle:
screenshot.jpg

You will see bytes at start of these grouping in 4 byte groupsl
0x00 0x11 0x00 0x2b 0x00 0x15 0x00 0x00 0x00 0x15 0x00 0x00 0x00 0x15 0x00 0x01 0x00 0x15 0x00 0x3f
0x00 0x11 0x00 0x2a .....
0x00 0x11 0x00 0x2c <Probably write Ram>

These are the starts of define the rows and cols... And it looks like it outputs 4 bytes for every normal byte.
The 0x11 - looks like DC set to command
The 0x15 - looks like DC set to data...

I saved away the capture... Pretty large one as I let it run for maybe 10 seconds...
If I ask the LA to export the SPI capture I start off with:
Code:
Time [s],Packet ID,MOSI,MISO
8.907206636000000,0,0x00,0x00
8.907206924000000,0,0x00,0x00
8.907207211999999,0,0x00,0x00
8.907207500000000,0,0x00,0x00
8.957214664000000,1,0x00,0x00
8.957214951999999,1,0x00,0x00
8.957215240000000,1,0x00,0x00
8.957215528000001,1,0x00,0x00
9.075366816000001,2,0x00,0x00
9.075367104000000,2,0x01,0x00
9.075367392000000,2,0x00,0x00
9.075367679999999,2,0x00,0x00
9.125374288000000,3,0x00,0x00
9.125374576000000,3,0x11,0x00
9.125374863999999,3,0x00,0x00
9.125375152000000,3,0x00,0x00
9.135377768000000,3,0x00,0x00
9.135378056000000,3,0x00,0x00
9.135378343999999,3,0x00,0x00
9.135378628000000,3,0x7F,0x00
9.135379404000000,3,0x00,0xFC
9.135379692000001,3,0x00,0x10
9.135379980000000,3,0x00,0x00
9.135380264000000,3,0x7F,0x00
9.145382352000000,4,0x00,0x00
9.145382639999999,4,0x11,0x00
9.145382928000000,4,0x00,0x00
9.145383216000001,4,0xFF,0x00
9.145384116000001,5,0x00,0xFF
9.145384404000000,5,0x11,0xEE
9.145384692000000,5,0x00,0x00
9.145384979999999,5,0xFF,0x00
9.145385736000000,6,0x00,0xFF
9.145386024000000,6,0x11,0xFE
9.145386311999999,6,0x00,0x00
9.145386600000000,6,0xFF,0x00
9.145387356000001,7,0x00,0x00
9.145387643999999,7,0x11,0x00
9.145387932000000,7,0x00,0x00
9.145388219999999,7,0xFF,0x00
9.160390884000000,8,0x00,0x00
9.160391172000001,8,0x11,0x00
9.160391460000000,8,0x00,0x00
9.160391748000000,8,0x11,0x00
9.310409868000001,8,0x00,0x00
9.310410156000000,8,0x00,0x00
9.310410444000000,8,0x00,0x00
9.310410728000001,8,0x10,0x00
9.310411488000000,8,0x00,0x00
9.310411776000000,8,0x00,0x00
9.310412063999999,8,0x00,0x00
9.310412352000000,8,0x00,0x00
9.310413108000001,8,0x00,0x00
9.310413396000000,8,0x00,0x00
9.310413684000000,8,0x00,0x00
9.310413968000001,8,0x11,0x00
9.310414728000000,8,0x00,0x00
9.310415016000000,8,0x00,0x00
9.310415303999999,8,0x00,0x00
9.310415592000000,8,0x00,0x00
9.310416348000000,8,0x00,0x00
9.310416635999999,8,0x00,0x00
9.310416924000000,8,0x00,0x00
9.310417212000001,8,0x00,0x00
9.310417967999999,8,0x00,0x00
9.310418256000000,8,0x00,0x00
9.310418543999999,8,0x00,0x00
9.310418832000000,8,0x00,0x00
9.310419588000000,8,0x00,0x00
9.310419875999999,8,0x00,0x00
9.310420160000000,8,0x00,0x00
9.310420452000001,8,0x00,0x00
9.310421207999999,8,0x00,0x00
9.310421496000000,8,0x00,0x00
9.310421784000001,8,0x00,0x00
9.310422067999999,8,0x18,0x00
9.310423100000000,8,0x00,0x00
9.310423388000000,8,0x00,0x00
9.310423675999999,8,0x00,0x00
9.310423960000000,8,0x00,0x00
9.310424736000000,8,0x00,0x00
9.310425020000000,8,0x00,0x00
9.310425307999999,8,0x00,0x00
9.310425596000000,8,0x00,0x00
9.310426372000000,8,0x00,0x00
9.310426656000001,8,0x00,0x00
9.310426944000000,8,0x00,0x00
9.310427232000000,8,0x07,0x00
9.310428152000000,8,0x00,0x00
9.310428436000000,8,0x00,0x00
9.310428723999999,8,0x00,0x00
9.310429012000000,8,0x07,0x00
9.310429772000001,8,0x00,0x00
9.310430056000000,8,0x00,0x00
9.310430344000000,8,0x00,0x00
9.310430631999999,8,0x40,0x00
9.310431392000000,8,0x00,0x00
9.310431676000000,8,0x00,0x00
9.310431963999999,8,0x00,0x00
9.310432252000000,8,0x01,0x00
9.310433251999999,8,0x00,0x00
9.310433536000000,8,0x00,0x00
9.310433824000000,8,0x00,0x00
9.310434111999999,8,0x19,0x00
9.310434872000000,8,0x00,0x00
9.310435156000000,8,0x00,0x00
9.310435443999999,8,0x00,0x00
9.310435732000000,8,0x00,0x00
9.310436488000001,8,0x00,0x00
9.310436776000000,8,0x00,0x00
9.310437064000000,8,0x00,0x00
9.310437351999999,8,0x00,0x00
9.310438268000000,9,0x00,0x00
9.310438555999999,9,0x00,0x00
9.310438844000000,9,0x00,0x00
9.310439132000001,9,0x00,0x00
9.310439887999999,10,0x00,0x00
9.310440176000000,10,0x04,0x00
9.310440463999999,10,0x00,0x00
9.310440752000000,10,0x00,0x00
9.310441508000000,11,0x00,0x00
9.310441795999999,11,0x00,0x00
9.310442084000000,11,0x00,0x00
9.310442372000001,11,0x00,0x00
9.310443288000000,12,0x00,0x00
9.310443576000001,12,0x05,0x00
9.310443864000000,12,0x00,0x00
9.310444152000001,12,0x03,0x00
9.310444924000000,13,0x00,0x00
9.310445211999999,13,0x00,0x00
9.310445500000000,13,0x00,0x00
9.310445787999999,13,0x40,0x00
9.310446543999999,14,0x00,0x00
9.310446832000000,14,0x05,0x00
9.310447119999999,14,0x00,0x00
9.310447408000000,14,0x00,0x00
9.310448164000000,15,0x00,0x00
9.310448451999999,15,0x05,0x00
9.310448740000000,15,0x00,0x00
9.310449028000001,15,0x07,0x00
9.310449783999999,16,0x00,0x00
9.310450072000000,16,0x05,0x00
9.310450360000001,16,0x00,0x00
9.310450648000000,16,0x00,0x00
9.310451404000000,17,0x00,0x00
9.310451691999999,17,0x05,0x00
9.310451980000000,17,0x00,0x00
9.310452268000001,17,0x00,0x00
9.310453232000000,18,0x00,0x00
9.310453519999999,18,0x00,0x00
9.310453808000000,18,0x00,0x00
9.310454096000001,18,0x44,0x00
9.310454851999999,19,0x00,0x00
9.310455140000000,19,0x05,0x00
9.310455427999999,19,0x00,0x00
9.310455716000000,19,0x01,0x00
9.310456472000000,20,0x00,0x00
9.310456759999999,20,0x05,0x00
9.310457048000000,20,0x00,0x00
9.310457336000001,20,0x07,0x00
9.310458091999999,21,0x00,0x00
9.310458380000000,21,0x15,0x00
9.310458668000001,21,0x00,0x00
9.310458956000000,21,0x03,0x00
9.310459712000000,22,0x00,0x00
9.310460000000001,22,0x15,0x00
9.310460288000000,22,0x00,0x00
9.310460576000001,22,0x04,0x00
9.310461620000000,23,0x00,0x00
9.310461908000001,23,0x11,0x00
9.310462196000000,23,0x00,0x00
9.310462484000000,23,0x46,0x00
9.310463272000000,24,0x00,0x00
9.310463560000001,24,0x15,0x00
9.310463847999999,24,0x00,0x00
9.310464136000000,24,0x00,0x00
9.310464892000001,25,0x00,0x00
9.310465180000000,25,0x11,0x00
9.310465468000000,25,0x00,0x00
9.310465755999999,25,0x48,0x00
Again things appear to be in 4 byte groupings...
So looks like a nice highly inefficient output...

Now back to some previous distractions ;)
 
@KurtE
In that crazy sketch I posted, you got the cmd and data bytes right. CMD = 0x11 and DAT = 0x15. Here is the little snippet of code I was playing with - not sure if ts select stuff is right was just playing that was why I was asking about what the Touch was doing:
Code:
void lcd_cmd(uint8_t cmd) {

  SPI.beginTransaction(settingsA);
  digitalWrite(SPI_TCS_L, LOW);
  digitalWrite(SPI_SS_L, LOW); 
  SPI.transfer(cmd>>1); 
  SPI.transfer(0x11+((cmd&1)<<5)); 
  digitalWrite(SPI_SS_L, HIGH);
  SPI.endTransaction();
    digitalWrite(SPI_TCS_L, HIGH);
    
  SPI.beginTransaction(settingsA);
  digitalWrite(SPI_TCS_L, LOW);
  digitalWrite(SPI_SS_L, LOW); 
  SPI.transfer(cmd>>1);
  SPI.transfer(0x1B+((cmd&1)<<5)); 
  digitalWrite(SPI_SS_L, HIGH);
  SPI.endTransaction();
  digitalWrite(SPI_TCS_L, HIGH);
}
void lcd_dat(uint8_t dat) {

  SPI.beginTransaction(settingsA);
    digitalWrite(SPI_TCS_L, LOW);
    digitalWrite(SPI_SS_L, LOW); 
    SPI.transfer(dat>>1); 
    SPI.transfer(0x15+((dat&1)<<5));
    digitalWrite(SPI_SS_L, HIGH);
  SPI.endTransaction();
    digitalWrite(SPI_TCS_L, HIGH);
    
  SPI.beginTransaction(settingsA);
  digitalWrite(SPI_TCS_L, LOW);
  digitalWrite(SPI_SS_L, LOW); 
  SPI.transfer(dat>>1); 
  SPI.transfer(0x1F+((dat&1)<<5)); 
  digitalWrite(SPI_SS_L, HIGH);
  SPI.endTransaction();
    digitalWrite(SPI_TCS_L, HIGH);
}
 
Hi @mjs513 and everyone...

I did a new logic capture with shorter amount of data... This one I compressed into a zip file of only about 27mb. It captures the startup until I see the first Raspberry Pi Logo...

If interested I might be able to post and/or email the captured run... I capture all 6 data pins plugged into the display(Int, Touch_CS, display_cs, Mosi, Miso, SCLK).

While I know many of you may not have a Saleae logic analyzer... You can download from: https://www.saleae.com/downloads/
Although not sure if matters I use the one in beta: https://support.saleae.com/logic-software/latest-beta-release

Once installed you can load saved captures and scroll through the data, update some of the analyzers... Like look at the SPI for the touch screen init...
 
@KurtE

Got the file and sorting through it now - interesting so far. Need to confirm whats on Channels 0 and 1: Channel 0 = INT?IRQ? and channel 1 = Touch CS.

Right now it looks like it toggles T_CS right before it does a Display_CS. and sends the data. Ok so I am getting an idea. Now to figure out what the initialization is to see what Chip it is - think its a 9486
 
@mjs513 - I believe that is correct...

FYI - I have a hacked up version of your uncannyEyes running on a T4B2(non-ribbon)... with OLED, using Adafruit library....

I am not sure yet how bad I screwed it up for running on the ST7735 displays... I tried to change it to remove including the main library header in main file, and have it such that you uncomment the one you wish to use in config.h... But with the hack I had to allow two displays to be initialized differently I moved the eye definitions down below the includes...

Note currently I am getting 22 frames per second...
 

Attachments

  • uncannyEyes-190709a.zip
    943.9 KB · Views: 104
@KurtE

Post usually comes around 4pm EST by me so can't play with the ST7735 until then - hate waiting :(

Been looking at the Logic Analyzer dump and can't for the life of figure out what display controller its using. Doesn't seem to match anything I've seen for this display - argh. First 8bytes should be controlling the first 595 chip and then next 16 bytes should be the data to be sent? Since its in groups of 4bytes is that equivalent to a 32bit transfer? Also seems to sending the last transfer continuously until the next change, for instance I saw about 20 transfers of 0x00,0x15,0x00,0x00 before the next packet sent.
 
@mjs513 - Yep I know what you mean... First about waiting for delivery...

And Second about not sure what exactly device this is: Looking at the link you gave earlier: https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=124961
I have not found any searches by the markings shown on his version on what the underlying screen is... It looks like it may have about 40 pins coming off of the display, which I don't believe matches for example the one I have Eastrising which I think the actual display has like 50 pins coming off of it. Nor have it Tried to pick apart the one ILI9486 version for Arduino Mega shield to see what display it has and the pins coming off of it.

Again hard to figure out exactly what is going on... 0x00 0x15 0x00 0x00 looks like a data Write of a 0.
20 of these in a row may be for example part of an fill operation or the like...

Note with the LA, you can click on the sort of wheel looking thing on the right of the SPI thing under analyzers, and you can click to export as text/CSV file, which can give you textual verison, which I have done... I then tried editing the file to combine the 4 lines associated with each output that had a 0x00 next line 0x11 and marked that as CMD and then likewise for 0x15 and marked as DAT

And for example my startup goes like:
Code:
Time [s],Packet ID,MOSI,MISO
6.303586540000000,1,0x00,0x00
6.303586828000000,1,0x01,0x00
6.303587116000000,1,0x00,0x00
6.303587404000000,1,0x00,0x00
6.353594260000000,2,0x00,0x00
6.353594548000000,2,0x00,0x00
6.353594836000000,2,0x00,0x00
6.353595124000000,2,0x00,0x00
6.471938852000000,3,0x00,0x00
6.471939140000000,3,0x01,0x00
6.471939428000000,3,0x00,0x00
6.471939716000000,3,0x00,0x00
CMD(0x11): 0x00,0x00, 0x00,0x00
CMD(0x11): 0x00,0x00, 0xFF,0x00
CMD(0x11): 0x00,0x00, 0xFF,0x00
6.541954940000000,6,0x00,0x00
6.541955228000000,6,0x00,0x00
6.541955516000000,6,0x00,0x00
6.541955800000000,6,0x7F,0x00
6.541956784000000,6,0x00,0x80
6.541957072000000,6,0x00,0x10
6.541957360000000,6,0x00,0x00
6.541957644000000,6,0x7F,0x00
6.541958404000000,6,0x00,0xDD
6.541958692000000,6,0x00,0x16
6.541958980000000,6,0x00,0x20
6.541959264000000,6,0x7F,0x00
6.541960024000000,6,0x00,0xDF
6.541960312000000,6,0x00,0x77
6.541960596000000,6,0x00,0xF8
6.541960884000000,6,0x7F,0x00
CMD(0x11): 0x00,0x00, 0x11,0x00
CMD(0x11): 0x00,0x00, 0xB0,0x00
DAT(0x15): 0x00,0x00, 0x00,0x00
CMD(0x11): 0x00,0x00, 0xB3,0x00
DAT(0x15): 0x00,0x00, 0x02,0x00
DAT(0x15): 0x00,0x00, 0x00,0x00
DAT(0x15): 0x00,0x00, 0x00,0x00
DAT(0x15): 0x00,0x00, 0x00,0x00
CMD(0x11): 0x00,0x00, 0xB9,0x00
DAT(0x15): 0x00,0x00, 0x01,0x00
DAT(0x15): 0x00,0x00, 0x00,0x00
DAT(0x15): 0x00,0x00, 0x0F,0x00
DAT(0x15): 0x00,0x00, 0x0F,0x00
CMD(0x11): 0x00,0x00, 0xC0,0x00
DAT(0x15): 0x00,0x00, 0x13,0x00
DAT(0x15): 0x00,0x00, 0x3B,0x00
DAT(0x15): 0x00,0x00, 0x00,0x00
DAT(0x15): 0x00,0x00, 0x02,0x00
DAT(0x15): 0x00,0x00, 0x00,0x00
DAT(0x15): 0x00,0x00, 0x01,0x00
DAT(0x15): 0x00,0x00, 0x00,0x00
DAT(0x15): 0x00,0x00, 0x43,0x00
CMD(0x11): 0x00,0x00, 0xC1,0x00
DAT(0x15): 0x00,0x00, 0x08,0x00
DAT(0x15): 0x00,0x00, 0x0F,0x00
DAT(0x15): 0x00,0x00, 0x08,0x00
DAT(0x15): 0x00,0x00, 0x08,0x00
CMD(0x11): 0x00,0x00, 0xC4,0x00
DAT(0x15): 0x00,0x00, 0x11,0x00
DAT(0x15): 0x00,0x00, 0x07,0x00
DAT(0x15): 0x00,0x00, 0x03,0x00
DAT(0x15): 0x00,0x00, 0x04,0x00
CMD(0x11): 0x00,0x00, 0xC6,0x00
DAT(0x15): 0x00,0x00, 0x00,0x00
CMD(0x11): 0x00,0x00, 0xC8,0x00
DAT(0x15): 0x00,0x00, 0x03,0x00
DAT(0x15): 0x00,0x00, 0x03,0x00
DAT(0x15): 0x00,0x00, 0x13,0x00
DAT(0x15): 0x00,0x00, 0x5C,0x00
DAT(0x15): 0x00,0x00, 0x03,0x00
DAT(0x15): 0x00,0x00, 0x07,0x00
DAT(0x15): 0x00,0x00, 0x14,0x00
DAT(0x15): 0x00,0x00, 0x08,0x00
DAT(0x15): 0x00,0x00, 0x00,0x00
DAT(0x15): 0x00,0x00, 0x21,0x00
DAT(0x15): 0x00,0x00, 0x08,0x00
DAT(0x15): 0x00,0x00, 0x14,0x00
DAT(0x15): 0x00,0x00, 0x07,0x00
DAT(0x15): 0x00,0x00, 0x53,0x00
DAT(0x15): 0x00,0x00, 0x0C,0x00
DAT(0x15): 0x00,0x00, 0x13,0x00
DAT(0x15): 0x00,0x00, 0x03,0x00
DAT(0x15): 0x00,0x00, 0x03,0x00
DAT(0x15): 0x00,0x00, 0x21,0x00
DAT(0x15): 0x00,0x00, 0x00,0x00
CMD(0x11): 0x00,0x00, 0x35,0x00
DAT(0x15): 0x00,0x00, 0x00,0x00
CMD(0x11): 0x00,0x00, 0x36,0x00
DAT(0x15): 0x00,0x00, 0x60,0x00
CMD(0x11): 0x00,0x00, 0x3A,0x00
DAT(0x15): 0x00,0x00, 0x55,0x00
CMD(0x11): 0x00,0x00, 0x44,0x00
DAT(0x15): 0x00,0x00, 0x00,0x00
CMD(0x11): 0x00,0x00, 0x01,0x00
CMD(0x11): 0x00,0x00, 0xD0,0x00
6.707089188000000,47,0x00,0xFF
6.707089476000000,47,0x10,0x95
6.707089764000000,47,0x00,0x00
6.707090052000000,47,0x07,0x00
DAT(0x15): 0x00,0x00, 0x07,0x00
DAT(0x15): 0x00,0x00, 0x1C,0x00
CMD(0x11): 0x00,0x00, 0x03,0x00
[COLOR="#FF0000"]6.707095988000000,47,0x00,0xFF
6.707096276000000,47,0x10,0x91
6.707096564000000,47,0x00,0x00
6.707096852000000,47,0xC0,0x00
6.707097608000000,47,0x00,0xFF[/COLOR]
6.707097896000000,47,0x10,0x95
6.707098184000000,47,0x00,0x00
6.707098472000000,47,0x01,0x00
6.707099228000000,47,0x00,0xFF
6.707099516000000,47,0x00,0x95
6.707099804000000,47,0x00,0x00
6.707100092000000,47,0x10,0x00
6.707101088000000,47,0x00,0xFF
6.707101376000000,47,0x00,0x95
6.707101664000000,47,0x00,0x00
6.707101952000000,47,0x00,0x00
6.707102708000000,47,0x00,0xFF
6.707102996000000,47,0x00,0x91
6.707103284000000,47,0x00,0x00
6.707103568000000,47,0x40,0x00
6.707104328000000,47,0x00,0xFF
6.707104616000000,47,0x00,0x95
6.707104904000000,47,0x00,0x00
6.707105192000000,47,0x01,0x00
6.707105964000000,47,0x00,0xFF
6.707106252000000,47,0x00,0x95
6.707106540000000,47,0x00,0x00
6.707106828000000,47,0x00,0x00
6.707107584000000,47,0x00,0xFF
6.707107872000000,47,0x00,0x95
6.707108160000000,47,0x00,0x00
6.707108448000000,47,0x00,0x00
6.707109444000000,47,0x00,0xFF
6.707109732000000,47,0x00,0x91
6.707110020000000,47,0x00,0x00
6.707110308000000,47,0x00,0x00
CMD(0x11): 0x00,0x00, 0x2A,0x00
DAT(0x15): 0x00,0x00, 0x00,0x00
DAT(0x15): 0x00,0x00, 0x00,0x00
DAT(0x15): 0x00,0x80, 0x01,0x00
DAT(0x15): 0x00,0xC0, 0x3F,0x00
CMD(0x11): 0x00,0xC0, 0x2B,0x10
DAT(0x15): 0x00,0xE0, 0x00,0x00
DAT(0x15): 0x00,0xE0, 0x00,0x00
DAT(0x15): 0x00,0xE0, 0x01,0x00
DAT(0x15): 0x00,0xE0, 0xE0,0x50
CMD(0x11): 0x00,0xF0, 0xB4,0x4A
DAT(0x15): 0x00,0xF0, 0x00,0x00
CMD(0x11): 0x00,0xE0, 0x2C,0x12
CMD(0x11): 0x00,0x00, 0x2B,0x00
...

My Regular expression stuff within sublime text is probably not optimal, but this was done with commands like:
Code:
FIND: .*,0x00,0x[0-9A-F][0-9A-F]$\n.*,0x11,0x[0-9A-F][0-9A-F]$\n[0-9\.]*,[0-9]*,(.*)\n[0-9\.]*,[0-9]*,(.*)
Replace: CMD(0x11): $1, $2

But you will see there are some other combinations of first two bytes which probably mean something.
Like I marked one in RED which is 0x00 0x10...

And then next line is: 0x10 0x00 ???
 
@KurtE

Yeah - the LA results are confusing - pretty much did the same as you except looking at the data on the screen and saw the same thing. The one thing I found that exactly matches the our display is here: https://github.com/juj/fbcp-ili9341/issues/40, but the initialization sequence seems to be different. Was just going to and follow that initialization sequence - but they seem to indicate its a MPI3501 which I can't find any spec sheet on - others seem to think it may be a 9486 - oh well.
 
Actually it looks like the github code would not be hard to make a version that runs with our stuff...
 
@KurtE

Took a cut at it but probably made it more complicated than it needed to be:

View attachment Kedei.zip

Also took the screen off the mount to see if I could see anything so don't know if I messed my display up.

EDIT: Only tried it on the T4
 
Hi Mike, trying it out...

Started looking at LA output and noticed the Chip selects were a bit screwy...

Then noticed:
Code:
int lcd_open(void) {

	SPI.begin();
    pinMode(LCD_CS, OUTPUT);
    digitalWrite(LCD_CS, HIGH);
    pinMode(LCD_CS, OUTPUT);
    digitalWrite(LCD_CS, TOUCH_CS);
	return 0;
}
Will try changing to what I think you were doing:
Code:
int lcd_open(void) {

	SPI.begin();
    pinMode(LCD_CS, OUTPUT);
    digitalWrite(LCD_CS, HIGH);
    pinMode(TOUCH_CS, OUTPUT);
    digitalWrite(TOUCH_CS, HIGH);
	return 0;
}
Which looks like it is helping the TOUCH_CS to work properly... So far LCD_CS is staying high...

Still debugging
 
I now have it at least crawling on T4... The problem was that tft.begin() was never called, and as such the stuff was never initialized like the _csport and _cspinmask

Which were used when you called off to tft.beginSPITransaction/tft.endSPITransaction.

So I added the call to the start of lcd_init()
Code:
void lcd_init(void)
{
  Serial.println("Before tft.begin()");
  tft.begin();
  Serial.println("After tft.begin()");
//reset display

Again it is really crawling!

As you can see here in the output of each 4 byte grouping...
screenshot.jpg
 
You can speed it up quite a bit by decreasing your delay in spi_transmit
Currently I have:
Code:
void spi_transmit(int devsel, uint8_t *data, int len)
{
//    Serial.print("spi_transmit: ");
    int ret = 0;
    //digitalWrite(10, HIGH);
	//ret = wiringPiSPIDataRW(devsel, (unsigned char*)data, len);
    //digitalWrite(10, LOW);
	tft.beginSPITransaction();
	for(uint8_t i=0; i<(len-1); i++){
		tft.writedata8_cont(*data++);
	}
	tft.writedata8_last(*data++);
	tft.endSPITransaction();
#if 1
	digitalWrite(TOUCH_CS, LOW);
	delayMicroseconds(1);
  digitalWrite(TOUCH_CS, HIGH);
#endif 
}
But it does not work if you change the #if 1 to #if 0
So wondering if maybe Touch_CS pin is somehow also tied into the shift registers...
 
@KurtE

Glad it was something stupid it on my part. Anyway as for the T_CS pin - you absolutely need it. Read that on several of the forums. This is the quote from the GitHub page that I got the code from:
T_CS - Chip select for xpt2046, you need this in order to make display work! nasty �� manually yank this line(pull low) when finish sending data through SPI
The 50micos delay was just a guess on my part to start with to see if it worked.

EDIT: Made the changes and not working for me - guess I broke something when I lifted the screen.
PS> Surprised I got as far as I did - see you guys taught me something after all.
 
Last edited:
@mjs513 - Hopefully your screen is not damaged so you can play :D I do see the Touch CS pin being manipulated after each write of 4 bytes... My guess is it is tied to the shift registers or the like and tells it to update the output bits... I am seeing in the earlier capture about 90 nano-seconds, so the Delay 1us is still maybe 10 times more than it needs.

Unfortunately it sort of neuters the usage of the FIFO otherwise it might make sense to try using 32 bit writes from FIFO, but that would only gain sligthly...
 
Back
Top