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

@mjs513 -

Yep - I totally hear you about not matching any driver we know, but who knows. At some point I will probably try to message the CSV file into stuff that looks more like
CMD: xxx
DATA XXX

And see if anything sticks out...

But just got back from one distraction and mowed some trails
 
Oh boy - hope you had some fun.

Yes I know you will massage it but fair warning there are some blocks that don't follow cmd/data blocks - I was doing that earlier. Then there are a whole bunch of repeated blocks with the same hex values. Its like it always repeating the last block sent until a new one is issued. This kinda of follows one of the drivers I saw. Got confusing :) Let me know when you are ready I will give you the link to fbct for the pi.
 
Hi Mike,

I took another look at the data. First thing is I wondered if maybe looking at the wrong edge of the clock in the capture, so I changed it. (Go to SPI Analyzer click on the thing choose settings).
The output data looked better. So again I saved the text file (export as text/csv file)...

Then loaded up in sublime text to look at. I then did a search and replace as to combine 4 lines together if they shared the same "packet id", which I think is set by when CS is asserted/deasserted.

Nice simple find string (with regular expressions turned on)
(\d*\.\d*),(\d*),(0x[0-9A-F]*),.*\n\d*\.\d*,\2,(0x[0-9A-F]*),.*\n\d*\.\d*,\2,(0x[0-9A-F]*),.*\n\d*\.\d*,\2,(0x[0-9A-F]*),.*

Replace with:
$1,$2,$3,$4,$5,$6

I think most all of the lines are now either 0x11, or 0x15...

The first several lines look like:
Code:
6.303586540000000,1,0x00,0x01,0x00,0x00
6.353594260000000,2,0x00,0x00,0x00,0x00
6.471938852000000,3,0x00,0x01,0x00,0x00
6.521946556000000,4,0x00,0x11,0x00,0x00
6.531950320000000,5,0x00,0x11,0x00,0xFF
6.531952084000000,6,0x00,0x11,0x00,0xFF
6.541954940000000,6,0x00,0x11,0x00,0xFF
6.541956784000000,6,0x00,0x11,0x00,0xFF
6.541958404000000,6,0x00,0x11,0x00,0xFF
6.541960024000000,6,0x00,0x11,0x00,0xFF
6.556963300000000,7,0x00,0x11,0x00,0x11
6.706982484000000,8,0x00,0x11,0x00,0xB0
6.706984104000000,9,0x00,0x15,0x00,0x00
6.706985964000000,10,0x00,0x11,0x00,0xB3
6.706987584000000,11,0x00,0x15,0x00,0x02
6.706989204000000,12,0x00,0x15,0x00,0x00
6.706990824000000,13,0x00,0x15,0x00,0x00
6.706992444000000,14,0x00,0x15,0x00,0x00
6.706994096000000,15,0x00,0x11,0x00,0xB9
6.706995908000000,16,0x00,0x15,0x00,0x01
6.706997528000000,17,0x00,0x15,0x00,0x00
6.706999148000000,18,0x00,0x15,0x00,0x0F
6.707000928000000,19,0x00,0x15,0x00,0x0F
6.707002548000000,20,0x00,0x11,0x00,0xC0
6.707004168000000,21,0x00,0x15,0x00,0x13
6.707005948000000,22,0x00,0x15,0x00,0x3B
6.707007568000000,23,0x00,0x15,0x00,0x00
6.707009188000000,24,0x00,0x15,0x00,0x02
6.707011048000000,25,0x00,0x15,0x00,0x00
6.707012684000000,26,0x00,0x15,0x00,0x01
6.707014304000000,27,0x00,0x15,0x00,0x00
6.707016084000000,28,0x00,0x15,0x00,0x43
6.707017704000000,29,0x00,0x11,0x00,0xC1
6.707019324000000,30,0x00,0x15,0x00,0x08
6.707020944000000,31,0x00,0x15,0x00,0x0F
6.707022564000000,32,0x00,0x15,0x00,0x08
6.707024184000000,33,0x00,0x15,0x00,0x08
6.707025996000000,34,0x00,0x11,0x00,0xC4
6.707027616000000,35,0x00,0x15,0x00,0x11
6.707029252000000,36,0x00,0x15,0x00,0x07
6.707030888000000,37,0x00,0x15,0x00,0x03
6.707032508000000,38,0x00,0x15,0x00,0x04
6.707034400000000,39,0x00,0x11,0x00,0xC6
6.707036020000000,40,0x00,0x15,0x00,0x00
6.707037640000000,41,0x00,0x11,0x00,0xC8
6.707039436000000,42,0x00,0x15,0x00,0x03
6.707041056000000,43,0x00,0x15,0x00,0x03
6.707042676000000,43,0x00,0x15,0x00,0x13
6.707044456000000,44,0x00,0x15,0x00,0x5C

