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

I had bad constructor value - changed to this:: KEDEIRPI35_t3 tft = KEDEIRPI35_t3(&SPI, 10, 6, 11, 13, 12); //10,6,11,13,12

Colors are all wrong: using the snippet above with names and here is the Draw Pallet:
View attachment 16996

Though with edited constructor above I don't get valid touch mapping - just static points and no drawing …

Lost cause … ???
 
@defragster - that looks exactly like my screen with the exception that touchscreen worked :) I don't have to use the full constructor though to get it to work.
 
Yes, it says v6.3 - 2018/4/9

I have dupont wires to T4 - 5V from Vin pin … I can readjust to anything

I posted mine before - I suppose you did too - … and of course the code … let me see
 
Okay moved 6 to 9 for touch - to use the code as written:
Code:
KEDEIRPI35_t3 tft = KEDEIRPI35_t3(&SPI, TFT_CS, STMPE_CS);  //10,9,11,13,12
//KEDEIRPI35_t3 tft = KEDEIRPI35_t3(&SPI, 10, 6, 11, 13, 12); //10,6,11,13,12

Got working touch - you can see I touched each color selector and drew with it - but the colors are quite wrong::
20190715_163832.jpg

Versus your post:
View attachment 16987
 
@defragster - that looks exactly like my screen with the exception that touchscreen worked :) I don't have to use the full constructor though to get it to work.

I just used the full constructor because it worked before - then I knew what the pins were … and they were explicit … to get working touch as posted I dropped those and except colors it works now.
 
@KurtE - @defragster

@defragster - was just letting you know what I had to get it to work. Anyway I just retry mine with the latest updates and this is what I am seeing:

20190715_195617.jpg

Not sure why the differences between the 3 displays. Just something strange with the Kedei
 
Looks sort of screwy! Actually you can use either constructor, it should end up through the same code...

You might post a picture of the back of your display, is it labeled the same as the one I have? Showing the same version.
ILI948x-displays.jpg

Sorry I used existing photo with other display as well
 
@KurtE

No worries about the pic. I just checked the back of my display and it has the exact same identification that is on your display:
20190715_202841.jpg
 
Freaky … I turned it off to hit the uncannyEyes again on another T4 - then this T4 back on - the color bar NOW matches p#381 pic of MJS513 - including two greens in middle though FAR RIGHT (before last I see as WHITE) Dark Gray looks darker - though my leftmost YELLOW is more washed out.

This includes the WHITE background that should be BLACK - and the rightmost box is labelled BLACK - but filled and draws white.

Touching each color does not print the right color name as touched though - though the drawn color matches the color block touched.
Here is what I get in order following mjs513 pic above starting with what looks like leftmost YELLOW then RED prints:
New color: RED
New color: YELLOW
New color: GREEN
New color: CYAN
New color: BLUE
New color: MAGENTA
New color: PINK
New color: ORANGE
New color: WHITE
New color: LIGHTGREY
New color: DARKGREY
New color: BLACK

@KurtE - the back of my display looks JUST like the right one in p#382 photo
 
@KurtE - @defragster

Didn't realize there was a white box on the far right - when I hit White the sermon shows black, when I hit black it shows White.
 
This is sort of strange...

