First, love the whole Arduino concept. And I also did try various search terms and did read for some little time but didn't find, or missed the answer.
I have as you might have guessed a Leonardo board, it's my first. And it works except for the problem(?) I'll be getting to in a moment, well, right now actually:
I am under the impression that the loop function is supposed to loop indefinitely. However my Leonardo does not, it WILL run the sketch, the loop function will be called but it is as though it runs once, then exits.
I know the Leonardo is different... (which is ok) is this the cause of the loop issue? How is it resolved? Also anything Leonardo specific someone might want to share I am all eyes.
/*
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 = 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(500);
}
I am thinking as a work around of adding another function, my own loop function? Lock it in a while loop?
It's as if the program sorry, sketch, starts to run... BUT execution gets interrupted because of the serial re-enumeration? As it runs then I get a blink on the rx. tx, lines and execution stops?
Concur the code looks good. When you say execution stops, what do you mean? How do you know it stops?
With delay(500) it's going to take 25 seconds to fade up and another 25 seconds to fade down… are you sure it's not working? A shorter delay may be part of your solution.
perhof:
What kind of LED are you using on pin 9 and do you have a current limiting resistor in series with the LED?
On my board its the LED next to the "on" light.
Ok. Replaced 500 with 5.
And powered it from an external source and it blinks 13 times, and just stops. When plugged into the computer it does the same thing but the rx light blinks and then, it stops.
Posted by: billroy "With delay(500) it's going to take 25 seconds"
I thought delay() took its parameter in microseconds?
It does, and your code waits 500 ms for every time you increase or decrease your LED level with 5.
That means it will take 25 seconds (50 * 500ms) to go from 0 to 255 and another 25 secs to go back to 0.
The comment in your code says: wait for 30 milliseconds to see the dimming effect which would have been a better choice.
Posted by: perhof "Try running the same sketch while on batteries (without USB) if you can."
A 5 volts phone charger shouldn't hurt it if powered the board from the usb port right?
Should be safe. How well it would work depends on how stable the voltage is.
Epoch_Void:
On my board its the LED next to the "on" light.
That would be the LED on pin 13 - not pin 9.
You probably see the LED flashing when the bootloader starts and then nothing.
That was it. I had switched from the blink example to the fade: blink uses 13, fade uses 9. So on non-leonardo boards pin 9, might have been ok?
It's working now though that I switched from pin 9 to 13.
Uno and older boards also have the LED on pin 13 and no LED on pin 9 but because pin 13 is not a PWM pin on those boards the example is made for an external LED connected to one of the PWM pins.
only works if fadeAmount is 1 or 5 or 255. It won't work if fadeAmount is any other value, as your using == .
Mark
PS brightness and fadeAmount should be unsigned byte and not int. It would also help if you check that brightness is in range befor you do the digitalWrite.
holmes4:
While you have the code working there is STILL a BUG in it. This line
if (brightness == 0 || brightness == 255) {
fadeAmount = -fadeAmount ;
only works if fadeAmount is 1 or 5 or 255. It won't work if fadeAmount is any other value, as your using == .
Mark
PS brightness and fadeAmount should be unsigned byte and not int. It would also help if you check that brightness is in range befor you do the digitalWrite.
Mark
I had "blink" on the brain there for a sec, and you're right but, its from the example code - sketch, base. They probably only meant it to be, such as it is.
So I don't think it is an error per se. More like unoptimized.
How could brightness not be in range? Something external to the code? Not as bad idea as a rule though, in any case.
How could brightness not be in range? Something external to the code? Not as bad idea as a rule though, in any case.
Suppose you decide that increasing steps of 1 is too slow. So, you change it to 4. brightness gets set to 0, 4, 8, 12, ,,, 240, 244, 248, 252, 256, etc., because brightness never exactly hits 255.
I don't see what "it works as written" has to do with making the code better. If you change the fade amount, so that is is incrementing by that amount does not result in 255 being assigned to brightness, the fade amount will never go negative, resulting in fading down. It requires changing only two characters to handle the possibility.
Defensive programming is always better then scratching your head going "WTF?" when an equality doesn't occur.