STM CircleOS forum / the color codes

ThomasScherrer · 2007-10-30 16:14:58

where is all color codes described ?
like:
[in] Color The new RGB color for background.
I know it is 64k col display so it is 16 bits in total,
how is this organized ?

Francis · 2007-10-30 19:33:54

See in the datasheet of the ST7637 (the controller of the LCD monitor)
http://www.stm32circle.com/projects/fil … v0%204.pdf

The explanation is also in the header files:

/* Exported defines ----------------------------------------------------------*/
//RGB is 16-bit coded as G2G1G0B4 B3B2B1B0 R4R3R2R1 R0G5G4G3
#define RGB_MAKE(xR,xG,xB) ( ( (xG&0x07)<<13 ) + ( (xG)>>5 ) + \
( ((xB)>>3) << 8 ) + \
( ((xR)>>3) << 3 ) )
#define RGB_RED 0x00F8
#define RGB_BLACK 0x0000
#define RGB_WHITE 0xffff
#define RGB_BLUE 0x1F00
#define RGB_GREEN 0xE007
#define RGB_YELLOW (RGB_GREEN|RGB_RED)
#define RGB_MAGENTA (RGB_BLUE|RGB_RED)
#define RGB_LIGHTBLUE (RGB_BLUE|RGB_GREEN)
#define RGB_ORANGE (RGB_RED | 0xE001) //green/2 + red
#define RGB_PINK (RGB_MAGENTA | 0xE001) //green/2 + magenta

ThomasScherrer · 2007-10-31 10:01:32

great thanks, that explain the wierdo results I got hehe
yes I found the RGB macro but did not understand the idea,
now when I have seen the bits organized like this
RGB is 16-bit coded as G2G1G0B4 B3B2B1B0 R4R3R2R1 R0G5G4G3
I see the light :-)

hammondeggs · 2008-01-19 07:33:36

This is technically 'wrong', as in the circle OS's LCD.C you have:
// Draw pixel.
LCD_SendLCDData( Color );
LCD_SendLCDData( Color >> 8 );
Where the first line actually sends the low byte and the second will send the high byte. If this were inverted, this would follow the LCD spec sheet, (see "65K color input mode - 8 bit mode) and be much easier / faster to manipulate bits around for colors, and wouldn't require anywhere near as much ugly bitshifting.
(R4R3R2R1R0G5G4G3G2G1G0B4B3B2B1B0 makes so much more sense now doesn't it?

Ah well.

Last edited by hammondeggs (2008-01-19 07:40:33)

mkoleda · 2009-11-26 21:05:32

Hi guys,

I had troubles to go through the full RGB spectrum. the point was to go from black to white. using RGB_MAKE I got sudden changes and discovered that the green component changed its intensity in greater steps even if I was just increasing its level the same increment as the other colours (I know it has 1 bit longer resolution, but these were DRASTIC changes). look at the definition:
/* Exported defines ----------------------------------------------------------*/
//RGB is 16-bit coded as G2G1G0B4 B3B2B1B0 R4R3R2R1 R0G5G4G3
#define RGB_MAKE(xR,xG,xB) ( ( (xG&0x07)<<13 ) + ( (xG)>>5 ) + \
( ((xB)>>3) << 8 ) + \
( ((xR)>>3) << 3 ) )

unfortunately, if we would mark the bits of green component from 7 to 0, looking at the bit operation ( (xG&0x07)<<13 ) + ( (xG)>>5 ) we simply loose bits 4 and 3. I strongly recommend this definition:
#define RGB_MAKE(xR,xG,xB) ( ( (xG&0x1c)<<11 ) + ( (xG)>>5 ) + \
( ((xB)>>3) << 8 ) + \
( ((xR)>>3) << 3 ) )
it just works works let me know if it helped someone, - anyway it would be nice to find this correction in the next release - I have spent 2 hours to find out where the problem was.

yrt · 2009-11-27 07:14:30

Hi,

I'm sorry but I don't understand your computing.
I think the original way is good, and I guess your first shift puts the bit G4, G3 and G2 instead of G2, G1, G0 to the most significant bits.
May be the conversion would be better if the 3 colors had the same weight, and the format was G2G1G0B5B4B3B2B1R5R4R3R2R1G5G4G3 ?

mkoleda · 2009-11-27 17:29:21

ok,
let's say we got a variable GREEN as an unsigned char. thus 8 bits:
b7 b6 b5 b4 b3 b2 b1 b0
looking at the RGM_MAKE we always use the UPPER bits of every color composite. from the MSB to that bit determined by the colour resolution depth (5bits, 6bits, 5bits) - did I get this right?

so if you use (GREEN&0x07)<<13 - what is the result of this expression? b2 b1 b0 shifted 13bits left - do you agree on that?
so it's (b2 b1 b0)0 0000 0000 0000

if we further use (GREEN)>>5 - what is the result of this expression? I guess it is
0000 0(b7 b6 b5) - in other words - we loose lower 5 bits - right? so there are only bits b7 b6 b5, and b2 b1 b0 bits used in the RGB_MAKE. We have lost bits b4 and b3 (instead of loosing bits b1 and b0 of the GREEN variable). Am I missing a point here? cause even if I would be wrong with this explanation (that would be pretty embarassing), results that I get using it are better than with the original definition of RGB_MAKE.

I just don't get this - why do we loose two bits in the middle of the variable instead of loosing either the lower 2 bits or the upper 2 bits? it makes dimming the composite colour more complicated.

yrt · 2009-11-30 10:39:31

Hi,

In fact, the problem is a problem of version !
What version are you using ?
Because the original code (CircleOS v3.8) is :

/*RGB is 16-bit coded as G2G1G0B4 B3B2B1B0 R4R3R2R1 R0G5G4G3*/
#define RGB_MAKE(xR,xG,xB) ( ( (((xG)>>2)&0x07)<<13 ) + ( (((xG)>>2))>>3 ) + \
( ((xB)>>3) << 8 ) + \
( ((xR)>>3) << 3 ) )

And the computing is right.

mkoleda · 2009-12-03 07:27:55

Hi,

ok, this looks much better. this definition is the same as mine in fact, so I am going to upgrade to 3.8 right away. thank you very much!

martin

# 1 2007-10-30 16:14:58 the color codes

the color codes

# 2 2007-10-30 19:33:54 the color codes

Re: the color codes

# 3 2007-10-31 10:01:32 the color codes

Re: the color codes

# 4 2008-01-19 07:33:36 the color codes

Re: the color codes

# 5 2009-11-26 21:05:32 the color codes

Re: the color codes

# 6 2009-11-27 07:14:30 the color codes

Re: the color codes

# 7 2009-11-27 17:29:21 the color codes

Re: the color codes

# 8 2009-11-30 10:39:31 the color codes

Re: the color codes

# 9 2009-12-03 07:27:55 the color codes

Re: the color codes

Board footer