Open michaelmargolis opened 9 months ago
Hi Michael,
Thank you for your suggestion. I think I did start off like that at first, but the colours displayed on the LCD did not look right. After some experimentation, I determined that the LCDs expected RGB565 data in the following format, with 3 bits of green at each end, i.e.
g2 g1 g2 b4 b3 b2 b1 b0 r4 r3 r2 r1 r0 g5 g4 g3 .
Odd, but that is how they seem to work. I don't know if the LCD driver chips support other formats, or, if they do, what initialisation values would be needed.
I used 4 stages of mask and shifting in fonts/animation_convert.py when preparing the 10 nixie tube image files, in the file fonts/animation_convert.py :
def color_to_bytes (color):
r, g, b = color
arr = bytearray(2)
arr[0] = r & 0xF8
arr[0] += (g & 0xE0) >> 5
arr[1] = (g & 0x1C) << 3
arr[1] += (b & 0xF8) >> 3
return arr
But I decided not to in display.py to make it more obvious what was going on, and easier to change should I ever need to. I suppose a much faster way would be to use lookup tables, but as rgb_to_int() is only called a few times during initialisation, speed isn't an issue.
The display code has an rgb_to_int function that converts rgb to rgb565 according to the comment but the function returns different values from the traditional and much simpler conversion method.
Pure red as rgb565 = 0xf800 display code returns 0xf8 Pure green as rgb565 = 0x7e0 display code returns 0xe007
The traditional method is:
rgb565 = ((r & 0xF8) << 8) | ((g & 0xFC) << 3) | (b >> 3)
This has 7 bitwise operations compared to over 60 used in the display rgb_to_int() function.Is there a reason not to change the LCD init code to support conventional rgb565 format?