{"id":3135,"date":"2026-07-28T02:35:36","date_gmt":"2026-07-28T02:35:36","guid":{"rendered":"https:\/\/cml-a.com\/content\/?p=3135"},"modified":"2026-07-28T04:56:20","modified_gmt":"2026-07-28T04:56:20","slug":"the-colors-are-wrong-but-how","status":"publish","type":"post","link":"https:\/\/cml-a.com\/content\/2026\/07\/28\/the-colors-are-wrong-but-how\/","title":{"rendered":"The colors are wrong, but how?"},"content":{"rendered":"\n

Recently I got this Raspberry Pi Pico 2W<\/a> as a toy:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

It does come with a single blinking LED, you know, so you can check that basic things are working. So that's good. Since it's nice to actually display things, I got a small, simple display- a WaveShare 1.69\" LCD display<\/a> and hooked it up as follows: <\/p>\n\n\n\n

WaveShare LCD pin<\/th>Raspberry Pi Pico 2W semantic pin<\/th>Raspberry Pi Pico 2W global pin<\/th><\/tr><\/thead>
VCC<\/td>3v3<\/td>Pin 39<\/td><\/tr>
GND<\/td>GND<\/td>Pin 38<\/td><\/tr>
DIN<\/td>GP19, SPI0 TX<\/td>Pin 25<\/td><\/tr>
CLK<\/td>GP18, SPI0 SCK<\/td>Pin 24<\/td><\/tr>
CS<\/td>GP17, SPI0 CSn<\/td>Pin 22<\/td><\/tr>
DC<\/td>GP22<\/td>Pin 29<\/td><\/tr>
RST<\/td>GP13 (also SPI1CSn)<\/td>Pin 17<\/td><\/tr>
BL<\/td>GP21<\/td>Pin 27<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

The initial functions like powering it on, turning on the backlight and clearing the screen to white and black seemed to work. The only thing is, the colors were wrong. For example, if I tried to clear to RED, well, the sample code has<\/p>\n\n\n\n

#define RED           0xF800<\/code><\/pre>\n\n\n\n
Except when I try it, it looks like blue.<\/p>\n\n\n\n
Not a big deal, figure the red\/blue channels are swapped. Very common problem. The documentation, regarding color formats, says <\/p>\n\n\n\n
\n
This LCD supports input color formats of 12-bit, 16-bit, and 18-bit per pixel, which are
RGB444, RGB565, and RGB666. This demo example uses the RGB565 color format,
which is also a commonly used RGB format.<\/p>\n<\/blockquote>\n\n\n\n
That makes it sound like channel swapping is unlikely, and the demo is supposed to be RGB565, but who knows. Or it might be RGB444 with unused bits. I haven't worked with this device before and I couldn't find any clarifying documentation on the mode selection so I don't know.<\/p>\n\n\n\n
So as another test, I try<\/p>\n\n\n\n
#define GREEN         0x07E0<\/code><\/pre>\n\n\n\n
since that should work, irrespective of red-blue channel swapping. Right? <\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Wrong. Instead of being green, it looks red now. I guess it's good to know that the different color channels are capable of displaying, But what kind of absolute madman would put red in the middle<\/em> of the format? It doesn't match any of the formats it listed support for, and seems like a very strange decision. Clearly something weird is going on.<\/p>\n\n\n\n
As a mini investigation, I did a test where I turned each of the 16 bits of the image data on in turn, to see the effects. <\/p>\n\n\n\n
At this point, I don't 100% know how many bits are in each channel or how the channels are ordered. <\/strong><\/p>\n\n\n\n
But, I was looking for<\/p>\n\n\n\n