Note: in KeDeiRPI..h file
I have colors defined two different ways.
Code:
// Color definitions
#ifdef RGB_COLORS
#define KEDEIRPI35_BLACK       0x0000      /*   0,   0,   0 */
#define KEDEIRPI35_NAVY        0x000F      /*   0,   0, 128 */
#define KEDEIRPI35_DARKGREEN   0x03E0      /*   0, 128,   0 */
#define KEDEIRPI35_DARKCYAN    0x03EF      /*   0, 128, 128 */
#define KEDEIRPI35_MAROON      0x7800      /* 128,   0,   0 */
#define KEDEIRPI35_PURPLE      0x780F      /* 128,   0, 128 */
#define KEDEIRPI35_OLIVE       0x7BE0      /* 128, 128,   0 */
#define KEDEIRPI35_LIGHTGREY   0xC618      /* 192, 192, 192 */
#define KEDEIRPI35_DARKGREY    0x7BEF      /* 128, 128, 128 */
#define KEDEIRPI35_BLUE        0x001F      /*   0,   0, 255 */
#define KEDEIRPI35_GREEN       0x07E0      /*   0, 255,   0 */
#define KEDEIRPI35_CYAN        0x07FF      /*   0, 255, 255 */
#define KEDEIRPI35_RED         0xF800      /* 255,   0,   0 */
#define KEDEIRPI35_MAGENTA     0xF81F      /* 255,   0, 255 */
#define KEDEIRPI35_YELLOW      0xFFE0      /* 255, 255,   0 */
#define KEDEIRPI35_WHITE       0xFFFF      /* 255, 255, 255 */
#define KEDEIRPI35_ORANGE      0xFD20      /* 255, 165,   0 */
#define KEDEIRPI35_GREENYELLOW 0xAFE5      /* 173, 255,  47 */
#define KEDEIRPI35_PINK        0xF81F
#define CL(_r,_g,_b) ((((_r)&0xF8)<<8)|(((_g)&0xFC)<<3)|((_b)>>3))
#else
// Looks like we are BGR format
#define KEDEIRPI35_BLACK       0x0000    /*   0,   0,   0, RGB:0x0000 */
#define KEDEIRPI35_NAVY        0x7800    /*   0,   0, 120, RGB:0x000f */
#define KEDEIRPI35_DARKGREEN   0x03e0    /*   0, 124,   0, RGB:0x03e0 */
#define KEDEIRPI35_DARKCYAN    0x7be0    /*   0, 124, 120, RGB:0x03ef */
#define KEDEIRPI35_MAROON      0x000f    /* 120,   0,   0, RGB:0x7800 */
#define KEDEIRPI35_PURPLE      0x780f    /* 120,   0, 120, RGB:0x780f */
#define KEDEIRPI35_OLIVE       0x03ef    /* 120, 124,   0, RGB:0x7be0 */
#define KEDEIRPI35_LIGHTGREY   0xc618    /* 192, 192, 192, RGB:0xc618 */
#define KEDEIRPI35_DARKGREY    0x7bef    /* 120, 124, 120, RGB:0x7bef */
#define KEDEIRPI35_BLUE        0xf800    /*   0,   0, 248, RGB:0x001f */
#define KEDEIRPI35_GREEN       0x07e0    /*   0, 252,   0, RGB:0x07e0 */
#define KEDEIRPI35_CYAN        0xffe0    /*   0, 252, 248, RGB:0x07ff */
#define KEDEIRPI35_RED         0x001f    /* 248,   0,   0, RGB:0xf800 */
#define KEDEIRPI35_MAGENTA     0xf81f    /* 248,   0, 248, RGB:0xf81f */
#define KEDEIRPI35_YELLOW      0x07ff    /* 248, 252,   0, RGB:0xffe0 */
#define KEDEIRPI35_WHITE       0xffff    /* 248, 252, 248, RGB:0xffff */
#define KEDEIRPI35_ORANGE      0x053f    /* 248, 164,   0, RGB:0xfd20 */
#define KEDEIRPI35_GREENYELLOW 0x2ff5    /* 168, 252,  40, RGB:0xafe5 */
#define KEDEIRPI35_PINK        0xf81f    /* 248,   0, 248, RGB:0xf81f */
#define CL(_r,_g,_b) ((((_b)&0xF8)<<8)|(((_g)&0xFC)<<3)|((_r)>>3))
#endif
Maybe try defining the name RGB_COLORS
And see if that changes anything...

If not Maybe try changing the define to #if 0
And see if by chance maybe somewhere else defined it...

Or try running the earlier simple test which uses the old code...
The loop runs through different colors printing out names as it goes...

But before that it tries to output 18 bit color frames as part of setup. Wondering if those look right on your display?
I will try to play with it later. But maybe put a print out of the R, G, B colors passed in and a delay after so you can see if the colors look right...
 

Attachments

  • Kedei_simple-190715a.zip
    3.8 KB · Views: 53
@KurtE - quick look SubLime doesn't find other defines of those color names - and build fails if they are all gone with "#if 0"

As far as the #ifdef RGB_COLORS - it makes the colors diff on touchpaint color bar - but not better and not right.

Also 0's and F's are not exchanged with that - white and black still swapped

