I'm a newby, but I did figure this out. Hope it's helpful.
Please see comments beside "int fadeAmount":
/*
Fade
This example shows how to fade an LED on pin 9
using the analogWrite() function.
This example code is in the public domain.
*/
int led = 9; // the pin that the LED is attached to
int brightness = 0; // how bright the LED is
int fadeAmount = 17; // how many points to fade the LED by
// only works well with prime factors of 255
// (1,3,5,17)
// 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);
}
With numbers other than the prime factors of 255, the counter goes all the way back to 0 and starts over.
What I mean is that the circuit behaves as stated in the description: that the LED fades up from 0 to full power, then fades back down. If you don't use one of these numbers for fadeAmount, the circuit will fade up to full, then drop suddenly back to 0 over and over.
You allow a brightness of 0 to be written the next iteration of the loop even though you detected it was about to happen and flipped the sign on fadeamount. Any odd number should prevent this, not just primes. You just need to fix your bug and never let zero be written while you are increasing the PWM duty cycle.
This code is the Basic Fade example with the exception that I added <= and >= near the bottom instead of ==. All negative numbers do not work. With my change, any number other than a prime causes the LED to bink once at the top end before it dims.
Without my change, in other words:
// reverse the direction of the fading at the ends of the fade:
if (brightness == 0 || brightness == 255) {
fadeAmount = -fadeAmount ;
causes the LED to go back to 0 after every iteration and start over.
The example has the same "bug" that I described; the code will result in flashing when it gets to the extremes if the "fadeamount" doesn't result in it landing precisely on 255 and 0. Look at the code and work it out on paper if necessary. The code only reverses direction when the limits are met (or exceeded), it should also readjust "brightness" at that time to keep the very next digitalWrite from being outside the limits (wrapping). The example works because the chosen values land precisely on 255 and 0. Prime numbers really has nothing to do with it.