Strange. I can’t see why that would be. At the very least, you should be able to vary red or blue individually, while the other one is set to off (along with green off).
So are you saying that, for you, the blue LED just goes from on to off, instead of fading down, when the ARDUBOY logo scrolls down at the start of a sketch that uses begin() with the standard Arduboy library?
Instead of a macro, it would probably be better to add a new function to the library, like setRGBledCorrected(), which would do the mapping you propose and then call setRGBled(). A sketch that wanted the LEDs to work the same on all Arduboys would call setRGBledCorrected(). A sketch that wanted to have full control of a correctly installed LED, or map it themselves, and possibly save some code space, would call setRGBled(). Since for an incorrect LED, green can never be turned on, it would probably be best if setRGBledCorrect() only accepted values for red and blue (so maybe just call it setRBled()?).
We would still need a flag in EEPROM, so the routine would know how to properly map the values.
Read on for a technical explanation of why this is so:
To simplify things, I’ll mostly ignore the resistors in the circuit. The resistors just limit the current, to determine the maximum brightness possible, and prevent the LEDs from burning out.
The RGB LED contains an individual red, green and blue LED in a package that has 4 leads. An LED is a two leaded device. To get 3 LEDs (6 leads total) into a 4 lead package, one lead of each LED is tied to a single common lead in the package. This single lead provides power to all three LEDs. (Technically, this is known as a “common anode” RGB LED.) The other lead of each LED is connected to its own I/O pin (through a resistor), providing the capability to individually control each LED in software.
One thing to understand is that an LED will only work when voltage is applied to it in one direction. One lead (the anode) has to be positive and the other (the cathode) negative. If you reverse the voltage, it won’t light.
Another thing to understand is that the actual logic for the LEDs is reversed. The common lead is tied to a positive voltage, so the I/O pin must be set low to turn it on. The setRGBled() routine compliments the values passed to it, so this “reverse logic” is transparent to the user.
With the RGB LED package installed reversed, the green LED ends up being reversed across the power and its I/O pin. Being reversed, the green LED can never light.
Instead of being attached to power, the common lead is now attached to the green LEDs I/O pin, meaning the red and blue LEDs now get their power from green LEDs I/O pin. Because of the “reverse logic” described above, to turn off an LED the I/O pin is set high. So, when the green LED is off, the high on its I/O pin provides the power to the red and blue LEDs. Setting the green LEDs I/O pin low, to turn it on, provides no power to the red and blue LEDs, which is why they won’t light when green is on.
Now, if the intensity of the green LED is varied between full on and off, it varies the power being supplied to the red and blue LEDs, thus controlling their intensity. Because of the resistors in the circuit, there will be some interaction between the LEDs and, as observed, control may not be linear.