I did exchange white and black and BLACK comes out MAGENTA colored.

Something wrong in the color map translation?

gotta run ...
 
@KurtE - @defragster

Playing around with the simple kedei sketch in post #386 the colors are still off so I put in a wait for input loop so I can try to match the colors to screen. I got this, it looks like the bits need to be flipped when being sent. The colors with a c next to it I think make it colors maybe @defragster can check:
Code:
uint16_t colors[16] = {
  0b0000000000000000,				/* WHITEc	000000 */
  0b0000000000010000,				/* NAVY		000080 */
  0b0000000000011111,				/* YELLOWc		0000ff */
  0b0000010011000000,				/* GREEN	009900 */
  0b0000010011010011,				/* TEAL		009999 */
  0b0000011111100000,				/* LIME		00ff00 */
  0b0000011111111111,				/* REDc		00ffff */
  0b1000000000000000,				/* MAROON	800000 */
  0b1000000000010000,				/* PURPLE	800080 */
  0b1001110011000000,				/* OLIVE	999900 */
  0b1000010000010000,				/* GRAY		808080 */
  0b1100111001111001,				/* SILVER	cccccc */
  0b1111100000000000,				/* AQUAc		ff0000 */
  0b1111100000011111,				/* GREENc	ff00ff */
  0b1111111111100000,				/* BLUEc	ffff00 */
  0b1111111111111111				/* BLACKc	ffffff */
};
const char* colorNames[] = {
  "WHITEc: ",
  "NAVY: ",
  "YELLOWc: ",
  "FUCHSIA: ",
  "TEAL: ",
  "LIME: ",
  "REDc: ",
  "MAROON: ",
  "PURPLE: ",
  "OLIVE: ",
  "GRAY: ",
  "SILVER: ",
  "AQUA: ",
  "GREENc: ",
  "BLUEc: ",
  "BLACKc: "};
 
@KurtE - @defragster
Ok in the loop if I change in your kedei_simple sketch
Code:
  lcd_fillframe(0, 0, lcd_w, lcd_h, (colors[color]));
to
Code:
  lcd_fillframe(0, 0, lcd_w, lcd_h, 0xFFFFFF -(colors[color]));
the colors seem to match. To black out the screen I just use
Code:
  lcd_fillRGB(0xFF, 0xFF, 0xFF);
instead of
Code:
lcd_fill(0x0)
 
@KurtE - @defragster

If you do the following in the GITHUB .h file:
Code:
#define RGB_COLORS 1
// Color definitions
#ifdef RGB_COLORS
#define KEDEIRPI35_BLACK       0xFFFF-0x0000      /*   0,   0,   0 */
#define KEDEIRPI35_NAVY        0xFFFF-0x000F      /*   0,   0, 128 */
#define KEDEIRPI35_DARKGREEN   0xFFFF-0x03E0      /*   0, 128,   0 */
#define KEDEIRPI35_DARKCYAN    0xFFFF-0x03EF      /*   0, 128, 128 */
#define KEDEIRPI35_MAROON      0xFFFF-0x7800      /* 128,   0,   0 */
#define KEDEIRPI35_PURPLE      0xFFFF-0x780F      /* 128,   0, 128 */
#define KEDEIRPI35_OLIVE       0xFFFF-0x7BE0      /* 128, 128,   0 */
#define KEDEIRPI35_LIGHTGREY   0xFFFF-0xC618      /* 192, 192, 192 */
#define KEDEIRPI35_DARKGREY    0xFFFF-0x7BEF      /* 128, 128, 128 */
#define KEDEIRPI35_BLUE        0xFFFF-0x001F      /*   0,   0, 255 */
#define KEDEIRPI35_GREEN       0xFFFF-0x07E0      /*   0, 255,   0 */
#define KEDEIRPI35_CYAN        0xFFFF-0x07FF      /*   0, 255, 255 */
#define KEDEIRPI35_RED         0xFFFF-0xF800      /* 255,   0,   0 */
#define KEDEIRPI35_MAGENTA     0xFFFF-0xF81F      /* 255,   0, 255 */
#define KEDEIRPI35_YELLOW      0xFFFF-0xFFE0      /* 255, 255,   0 */
#define KEDEIRPI35_WHITE       0xFFFF-0xFFFF      /* 255, 255, 255 */
#define KEDEIRPI35_ORANGE      0xFFFF-0xFD20      /* 255, 165,   0 */
#define KEDEIRPI35_GREENYELLOW 0xFFFF-0xAFE5      /* 173, 255,  47 */
#define KEDEIRPI35_PINK        0xFFFF-0xF81F
you will get this for touchpaint
20190716_085444.jpg