I included a zip file showing the whole extract. Which shows I think a couple of full/partial screen fills
 

Attachments

  • RPI_Display_startup3.zip
    925.7 KB · Views: 59
@mjs513 - Yep equally bad ;)

Yep I was/am thinking about something similar.
Also yours has a bug: Like look at line 13790:
Code:
6.80517338	9812	0x00	0x15	0x30	0x22	lcd_dat(0x30);

Should be: lcd_dat(0x3022);

I Just did similar edit using Sublime...
Example:
Not very sophisticated but:
Find: (0x00,0x11,0x)([0-9A-F][0-9A-F])(,0x)([0-9A-F][0-9A-F])$
Replace: $1$2$3$4,lcd_cmd(0x$2$4);

Yes lots of duplicates as it is filling screen up.
For example if you look at line 103, you should see something that maybe looks familiar:
l
Code:
cd_cmd(0x002B);
lcd_dat(0x0000);
lcd_dat(0x0000);
lcd_dat(0x0001);
lcd_dat(0x003F);
lcd_cmd(0x002A);
lcd_dat(0x0000);
lcd_dat(0x0000);
lcd_dat(0x0001);
lcd_dat(0x00DF);
lcd_cmd(0x002C);
lcd_dat(0x0000);
lcd_dat(0x0000);
lcd_dat(0x0000);
lcd_dat(0x0000);
lcd_dat(0x0000);
lcd_dat(0x0000);
lcd_dat(0x0000);
lcd_dat(0x0000);
lcd_dat(0x0000);
lcd_dat(0x0000);
...
This is defining the start of a main write to the display.
#define KEDEIRPI35_CASET 0x2A //Column Address Set
#define KEDEIRPI35_PASET 0x2B //Page Address Set
#define KEDEIRPI35_RAMWR 0x2C //Memory Write
So output Rows 00-0x13f And Columns: 00-0x1df or 320x480=153600 values
The first data output at line 114

The next command is at line 153714
Which makes sense (114+153600) so one lcd_dat per memory...

And then it repeats doing another equivalent of writeRect...

Now if I were a nerd and then convert this whole thing into simple program,
Probably converting the first three lines like:
Code:
6.303586540000000,1,0x00,0x01,0x00,0x00,spi_transmit32(0x00010000);
6.353594260000000,2,0x00,0x00,0x00,0x00,spi_transmit32(0x00000000);
6.471938852000000,3,0x00,0x01,0x00,0x00,spi_transmit32(0x00010000);
I would also look at the time stamps and if there was any difference > threshold I would add a delay between...
Like these first two lines have a difference of time of: 0.05000772
or: delay(50);

And then try to package it with one of the programs and see what happens on the display...

But that was only if ....

Included updated txt file with cmd, dat, transmit32...
 

Attachments

  • RPI_Display_startup3.zip
    947.9 KB · Views: 51
@KurtE
The nerd that I am I tried to make it work without a lot of manual conversion. If do the delay etc and then do a mass copy and past of all 201K lines work load into the T4 - out of memory. To make it work you have to take all those dup lines and make them for loops I tried but just to get through 11K lines is took forever - don't know if there is a shorter way.
 
@KurtE
Tried lining up what you have with what I was working on in my spreadsheet - a couple things didn't line up but have to finish doing some chores around the house then I will get back to it.

We really are gluttons for punishment :)
 
Glutton , geek whatever :)

My display is still wired - haven't tried it since last post here - maybe soon.

The timers sound fun. My code on T4 shows this as the micros() rolled over:
Code:
600000000=d CYCCNT 	13310706=loop() Cnt 	4293453002us @ 4293453ms cnt =64380000
600000000=d CYCCNT 	13310707=loop() Cnt 	4294453002us @ 4294453ms cnt =64395000
600000000=d CYCCNT 	13310707=loop() Cnt 	485706us @ 4295453ms cnt =64410000
600000000=d CYCCNT 	13310707=loop() Cnt 	1485706us @ 4296453ms cnt =64425000
600000000=d CYCCNT 	13310709=loop() Cnt 	2485706us @ 4297453ms cnt =64440000
600000000=d CYCCNT 	13310709=loop() Cnt 	3485706us @ 4298453ms cnt =64455000

