This evening I've also created another 2 functions for controlling an RGB LED. The first function holds an LED at a certain RGB value for a given time period, using PWM, nothing special there. The second function accepts 2 RGB values, then fades between them over a given time period, with a smooth gradient. One can now program a lighting sequence using the simple colour "holds" and "fades".

My problem with the fade code is that I could only seem to make it work when using floating point arithmetic. Attempting to mix up integer math made the PWM go all wrong. So the Arduino is performing a LOT more operations that it really should be doing. This does not affect the timing of the LED colour-changes (to my eyes at least) though I havn't done any rigorous sort of test on that:

Code:

//i/o pin declarations
int rpin = 9;
int gpin = 10;
int bpin = 11;

//function prototypes
void solid(int r, int g, int b, int t);
void fade(int r1, int g1, int b1, int r2, int g2, int b2, int t);

void setup()		    
{
//empty
}

void loop()			  
{
  //colour sequence instructions
  
  //Example sequence one: Rainbow fade over 15 seconds:
  fade(255,0,0,0,255,0,5000); //fade from red to green over 5 seconds
  fade(0,255,0,0,0,255,5000); //fade from green to blue over 5 seconds
  fade(0,0,255,255,0,0,5000); //fade from blue to red over 5 seconds
}

//function holds RGB values for time t milliseconds
void solid(int r, int g, int b, int t)
{

  //map values - arduino is sinking current, not sourcing it
  r = map(r, 0, 255, 255, 0);
  g = map(g, 0, 255, 255, 0);
  b = map(b, 0, 255, 255, 0);

  //output
  analogWrite(rpin,r);
  analogWrite(gpin,g);
  analogWrite(bpin,b);
  
  //hold at this colour set for t ms
  delay(t);

}

//function fades between two RGB values over fade time period t
//maximum value of fade time = 30 seconds before gradient values
//get too small for floating point math to work? replace floats
//with doubles to remedy this?
void fade(int r1, int g1, int b1, int r2, int g2, int b2, int t)
{

  float r_float1, g_float1, b_float1;
  float r_float2, g_float2, b_float2;
  float grad_r, grad_g, grad_b;
  float output_r, output_g, output_b;
  
  //declare integer RGB values as float values
  r_float1 = (float) r1;
  g_float1 = (float) g1;
  b_float1 = (float) b1;
  r_float2 = (float) r2;
  g_float2 = (float) g2;
  b_float2 = (float) b2;
  
  //calculate rates of change of R, G, and B values
  grad_r = (r_float2-r_float1)/t;
  grad_g = (g_float2-g_float1)/t;
  grad_b = (b_float2-b_float1)/t;
  
  //loop round, incrementing time value "i"
  for ( float i=0; i<=t; i++ )
  {
    
    output_r = r_float1 + grad_r*i;
    output_g = g_float1 + grad_g*i;
    output_b = b_float1 + grad_b*i;
    
    //map values - arduino is sinking current, not sourcing it
    output_r = map (output_r,0,255,255,0);
    output_g = map (output_g,0,255,255,0);
    output_b = map (output_b,0,255,255,0);
    
    //output
    analogWrite(rpin, (int)output_r);
    analogWrite(gpin, (int)output_g);
    analogWrite(bpin, (int)output_b);
    
    //hold at this colour set for 1ms
    delay(1);
    
  }
}
 

akgraphics, could you explain this piece of code?

Code:

//map values - arduino is sinking current, not sourcing it
r = map(r, 0, 255, 255, 0);
g = map(g, 0, 255, 255, 0);
b = map(b, 0, 255, 255, 0); 

I'm learning a lot of programming techniques at the moment and it appears you're reversing/inverting the output by mapping it? Is that just to do with how you have your LED's connected to the outputs?

Thanks in advance, Easty.

PS Sorry thebias I can't answer your question (yet) but I'm planning something similar by the sounds of it.

Thanks Theboii, I had had a read of the reference material and seemed to understand it!

I was wondering why akgraphics had used it in his code as in my brief experiments with PWM'ing LEDs last night I didn't have to perform that change. I guess it's circuit specific though...

Cheers, Easty.

Understood 100%!

Interesting about the sink/source comparision... I think I'd better redesign my circuit!

Thanks, Easty.

Here is a non-float, hue only version also.  What is the application?  It sounds like it could be interesting.
Code:

void setup(){
  Serial.begin(9600);
}

void loop(){
//colors out of phase by 341  (1023/3)
  Serial.println("V,R,G,B");
  for(int v = 0; v < 1024; v++){ //analogRead surrogate
    Serial.print(v);
    Serial.print(",");
    Serial.print(colVal(v+341),DEC);    //red
    Serial.print(",");
    Serial.print(colVal(v),DEC);	  //green
    Serial.print(",");
    Serial.println(colVal(v+682),DEC);  //blue
  }
  while(true);
}

//based on green hue function, add phase adjustment for red or blue value
byte colVal(int val){
  int v = val % 1024;
  if(v<=170)
    return (v * 3) / 2;
  if(v<=512)
    return 255;
  if(v<=682)
 return 255 - (((v%171) * 3) / 2);
  return 0;
}
 

Edit:  Just noticed the part about non-floats messing up the pwm functions, that doesn't sound right.

Not sure if this is at all helpful for you too easty but my theory so far is to use a combo of the code you guys have put up here with 3 of these circuits http://www.arduino.cc/playground/uploads/Learning/multiple_leds2.jpg in order to drive the each of 3 colours for each LED.  To start with I would just like to get 3 RGB leds up and running.  I think this should work bearing in mind that I want them to all do the same thing at the same time. If anyone sees any gaping holes in my theory please point it out!

Cheers

xandar wrote on 20.07.2008 at 07:11:45:


Yes if there is no voltage difference then there is no current flow.

Quote:


You can sink 60mA at 25C and get down to a voltage of 1.5v.

That means sinking current you will not get the full 5v across the load but 5 - 1.5 = 3.5v

Sinking 40mA gets you down to under 1V on the output where as 20mA gets the output voltage down to 0.5v