In the Fade sketch from the example sketches. is this piece of code:
/*
Fade
This example shows how to fade an LED on pin 9
using the analogWrite() function.
The analogWrite() function uses PWM, so if
you want to change the pin you're using, be
sure to use another PWM capable pin. On most
Arduino, the PWM pins are identified with
a "~" sign, like ~3, ~5, ~6, ~9, ~10 and ~11.
This example code is in the public domain.
*/
int led = 9; // the PWM pin the LED is attached to
int brightness = 0; // how bright the LED is
int fadeAmount = 5; // how many points to fade the LED by
// the setup routine runs once when you press reset:
void setup() {
// declare pin 9 to be an output:
pinMode(led, OUTPUT);
}
// the loop routine runs over and over again forever:
void loop() {
// set the brightness of pin 9:
analogWrite(led, brightness);
// change the brightness for next time through the loop:
brightness = brightness + fadeAmount;
// reverse the direction of the fading at the ends of the fade:
if (brightness == 0 || brightness == 255) {
fadeAmount = -fadeAmount ;
}
// wait for 30 milliseconds to see the dimming effect
delay(30);
}
Just before the reverse direction, if you coerce the value of brightness to be within 0 to 255, then it won't matter what value is used for fadeAmount, the direction change will not cause the brightness go out of range. The result is smooth fading at the up/down transitions.
The constraint approach seems too obfuscated to me. I'd rather use the KISS principle. As a bonus, it's easy to have different fade in and fade out rates...
//...
// set the brightness of pin 9:
analogWrite(led, brightness);
// change the brightness for next time through the loop:
brightness = brightness + fadeAmount;
// reverse the direction of the fading at the ends of the fade:
if (brightness > 255)
{
brightness = 255;
fadeAmount = -13 ;
}
else if (brightness < 0)
{
brightness = 0;
fadeAmount = 7 ;
}
//...
Just to mention that KISS approach has the exact same constraints, in fact, expanding the nested ternary gives the same code. However, I agree using the if/else format easier to follow, easier to add more options.
Sometimes I use the ternary if that all that's needed and its commented appropriately.
Now all that's left is an algorithm to adjust for the human eye's response to brightness...
dlloyd:
Just to mention that KISS approach has the exact same constraints, in fact, expanding the nested ternary gives the same code. However, I agree using the if/else format easier to follow, easier to add more options.
Sometimes I use the ternary if that all that's needed and its commented appropriately.
Now all that's left is an algorithm to adjust for the human eye's response to brightness...
Ooh, actually before we go there, it's also best to use the smallest step possible to get the smoothest brightness steps. Namely 1. The 30 millisecond delay is what should change, in order to alter the rate in this simple implementation. So forget what I wrote.
An implementation that takes into account the gamma or whatever, should also only modify the delays.
But I think there might be a problem with calling analogWrite too frequently. I recall from way back, that the PWM pulses can't stay synchronous with the pulses that were running from the previous call. This means that if it's called too often a beat frequency might be created. I'll have to investigate.
But it goes without saying that an example sketch is supposed to be simple. It should definitely not trot out anything that is unreliable.