That yield really takes the edge off the added loop() speed - if only there were a non-conditional way to limit it to run only a million times/sec - or some compromise.
 
@KurtE
Tried lining up what you have with what I was working on in my spreadsheet - a couple things didn't line up but have to finish doing some chores around the house then I will get back to it.

We really are gluttons for punishment :)

@KurtE
Tried a couple of things but no go - I tried to match what you had with what I had as best I good but they look like a match.
 
@mjs513 - :eek: - One little typo... The function spi_transmit32, I think line 9 was setting CS to LOW, should be HIGH...

After that change my screen now shows 4 Raspberries :D
 
@KurtE
Stop showing off :)

Didn't even look their - was busy checking the conversions. Any loaded it up with the correction and it ran but my colors are still off - screen is white raspberry is like an orange and leafs are a light pink. They are in the upper right corner of the display. Look like the screen colors are the same before we did the negate of the colors. Not sure what else you want to do with the lib you created.

I have another display arriving today so lets see if it gives the same result :)

Did finally get around to installing sublime text so I can start using it on the desktop along with code compare.
 
@mjs513 :p :D

I did not look either, but as soon as I saw the first few things output and CS pin not changing state, knew something was wrong!

So colors are screwed up? Aarg!

Will be interesting to hear what your new display does. If it is still screwed up color wise, then one of the next things I would probably do with one of these display with different colors is to, try running it on an RPI with their Raspian image with the driver already installed. I did this with my display to verify it would output something. It came up with the complete Raspberry PI(linux) desktop on the display.

If it came up looking correct color wise, I would then try:
a) reconnect it to teensy and see if this (or one of the other sketches) now shows the correct colors. Which might imply that the KeDei driver somehow updated the display

b) If still not showing correct on Teensy, hook back up on RPI with LA and capture it's startup, and attempt to see what differences there are...

or c) - Punt
 
@KurtE


Ok. What image did you use and how do you install it - or point me in the right direction - I do have a raspberry pi 3 sitting around I can test it on.
 
@KurtE

Ok - download just finished - took a couple of hours man...…

1. Booted up pi 3 with the 6.3 img I downloaded screen looked good - nice black background with nicely colored raspberries :) Unfortunately the pi never booted just got stuck on that screen. May be a problem with the image.

2. Put it back on the Teensy - no good - screen white with colors as described in post 412. One thing I noticed was that on the teensy the screen was mirrored compared to the Pi.

3. Going to wait for the new screen before hooking up the LA just in case. Almost time to punt...…..
 
Sounds like it hung ;) Did you try booting it again, to see if maybe it is happy a second time...

On mine, it shows the startup screen like we had, then sort of goes blank and shows a couple of warning/errors...

Then comes up with main screen:
IMG_0826 (002).jpg

... Again maybe time to punt and/or see what the new one does
 
Also another possibly interesting thing involved with this startup sequence is there is the SPI stuff talking to what we think is only the touch display. There is a conversation that happens before we actually then do the init sequence which those other CSV files showed...

So reloaded my saved away logic output, and setup another SPI filter looking at the TouchCS as the CS pin. Had to also change defaults on idle cs high or low, and trailing edge...

Then dumped out the startup sequence to file. I then mucked with it with sublime text, to change the 4 8 bit transfers per logical transfer into one 32 bit transfer:
With:
Find: (6\.[0-9]*),([0-9]*),0x([0-9A-F]*),0x([0-9A-F]*)\n6\.[0-9]*,\2,0x([0-9A-F]*),0x([0-9A-F]*)\n6\.[0-9]*,\2,0x([0-9A-F]*),0x([0-9A-F]*)\n6\.[0-9]*,\2,0x([0-9A-F]*),0x([0-9A-F]*)
Replace: $1,$2,0x$3$5$7$9,0x$4$6$8$10

Then took to excel to add another column to add number of millseconds delay between.