As a note GrahicsTestKedei and RotationTest exactly matches what Kurt previously posted
 
@mjs513 @defragster - Interesting. I am wondering if maybe the MADCTL values are incorrect for your display. This is the thing that controls things like change directions of bits and the like.

So I updated the library some, to do a couple of things.
a) sendCommand added so I can muck with stuff outside
b) made the setRotation MADCTL value be in public array so test app can look at them as well.
c) Test app (my rotation test for bounds) - I added it as an example app.
It displays test screen: and says hit any key to continue.
Most keys: it will increment the rotation and redraw display: Now printing something like:
Code:
Set Rotation: 1 (4a) width: 320 height: 480
Hit any key to continue
Set Rotation: 2 (2a) width: 480 height: 320
Hit any key to continue
Set Rotation: 3 (8a) width: 320 height: 480
Hit any key to continue
Set Rotation: 0 (ea) width: 480 height: 320
Hit any key to continue
Note the number in () is the MADCTL for the rotation.

As before entering a . will draw line around what it thinks is the bounds.
more .s will print one pixel farther into rectangle...

But added: m does a madtl test.

It will iterate trying to change one bit of the Madctl (starting with lowest) and redraw the screen.
So you can hopefully cycle through and see if one bit magically gives you the right colors... (Fingers crossed).

Screen should look something like:
KeDeiTest.jpg
You will notice I added a few more rectangles...
 
@KurtE
Just gave it a try and the changing the madtl does change the colors to the correct ones. The only thing that does it is to invert RGB colors. Then it works as you show. Sorry.

Strange display
 
@mjs513 - Did you say that changing the MADCTL did work to get the right colors on your display?

If so which value worked? So I might try that change on my display and hopefully it still works on mine...
 
@mjs513 - Did you say that changing the MADCTL did work to get the right colors on your display?

If so which value worked? So I might try that change on my display and hopefully it still works on mine...
Oh wasn't clear - none of them worked. Sorry.

I did break down and ordered another display just as a test - I screwed up that second one that I bought. Will get it Thursday. Don't know if its worth spending more time on this one.
 
I was thinking we could simply define the colors to work on both sets... I thought of using the CL defines like:
#define CL(_r,_g,_b) ((((_b)&0xF8)<<8)|(((_g)&0xFC)<<3)|((_r)>>3))
so for Red we would have: KEDEIRPI35_RED CL(255, 0, 0 )

But was experimenting with another test app I did to convert colors for RGB to BGR...
Code:
#define CLRGB(_r,_g,_b) ((((_r)&0xF8)<<8)|(((_g)&0xFC)<<3)|((_b)>>3))
#define CLBGR(_r,_g,_b) ((((_b)&0xF8)<<8)|(((_g)&0xFC)<<3)|((_r)>>3))
#define CLNBGR(_r,_g,_b) ((CLBGR(_r, _g, _b))^0xffff)

uint16_t color565_RGB(uint8_t r, uint8_t g, uint8_t b) {
  return ((r & 0xF8) << 8) | ((g & 0xFC) << 3) | (b >> 3);
}

uint16_t color565_BGR(uint8_t r, uint8_t g, uint8_t b) {
  return ((b & 0xF8) << 8) | ((g & 0xFC) << 3) | (r >> 3);
}

void printColor(uint8_t r, uint8_t g, uint8_t b) {
  Serial.printf("r:%3u g:%3u b:%3u RGB:%04x GRB:%04x ",
                r, g, b, color565_RGB(r, g, b), 
                color565_BGR(r, g, b));
  Serial.printf(" Macros: %04x %04x %04x ",
                CLRGB(r, g, b), CLBGR(r, g, b), CLNBGR(r, r, b));
  Serial.print(CLNBGR(r, r, b), HEX);
  uint16_t color = CLBGR(r, g, b);
  Serial.print(" ");
  Serial.println((uint16_t)~color, HEX);
}

