In my
last article, I demonstrated use of a potentiometer to control the hue of an RGB LED. In the HSV color space, the hue is one of three parameters controling the color. The other two are saturation and value. With a single control, there isn't a way to vary the other two parameters to give us a greater color range. In this article, I show one technique to control any of the three color variables.
Designing the input
But first, a short design discussion. In order to change what the potentiometer does, we need some method to change its mode of operation. I toyed with several ideas. My preferred method was three buttons: one button puts it in hue change mode, the second button puts it in saturation change mode and finally, the third button puts it in value change mode. The user would press a button and twist the potentiometer, setting that button's associated value. I like this because there is a one-to-one mapping between the buttons and the mode. It makes it easy for the user to understand and use. The problem: I only have two buttons.
My next idea was no button pressed changes hue, one button pressed changes saturation and the other button pressed changes the value. However, as I thought this through, I realized this would not give the user a nice flow between modes since every time one of the buttons was released, the hue mode would be entered, setting it to whatever value the potentiometer was in for the end of the last mode. This would cause the colors to jump around as modes changed and the un-pressed mode, hue, would have to be changed last. This clearly would not work very well.
After further thought, I hit upon the idea of using one button to cycle through the three modes with each button press and using the other button to enter that mode (or in other words, activate the potentiometer). Sort of like one button controls a menu and the other selects and deselects that menu option. To implement this, two additional LEDs are needed to indicate the mode and a third LED to indicate whether the potentiometer is enabled or not. This allows switching between modes without changing the output of the LED until the mode is selected. When the mode is exited, the LED would not change color as it would have in the previous scenario.
I implemented this design. However, after building it, I didn't like it since a binary readout is used to indicate the mode. I considered this sub-optimal from a usability standpoint. How many people can read binary numbers? In addition to the usability issue, it required three LEDs in addition to the switches, increasing the parts count and clutter on the breadboard. It worked but just seemed pretty clunky.
As I thought about it some more, I realized I could use the buttons directly in a binary pattern to select the mode and simply use a short delay before entering the mode. In other words, press and hold one button to change hue. Press and hold the other button to change saturation. Press and hold both buttons to change the value. I like this. It will reduce the parts count and eliminate a level of abstraction in the user interface; the buttons will directly control the mode. This is what I'll present below.
Hardware changes
Starting with the last circuit with in the previous article, I added two switches, two resistors and some jumpers. If you look at the schematic, pins 12 and 13 are connected to ground through a resistor when the switch is open. This means these two pins are normally in the LOW state when
digitalRead is called with their pin numbers. When the button is closed, they are connected to the 5V side and become HIGH. The resistor puts a load on the circuit when the button is closed. If the resistor is removed, a direct short between ground and power exists when the button closes; not a good thing to do.
That's it. Pretty simple circuit changes.
Click the image for a larger view or
here for a schematic.
Software changes
The software changes are a bit more involved. First, the simple part, I added two declarations for the pins. The next change is a semi-advanced technique, but first a bit of analysis.
There are two buttons. For each button, the software needs to time how long the user has pressed it and, when they have held it down long enough, switch into active mode. To do this, each button requires a timer and a memory of the last button state. The code is the same for both, but the memory to track their status needs to be separate.
To facilitate this type of design, where there are two sections of memory with the same functions working on it, I used something called a class. Put simply, a class associates data with code. To create a class, start with the
class keyword followed by the name of the class. This is the name you as a programmer decide to call it. Since this class contains the state information for a mode switch, I called the class
ModeSwitchState.
Next, I defined the state information tracked for each switch. This includes the pin the switch is connected to, a timer to track when the last change was made to the switch's state and the switch's last value (i.e. was it pressed or not). These three things are what are called private variables, as indicated by the
private keyword. This means nothing outside of functions defined in the class can access their values. The big, technical term for this is
data encapsulation. All that means is it's harder to accidentally change the wrong thing because the only things that can get to the memory is this one class.
After I defined the private memory, I created two functions that any code can use. The first is what's called the constructor. This simply means it's the function that is called when a new variable of this type is created. In this case, the constructor takes a parameter to indicate the Arduino pin the rest of the functions will use. Since the pin variable is private, this is the only way to set its value. The idea is you create a variable of this class type for each button to be controlled. The constructor also sets initial values for the other variables and calls pinMode for the pin it reads.
Finally, I wrote a function to read the current value of the pin and, if it's different from the last value, reset the timer and the last value read variables. It then returns true if the button is pressed and the difference between the timer and the current time is greater than 500 ms. Otherwise it will return false.
That's it for the definition of this class. Next, I created two variables of this class type, called
modeSwitch1 and
modeSwitch2. The constructor is called with the values of the pin assignment previously defined.
And that's it for the advanced stuff. All the other changes are in the loop function.
First the loop gets the current mode state of each switch. Remember, since this is calling the function on the class, all the timer code is neatly tucked away out of sight from the main processing loop. All we have to do now is worry about getting the current value as defined by the
readModeSwitch function. That's done by the first two lines.
Next I check to see if either of the switches are currently active. If so, then the potentiometer is read. Following this, either hue, saturation or value is changed to the pot's value based on which combination of switches are pressed. The case where both switches are pressed needs to be checked first, followed by the test for a single switch. If neither of these conditions are met, then the other switch must be pressed and its associated value changed.
Finally, after all this, the RGB color is computed and the LED is set to that color.
If neither switch is pressed, then nothing happens, the loop exits and immediately begins again.
Here's the final code.
int ledPins[] = { 11, 9, 10 };
int analogPin = 0;
int modeBit0pin = 12;
int modeBit1pin = 13;
int hueValue = 0;
double satValue = 1.0;
double lumValue = 1.0;
class ModeSwitchState
{
private:
int pin;
long timer;
boolean lastValue;
public:
ModeSwitchState(int switchPin)
: pin(switchPin), timer(0), lastValue(false)
{
pinMode(pin, OUTPUT);
}
boolean readModeSwitch()
{
boolean curValue = digitalRead(pin) == HIGH;
if (curValue != lastValue)
{
lastValue = curValue;
timer = millis();
}
return curValue && ((millis() - timer) > 500);
}
};
ModeSwitchState modeSwitch1(modeBit0pin), modeSwitch2(modeBit1pin);
void setup()
{
pinMode(analogPin, INPUT);
for(int i = 0; i < 3; i++)
pinMode(ledPins[i], OUTPUT);
}
void loop()
{
boolean mode1enabled = modeSwitch1.readModeSwitch();
boolean mode2enabled = modeSwitch2.readModeSwitch();
if (mode1enabled || mode2enabled)
{
int analogValue = analogRead(analogPin);
if (mode1enabled && mode2enabled)
hueValue = map(analogValue, 0, 1024, 0, 360);
else if (mode1enabled)
satValue = analogValue / 1024.0;
else
lumValue = analogValue / 1024.0;
byte* colors = hsvToRgb(hueValue, satValue, lumValue);
setColor(ledPins, colors);
}
}
void setColor(int* led, const byte* color)
{
for(int i = 0; i < 3; i++)
analogWrite(led[i], 255-color[i]);
}
byte rgb[3];
byte* hsvToRgb(int h, double s, double v)
{
// Make sure our arguments stay in-range
h = max(0, min(360, h));
s = max(0, min(1.0, s));
v = max(0, min(1.0, v));
if(s == 0)
{
// Achromatic (grey)
rgb[0] = rgb[1] = rgb[2] = round(v * 255);
return rgb;
}
double hs = h / 60.0; // sector 0 to 5
int i = floor(hs);
double f = hs - i; // factorial part of h
double p = v * (1 - s);
double q = v * (1 - s * f);
double t = v * (1 - s * (1 - f));
double r, g, b;
switch(i)
{
case 0:
r = v;
g = t;
b = p;
break;
case 1:
r = q;
g = v;
b = p;
break;
case 2:
r = p;
g = v;
b = t;
break;
case 3:
r = p;
g = q;
b = v;
break;
case 4:
r = t;
g = p;
b = v;
break;
default: // case 5:
r = v;
g = p;
b = q;
}
rgb[0] = round(r * 255.0);
rgb[1] = round(g * 255.0);
rgb[2] = round(b * 255.0);
return rgb;
}
Conclusion and downloads
That's about all I'm going to do with the RGB LED for now. The source code for this and the past two articles can be downloaded here:
In the next article I will talk about the joys and sorrows of building a simple LCD kit to use with the Arduino.
Hi. I'm Harley and I'm a software developer. I'm also a lot of other things, but the focus of this site is about software development and this aspect of who I am. 