And we have the sequence:
Code:
Time [s]	Packet ID	MOSI	MISO	Column1
6.243344748	0	0x00E70000	0x00007FF8	 
6.243350384	1	0x00E70000	0xFFF07FF8	0
6.243355764	2	0x00E70000	0xFFF07FF8	0
6.243361208	3	0x00E70000	0xFFF07FF8	0
6.243366652	4	0x00E70000	0xFFF07FF8	0
6.243372032	5	0x00E70000	0xFFF07FF8	0
6.243377412	6	0x00E70000	0xFFF07FF8	0
6.243382792	7	0x00E70000	0xFFF07FF8	0
6.243388172	8	0x00E70000	0xFFF07FF8	0
6.243393616	9	0x00E70000	0xFFF07FF8	0
6.243398996	10	0x00E70000	0xFFF07FF8	0
6.243404376	10	0x00E70000	0xFFF07FF8	0
6.24340982	10	0x00E70000	0xFFF07FF8	0
6.243415264	10	0x00E70000	0xFFF07FF8	0
6.243420644	10	0x00E70000	0xFFF07FF8	0
6.243426024	10	0x00E70000	0xFFF07FF8	0
6.243431468	10	0x00E70000	0xFFF07FF8	0
6.243436848	10	0x00E70000	0xFFF07FF8	0
6.243442228	10	0x00E70000	0xFFF07FF8	0
6.243447608	10	0x00E70000	0xFFF07FF8	0
6.243452988	10	0x00E70000	0xFFF07FF8	0
6.293464788	10	0x00E70000	0xFFF07FF8	50
6.293470424	10	0x00E70000	0xFFF07FF8	0
6.293475996	10	0x00E70000	0xFFF07FF8	0
6.29348144	10	0x00E70000	0xFFF07FF8	0
6.293486884	10	0x00E70000	0xFFF07FF8	0
6.293492264	10	0x00E70000	0xFFF07FF8	0
6.293497708	10	0x00E70000	0xFFF07FF8	0
6.293503152	10	0x00E70000	0xFFF07FF8	0
6.293508596	10	0x00E70000	0xFFF07FF8	0
6.293513976	10	0x00E70000	0xFFF07FF8	0
6.293519356	10	0x00E70000	0xFFF07FF8	0
6.2935248	10	0x00E70000	0xFFF07FF8	0
6.293530244	10	0x00E70000	0xFFF07FF8	0
6.293535688	10	0x00E70000	0xFFF07FF8	0
6.293541132	10	0x00E70000	0xFFF07FF8	0
6.293546576	10	0x00E70000	0xFFF07FF8	0
6.29355202	10	0x00E70000	0xFFF07FF8	0
6.293557464	10	0x00E70000	0xFFF07FF8	0
6.293562908	10	0x00E70000	0xFFF07FF8	0
6.293568352	10	0x00E70000	0xFFF07FF8	0
6.293573796	10	0x00E70000	0xFFF07FF8	0
6.293579496	10	0x00800000	0xFFF07FF8	0
6.30358654	10	0x00010000	0x00000000	10
 
@KurtE

It could very well be. I got my third display and tested it on T4 - Ran the graphics test sketch and nothing - screen remained white. So I ran the kedei startup sketch and it displayed the 4 berries although colors still wrong but it was a lot clearer. Then I put it in the Pi and colors were correct and got a black background. There was one thing I did just since I noticed they had Touch on CS and LCD on the pin next to it. I swapped TS and CS pins without changing them in the sketch and it still worked...….

EDIT: I did run touchpaint and touch does work even if nothing is displayed.
 
Also another possibly interesting thing involved with this startup sequence is there is the SPI stuff talking to what we think is only the touch display. There is a conversation that happens before we actually then do the init sequence which those other CSV files showed...

So reloaded my saved away logic output, and setup another SPI filter looking at the TouchCS as the CS pin. Had to also change defaults on idle cs high or low, and trailing edge...

Then dumped out the startup sequence to file. I then mucked with it with sublime text, to change the 4 8 bit transfers per logical transfer into one 32 bit transfer:
With:
Find: (6\.[0-9]*),([0-9]*),0x([0-9A-F]*),0x([0-9A-F]*)\n6\.[0-9]*,\2,0x([0-9A-F]*),0x([0-9A-F]*)\n6\.[0-9]*,\2,0x([0-9A-F]*),0x([0-9A-F]*)\n6\.[0-9]*,\2,0x([0-9A-F]*),0x([0-9A-F]*)
Replace: $1,$2,0x$3$5$7$9,0x$4$6$8$10

Then took to excel to add another column to add number of millseconds delay between.

And we have the sequence:

….

Since I don't have the raw data what you would have to do is to lcd_cmd(MOSI) and LCD_DAT(MISO)? or do I have it backwards - please teach me master yoda :)

EDIT:
Dummy that I am I just converted them to this format
Code:
spi_transmit32(0x00E70000); spi_transmit32(0x00007FF8); [\CODE]
Didn't change the colors though.  On to the next problem
 
