I noticed that I was getting odd colors that didn't match other elements on my screen drawn with the same colors. Pixels drawn with fillRect() had the correct colors, but pixels drawn with drawPixels() didn't. I tracked it down to this function in RA8875.h:
//convert a 16bit color(565) into 8bit color(332) as requested by RA8875 datasheet
inline __attribute__((always_inline))
uint8_t _color16To8bpp(uint16_t color) {
return ((color & 0x3800) >> 6 | (color & 0x00E0) >> 3 | (color & 0x0003));
}
It's taking the low-order bits of the 565 color instead of the high-order bits. Correcting it to this:
//convert a 16bit color(565) into 8bit color(332) as requested by RA8875 datasheet
inline __attribute__((always_inline))
uint8_t _color16To8bpp(uint16_t color) {
return ((color & 0xE000) >> 8 | (color & 0x0700) >> 6 | (color & 0x0018) >> 3);
}
Fixed my problem nicely.
What I also need to do is create a function, drawPixels8(), that takes the pixel array already in 8-bit color. It seems a bit silly to build a line of 16-bit pixels (the source data is 4-bit IRGB) only to have drawPixels() convert them again.
I noticed that I was getting odd colors that didn't match other elements on my screen drawn with the same colors. Pixels drawn with fillRect() had the correct colors, but pixels drawn with drawPixels() didn't. I tracked it down to this function in RA8875.h:
It's taking the low-order bits of the 565 color instead of the high-order bits. Correcting it to this:
Fixed my problem nicely.
What I also need to do is create a function, drawPixels8(), that takes the pixel array already in 8-bit color. It seems a bit silly to build a line of 16-bit pixels (the source data is 4-bit IRGB) only to have drawPixels() convert them again.