g0hjq / lcd_nixie_clock

Pseudo Nixie LCD clock in Micropython for the Waveshare kit and Pi Pico
MIT License
3 stars 5 forks source link

rgb565 #3

Open michaelmargolis opened 9 months ago

michaelmargolis commented 9 months ago

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?

g0hjq commented 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.