Last edited:
Hi @mjs513 - The raw data of the last posting, came from the RPI Logic Analyzer save file that I sent you awhile ago in a zip file... It is all in the very beginning of the data.
screenshot.jpg

And all of it is in the measurement marked area of the picture.

Not sure what you are asking, How do we try to capture this data?

a couple of interesting notes:

a) I know on our current boards the SPI transactions, with the Touch CS being asserted with SPI, I know works with the XPT2046 chip on the display as we have a working version of touchpaint that uses this. Which is interesting as it does not go with these 4 byte outputs per command request.

Looked like several of the same commands and results. The last two are different, with the last one actually being the first command shown in the other list, as both CS pins are low at that point, but then touch CS rises just after the output.

b) If we are curious about trying these outputs to the display and see what return values are... I will try it.
Code:
void spi_transmit32(uint32_t data32)
{
  digitalWriteFast(LCD_CS, LOW);
  SPI.transfer16(data32 >> 16);
  SPI.transfer16(data32 & 0xffff);
  digitalWriteFast(LCD_CS, HIGH);
  digitalWriteFast(TOUCH_CS, LOW);
  delayNanoseconds(5);
  digitalWriteFast(TOUCH_CS, HIGH);
}

void lcd_cmd(uint8_t cmd) {
  spi_transmit32(0x00110000L | cmd);
}

void lcd_data(uint16_t dat) {
  spi_transmit32(0x00150000L | dat);
}
void lcd_data(uint16_t dat, uint32_t count) {
  uint32_t data32 = 0x00150000L | dat;
  while (count--) {
    spi_transmit32(data32);
  }
}
I have the simple stuff at start... Note in test app, I also have:
Code:
#define KEDEIRPI35_CASET   0x2A   //Column Address Set 
#define KEDEIRPI35_PASET   0x2B   //Page Address Set 
#define KEDEIRPI35_RAMWR   0x2C   //Memory Write 
void setAddr(uint16_t x0, uint16_t y0, uint16_t x1, uint16_t y1)
 {
    lcd_cmd(KEDEIRPI35_PASET);  // (y)
    lcd_data(y0 >> 8);
    lcd_data(y0 & 0xFF);
    lcd_data(y1 >> 8);
    lcd_data(y1 & 0xFF);
    lcd_cmd(KEDEIRPI35_CASET);  // (x)
    lcd_data(x0 >> 8);
    lcd_data(x0 & 0xFF);
    lcd_data(x1 >> 8);
    lcd_data(x1 & 0xFF);
}


void fillRect(int16_t x, int16_t y, int16_t w, int16_t h, uint16_t color)
{
  setAddr(x, y, x + w - 1, y + h - 1);
  lcd_cmd(KEDEIRPI35_RAMWR);
  lcd_data(color, w*h);
}
Where I also tried to build table of colors all three different ways:
Code:
#define CL_RGB(_r,_g,_b) ((((_r)&0xF8)<<8)|(((_g)&0xFC)<<3)|((_b)>>3))
#define CL_BGR(_r,_g,_b) ((((_b)&0xF8)<<8)|(((_g)&0xFC)<<3)|((_r)>>3))
#define CL_NRGB(_r,_g,_b) (((((_r)&0xF8)<<8)|(((_g)&0xFC)<<3)|((_b)>>3))^0xffff)

const uint16_t colors_rgb[] = {
  CL_RGB(   0,   0,   0 ),
  CL_RGB(   0,   0, 128 ),
  CL_RGB(   0, 128,   0 ),
  CL_RGB(   0, 128, 128 ),
  CL_RGB( 128,   0,   0 ),
  CL_RGB( 128,   0, 128 ),
  CL_RGB( 128, 128,   0 ),
  CL_RGB( 192, 192, 192 ),
  CL_RGB( 128, 128, 128 ),
  CL_RGB(   0,   0, 255 ),
  CL_RGB(   0, 255,   0 ),
  CL_RGB(   0, 255, 255 ),
  CL_RGB( 255,   0,   0 ),
  CL_RGB( 255,   0, 255 ),
  CL_RGB( 255, 255,   0 ),
  CL_RGB( 255, 255, 255 ),
  CL_RGB( 255, 165,   0 ),
  CL_RGB( 173, 255,  47 ),
  CL_RGB( 255, 0,  255 )  
};