void PrintRGBtoBGRConversion(uint16_t colorRGB) {
    uint8_t r = (colorRGB>>8)&0x00F8;
    uint8_t g = (colorRGB>>3)&0x00FC;
    uint8_t b = (colorRGB<<3)&0x00F8;
    Serial.printf("0x%04x    /* %3d, %3d, %3d, RGB:0x%04x */\n",
        color565_BGR(r,g,b), r, g, b, colorRGB);
}

void setup() {
  while (!Serial && millis() < 5000) ;
  Serial.begin(38400);
  delay(100);
  Serial.println("program started");
  Serial.println(~0x400, HEX);
  delay(100);
  printColor(   0,   0,   0);
  printColor(   0,   0, 128);
  printColor(   0, 128,   0);
  printColor(   0, 128, 128);
  printColor( 128,   0,   0);
  printColor( 128,   0, 128);
  printColor( 128, 128,   0);
  printColor( 192, 192, 192);
  printColor( 128, 128, 128);
  printColor(   0,   0, 255);
  printColor(   0, 255,   0);
  printColor(   0, 255, 255);
  printColor( 255,   0,   0);
  printColor( 255,   0, 255);
  printColor( 255, 255,   0);
  printColor( 255, 255, 255);
  printColor( 255, 165,   0);
  printColor( 173, 255,  47);

  // Now lets try it by printing conversions
  PrintRGBtoBGRConversion(0x0000  );
  PrintRGBtoBGRConversion(0x000F  );
  PrintRGBtoBGRConversion(0x03E0  );
  PrintRGBtoBGRConversion(0x03EF  );
  PrintRGBtoBGRConversion(0x7800  );
  PrintRGBtoBGRConversion(0x780F  );
  PrintRGBtoBGRConversion(0x7BE0  );
  PrintRGBtoBGRConversion(0xC618  );
  PrintRGBtoBGRConversion(0x7BEF  );
  PrintRGBtoBGRConversion(0x001F  );
  PrintRGBtoBGRConversion(0x07E0  );
  PrintRGBtoBGRConversion(0x07FF  );
  PrintRGBtoBGRConversion(0xF800  );
  PrintRGBtoBGRConversion(0xF81F  );
  PrintRGBtoBGRConversion(0xFFE0  );
  PrintRGBtoBGRConversion(0xFFFF  );
  PrintRGBtoBGRConversion(0xFD20  );
  PrintRGBtoBGRConversion(0xAFE5  );
  PrintRGBtoBGRConversion(0xF81F);


}

void loop()
{
}

And was getting strange results when I tried to define your version of CL something like (~(CL(r, g, b))) or (CL(r,g,b)^0xffff) probably what the compiler did with it. Now I did it with variables, not sure if I just did it with constants yet... will try that next... But got different results if I stored the CL first into variable and then did the not operation or xor...
Code:
r:  0 g:  0 b:  0 RGB:0000 GRB:0000  Macros: 0000 0000 ffff FFFF FFFF
r:  0 g:  0 b:128 RGB:0010 GRB:8000  Macros: 0010 8000 7fff 7FFF 7FFF
r:  0 g:128 b:  0 RGB:0400 GRB:0400  Macros: 0400 0400 ffff FFFF FBFF
r:  0 g:128 b:128 RGB:0410 GRB:8400  Macros: 0410 8400 7fff 7FFF 7BFF
r:128 g:  0 b:  0 RGB:8000 GRB:0010  Macros: 8000 0010 fbef FBEF FFEF
r:128 g:  0 b:128 RGB:8010 GRB:8010  Macros: 8010 8010 7bef 7BEF 7FEF
r:128 g:128 b:  0 RGB:8400 GRB:0410  Macros: 8400 0410 fbef FBEF FBEF
r:192 g:192 b:192 RGB:c618 GRB:c618  Macros: c618 c618 39e7 39E7 39E7
r:128 g:128 b:128 RGB:8410 GRB:8410  Macros: 8410 8410 7bef 7BEF 7BEF
r:  0 g:  0 b:255 RGB:001f GRB:f800  Macros: 001f f800 07ff 7FF 7FF
r:  0 g:255 b:  0 RGB:07e0 GRB:07e0  Macros: 07e0 07e0 ffff FFFF F81F
r:  0 g:255 b:255 RGB:07ff GRB:ffe0  Macros: 07ff ffe0 07ff 7FF 1F
r:255 g:  0 b:  0 RGB:f800 GRB:001f  Macros: f800 001f f800 F800 FFE0
r:255 g:  0 b:255 RGB:f81f GRB:f81f  Macros: f81f f81f 0000 0 7E0
r:255 g:255 b:  0 RGB:ffe0 GRB:07ff  Macros: ffe0 07ff f800 F800 F800
r:255 g:255 b:255 RGB:ffff GRB:ffff  Macros: ffff ffff 0000 0 0
r:255 g:165 b:  0 RGB:fd20 GRB:053f  Macros: fd20 053f f800 F800 FAC0
r:173 g:255 b: 47 RGB:afe5 GRB:2ff5  Macros: afe5 2ff5 d28a D28A D00A
Probably something stupid I am doing... The last three numbers on each line are the negated. First was done part of Serial.printf, just to make sure I was outputting correctly, 2nd one was output by itself using Serial.print(...,HEX);
last one was assigning value to variable than inverting, which is correct. :confused:
 
