ILI9341_T4 and tgx color problems

Arctic_Eddie

Arctic_Eddie

Well-known member
I have a T4.1 and the 3.5" color touch display from PJRC. Using the ILI9341_t3 and XPT2046 libraries gives me the proper colors and touch action. I can use the color generator method and get what I expect. However, when using the ILI9341_T4 library, the colors come out wrong. An attempt to get dark gray comes out purple. Using a power of two gives an entirely different color than the some number minus 1. I pulled a color generator function from an earlier project using the same display and a T3.2 and it produces the right colors. The ILI9341_T4 library seems to have a bug in the color generation. My color generator code is shown below. An example generating dark gray with both methods produces the expected result with mine but total white with the other. There are other problems with this library to be posted separately, namely touch value stability.

Code: 
// Examples of the problem
#define DARKGRAY1   Color8To5(63,63,63)
#define DARKGRAY2   RGB565(63,63,63)

RGB565 Color8To5( uint16_t r, uint16_t g, uint16_t b )
{
    // Convert 888 color to 565 color
    uint16_t    c565;
    //c565 = ((r / 8) << 11) | ((g / 4) << 5) | (b / 8);
    c565 = ((r >> 3) << 11) | ((g >> 2) << 5) | (b >> 3);
    return c565;
}
 
I used the ILI9341_t3 library from the Arduino IDE repository and do not have any of those problems. The image quality is slightly better and colors are exactly as you would expect. My reason for trying the ILI9341_T4 version was to get image buffering for fast scans in a curve tracer project. We want to collect 280 pieces of data from a fast external ADC at 560KSPS while an external function generator runs at 2KHz. If Kurt's library has the DMA buffering then I'll try that one. Thanks for the heads up.
 
My library has the ability to choose to use a frame buffer. When turned on, all of your updates are written to the buffer.
Then if you call: updateScreen - it will directly update the screen. More or less the same as doing a writeRect...

However if you use instead: updateScreenAsync it uses DMA to update the screen from the buffer. The readme file has some details about the
different options. there.
 
I was just looking at some of your .h, .cpp, and examples and will try it tomorrow. I'll take my _T4 version but use your library. The IDE verify will show me what to fix. I want to update the screen at 60Hz with frames captured at that and higher sampling rates. I don't have to see each cycle of the test frequency but want to show them periodically at a flicker free rate. It's sort of like "grab a cycle when you can" like triggered oscopes act.
 
@Arctic_Eddie

Hi,

I was away from the forum for some time so my answer comes late and I guess you already moved on with your project but I just want to explain why you do not get the same colors with RGB565() and your Color8to5() function...

This is because the constructor RGB565(r,g,b) does not take inputs r,g,b in the range [0,255] but instead in their respective range (so r=[0,31], g=[0,63], b=[0,31])). Thus, in order to get the same color DARKGRAY you should call RGB565(8,16,8), or alternatively, you can specify the color using floating point values in the range [0.0, 1.0] so here, DARKGRAY can also be constructed with RGB565(0.25f, 0.25f, 0.25f). The advantage of the second method is that is works for any color types (RGB565, RGB24, RGB32,...) without having the adjust the value according to the depth of each color channel...
 
You must log in or register to reply here.
Back
Top