const uint16_t colors_bgr[] = {
  CL_BGR(   0,   0,   0 ),
  CL_BGR(   0,   0, 128 ),
  CL_BGR(   0, 128,   0 ),
  CL_BGR(   0, 128, 128 ),
  CL_BGR( 128,   0,   0 ),
  CL_BGR( 128,   0, 128 ),
  CL_BGR( 128, 128,   0 ),
  CL_BGR( 192, 192, 192 ),
  CL_BGR( 128, 128, 128 ),
  CL_BGR(   0,   0, 255 ),
  CL_BGR(   0, 255,   0 ),
  CL_BGR(   0, 255, 255 ),
  CL_BGR( 255,   0,   0 ),
  CL_BGR( 255,   0, 255 ),
  CL_BGR( 255, 255,   0 ),
  CL_BGR( 255, 255, 255 ),
  CL_BGR( 255, 165,   0 ),
  CL_BGR( 173, 255,  47 ),
  CL_BGR( 255, 0,  255 )  
};

const uint16_t colors_nrgb[] = {
  CL_NRGB(   0,   0,   0 ),
  CL_NRGB(   0,   0, 128 ),
  CL_NRGB(   0, 128,   0 ),
  CL_NRGB(   0, 128, 128 ),
  CL_NRGB( 128,   0,   0 ),
  CL_NRGB( 128,   0, 128 ),
  CL_NRGB( 128, 128,   0 ),
  CL_NRGB( 192, 192, 192 ),
  CL_NRGB( 128, 128, 128 ),
  CL_NRGB(   0,   0, 255 ),
  CL_NRGB(   0, 255,   0 ),
  CL_NRGB(   0, 255, 255 ),
  CL_NRGB( 255,   0,   0 ),
  CL_NRGB( 255,   0, 255 ),
  CL_NRGB( 255, 255,   0 ),
  CL_NRGB( 255, 255, 255 ),
  CL_NRGB( 255, 165,   0 ),
  CL_NRGB( 173, 255,  47 ),
  CL_NRGB( 255, 0,  255 ) 
};

const char* color_names[] = {"BLACK","NAVY","DARKGREEN","DARKCYAN",
"MAROON","PURPLE","OLIVE","LIGHTGREY",
"DARKGREY","BLUE","GREEN","CYAN","RED",
"MAGENTA","YELLOW","WHITE","ORANGE",
"GREENYELLOW","PINK"};

And Loop as:
Code:
uint16_t color_index = 0;
void loop() {
  delay(2500);
  SPI.beginTransaction(SPISettings(30000000, MSBFIRST, SPI_MODE0));
  Serial.print("Now Display color: ");
  Serial.print(color_names[color_index]);
  Serial.printf(" - %04x %04x %04x(%04x)\n",colors_rgb[color_index], colors_bgr[color_index],
    colors_nrgb[color_index], colors_rgb[color_index]^0xffff);
  fillRect(0,  0, 160, 320, colors_rgb[color_index]);
  fillRect(160,0, 160, 320, colors_bgr[color_index]);
  fillRect(320,0, 160, 320, colors_nrgb[color_index]);
  SPI.endTransaction();
  color_index++;
  if (color_index >= (sizeof(color_names)/sizeof(color_names[0]))) color_index = 0;
}

So will try to see what happens when I transfer those commands at start. Probably simple function like:
Code:
void spi_transferAndPrint32(uint32_t data32)
{
  Serial.printf("MOSI: %08x ", data32);
  Serial.printf(" MISO: %04x", data16 SPI.transfer16(data32 >> 16));
  Serial.printf(" %04x\n", SPI.transfer16(data32 & 0xffff));
}

Then add the calls to this with the data, and CS pins set in predefined...

Will try soon!
 
Hi @mjs513, @defragster -

And while doing so, wondered if the fix is something simple like: maybe we should not be using SPI_MODE0?

That is remember the data cleaned up when I changed the SPI analyzer to use trailing edge?

What happens if you change the Startup app, and change SPI_MODE0 to SPI_MODE1?

I have it trying to output the data (at startup with MODE3 and after Mode1...

View attachment KeDei_startup-190718a.zip

Edit forgot to try editing begin transaction in loop in above...
 
@KurtE - @defragster

Sorry - been distracted playing with this crazy display. Nothing seems to work to get it to right without negating the colors. I edited the kedei_simple sketch to pull in the startup from the other other sketch so been using that to play with. I did try mode3 and mode1 - no luck. Heres the sketch I was using - similar to what you just posted KurtE:

View attachment Kedei_simple2.zip
 
Back
Top