Found new rotationColorPos sketch - I didn't see anything good come of it.

Though I'm wondering back to when mine came up better yesterday when I re-powered it? i.e. does the device have any static settings only applied at power up?

@mjs513 did what I should have tried with negation rather than just swapping 0's for F's - I didn't try #388 or #390 yet.
 
Hi @mjs513 and @defragster and ...

I did a hack for the define of colors, which you might try out and see if it works for you?
Code:
// Color definitions
// Warning Some of these display appear to use RGB colors
//                     Others use BGR colors
//                     And some appear to use negated BGR
// Define at most only one of these...
//#define RGB_COLORS
//#define BGR_COLORS
#define NBGR_COLORS
#if 1

#ifdef RGB_COLORS
#define CL(_r,_g,_b) ((((_r)&0xF8)<<8)|(((_g)&0xFC)<<3)|((_b)>>3))
#elif defined(BGR_COLORS)
#define CL(_r,_g,_b) ((((_b)&0xF8)<<8)|(((_g)&0xFC)<<3)|((_r)>>3))
#else  // negated BGR colors
#define CL(_r,_g,_b) (((((_b)&0xF8)<<8)|(((_g)&0xFC)<<3)|((_r)>>3))^0xffff)
#endif
#define KEDEIRPI35_BLACK       CL(   0,   0,   0 )
#define KEDEIRPI35_NAVY        CL(   0,   0, 128 )
#define KEDEIRPI35_DARKGREEN   CL(   0, 128,   0 )
#define KEDEIRPI35_DARKCYAN    CL(   0, 128, 128 )
#define KEDEIRPI35_MAROON      CL( 128,   0,   0 )
#define KEDEIRPI35_PURPLE      CL( 128,   0, 128 )
#define KEDEIRPI35_OLIVE       CL( 128, 128,   0 )
#define KEDEIRPI35_LIGHTGREY   CL( 192, 192, 192 )
#define KEDEIRPI35_DARKGREY    CL( 128, 128, 128 )
#define KEDEIRPI35_BLUE        CL(   0,   0, 255 )
#define KEDEIRPI35_GREEN       CL(   0, 255,   0 )
#define KEDEIRPI35_CYAN        CL(   0, 255, 255 )
#define KEDEIRPI35_RED         CL( 255,   0,   0 )
#define KEDEIRPI35_MAGENTA     CL( 255,   0, 255 )
#define KEDEIRPI35_YELLOW      CL( 255, 255,   0 )
#define KEDEIRPI35_WHITE       CL( 255, 255, 255 )
#define KEDEIRPI35_ORANGE      CL( 255, 165,   0 )
#define KEDEIRPI35_GREENYELLOW CL( 173, 255,  47 )
#define KEDEIRPI35_PINK        CL( 255, 0,  255 )

#else
I left it in the probably negated format, it looked OK I think on my display with BGR set...
 
@KurtE

