My experience is that equal MCd of red, green and blue do not add up to white.
Example 1: An old formula for color TVs - photometric output was said to be 59% from green, 30% from red, 11% from blue IIRC.
Example 2: sRGB, a "color space" that computer monitors are mostly largely assumed to be close to. I get 70% from green, 22% from red, 8% from blue, to achieve 6500 K white.
Example 3:
formatting link
With a red LED of dominant wavelength 625 nm and on the spectral locus,
a green one with chromaticity conforming to what Nichia publishes for the usual "G color rank" green ones with nominal dominant wavelength of 525 nm,
and a blue LED with chromaticity conforming to what Nichia publishes for most "W" color rank blue LEDs with dominant wavelength nominally 470 nm:
To achieve 6500 K white, photometric content is 27.9% from red, 62.5% from green, 9.6% from blue.
Percentage of photometric content from blue will be less if the blue LED is a "royal blue" one. If the white is to be something less bluish than 6500 K, then photometric content breakdown must decrease for blue and increase for red, and green can make a minor change in either direction. Green's photometric content from an RGB LED light source usually remains over half the total photometric content for color temperature at least from 2400 K to 12,000 K, and red's photometric contribution usually exceeds that from blue even to color temp. of 12,000 K.
RGB LED PIC controlled via RS232 from the PC The RGB color PIC program, the asm source, the hex file, and the Linux C sources for on the PC are now ready and available here under the Gnu Public License (GPL):
formatting link
The PIC is a 16F648A and can also be controlled via a normal terminal program.
19200 Bd, 8 data bits, 1 stop bit .
Color settings can be saved in EEPROM, so that at startup you get the selected color again. All you need to do is make a white balance once, by adjusting 2 resistors (use pots perhaps). The system uses 3 software PWM channels and the PIC can drive 3 small LEDs directly.
others have suggested LZW but things like LZW likes lots of ram and a small MCU doesn't usually have that.
static huffman doesn't though, and could probably work well.
on the other hand that table is poorly encoded.
you can reduce size by noting the conversion between multiple-word names and camelcase names, (you only need to store one form)
(removing the CamelCased version reduces it to 10691 bytes)
not all ascii characters are present also the numbers can be stored in binary.
this reduces it to 4139 sub-6bit characters (actually only 38 symbols including space (or shift) and and an end-marker) and 1467 octets of colour data,
if the chip allows you to read the ROM... do PICs allow that? It should all fit in a 4Kx12bit chip without too much work. (about 3048 words)
it works fine in dosemu under linux. (runs in a window under X) (dosemu provides some level of VGA emulation - enough to get the standard modes atleast)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.