Had to make a slight change to get colors to match and touchpaint to match what you had:
Code:
// Define at most only one of these...
//#define RGB_COLORS
//#define BGR_COLORS
//#define NBGR_COLORS
[COLOR="#FF0000"]#define NRGB_COLORS[/COLOR]

#if 1

#ifdef RGB_COLORS
#define CL(_r,_g,_b) ((((_r)&0xF8)<<8)|(((_g)&0xFC)<<3)|((_b)>>3))
#elif defined(BGR_COLORS)
#define CL(_r,_g,_b) ((((_b)&0xF8)<<8)|(((_g)&0xFC)<<3)|((_r)>>3))
#elif defined(NBGR_COLORS)  // negated BGR colors
#define CL(_r,_g,_b) (((((_b)&0xF8)<<8)|(((_g)&0xFC)<<3)|((_r)>>3))^0xffff)
#else
[COLOR="#FF0000"]#define CL(_r,_g,_b) (((((_r)&0xF8)<<8)|(((_g)&0xFC)<<3)|((_b)>>3))^0xffff)[/COLOR]
#endif

One funny thing is that white and lightgrey seem to be reversed for some reason.
 
Thanks Mike,

I think I updated it the way you mentioned, plus update the functional colors to numbers...
Although I must mention never actually tried them. tft.fillScreen(KEDEIRPI35_t3::color565(64, 64, 64));

Hopefully this should put this reasonably to bed.

Or sort of a comment back to earlier posts. We could always maybe try to really properly understand the startup sequence that RPI does with these PO..

That is as mentioned before I do have an Logic analyzer capture of a startup on RPI... I have also had the LA output a CSV file of the SPI transfers. That starts off 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
6.521946556000000,4,0x00,0x00
6.521946844000000,4,0x11,0x00
6.521947132000000,4,0x00,0x00
6.521947420000000,4,0x00,0x00
6.531950320000000,5,0x00,0x00
6.531950608000000,5,0x11,0x00
6.531950896000000,5,0x00,0x00
6.531951184000000,5,0xFF,0x00
6.531952084000000,6,0x00,0xFF
6.531952372000000,6,0x11,0xEE
6.531952660000000,6,0x00,0x00
6.531952948000000,6,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
6.556963300000000,7,0x00,0x00
6.556963588000000,7,0x11,0x00
6.556963876000000,7,0x00,0x00
6.556964164000000,7,0x11,0x00
6.706982484000000,8,0x00,0x00
6.706982772000000,8,0x11,0x00
6.706983060000000,8,0x00,0x00
6.706983348000000,8,0xB0,0x00
6.706984104000000,9,0x00,0xFF
6.706984392000000,9,0x15,0xCA
6.706984680000000,9,0x00,0x00
6.706984968000000,9,0x00,0x00
6.706985964000000,10,0x00,0xFF
6.706986252000000,10,0x11,0xC8
6.706986540000000,10,0x00,0x00
6.706986828000000,10,0xB3,0x00
6.706987584000000,11,0x00,0xFF[/CODE]
The file has something like 805901 lines in it.
Earlier which I did not save I had Sublime test regular expression search and replace. These are mostly groups of 4 bytes associated with each actual transfer:
Example these 4 line:
Code:
6.556963300000000,7,0x00,0x00
6.556963588000000,7,0x11,0x00
6.556963876000000,7,0x00,0x00
6.556964164000000,7,0x11,0x00
We know is it is outputting a command by second byte being 0x11 (DC Asserted) So we transfer: 0x00 0x11 0x00 0x11

likewise:
Code:
6.706984104000000,9,0x00,0xFF
6.706984392000000,9,0x15,0xCA
6.706984680000000,9,0x00,0x00
6.706984968000000,9,0x00,0x00
We know we are sending a data byte: 0x00 0x14

So for example maybe there are initing something else that we are not doing...

But for now probably close enough to punt ;)
 
@KurtE

I was beginning to do that before you got the initial sketch that we started from working so I just left it at that. Don't know if it worth it at this point to spend that much time going through the LA dump to figure out wants going on - but I know we will at some point :)

Think for now maybe punt while we catch up on other distractions.

<EDIT> the thing that hit me about the startup sequence is that it really didn't match anything I was seeing in the available drivers even for 9488.....
 
Back
Top