Pages: [1]   Go Down
Author Topic: LED Blink Program Weirdness  (Read 2627 times)
0 Members and 1 Guest are viewing this topic.
Offline Offline
Newbie
*
Karma: 0
Posts: 13
just learning the ropes.. err wires
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I was given a Arduino Duemilanove, which looks exactly like the board shown in "The Arduino Playground"
  http://arduino.cc/en/uploads/Main/ArduinoDuemilanove.jpg
right down to the "RESET-EN" trace, and the text between 'MADE IN ITALY' and pin13.  So I started to play just the board (not extra electronics or external power) connected to my Dell Laptop running Fedora 14, with the arduino 0022 software installed.

Now I tryed the 'LED Blink' sktech from the web site, but all I even got after the program was uploaded to the arduino was a solid unblinking LED!
  http://arduino.cc/en/Tutorial/Blink

However other example sketches (mostly serial communications) worked fine, including 'PhysicalPixel' where you send the arduino 'H' and 'L' characters to turn on and of the LED!  Just the LED blink sketch fails to do what it what it is supposed to do!   Playing with the delay() values would sometimes result in the LED flashing breifly then just turning off, but typically the LED would just be a steady on with no other action.

Then I tried a different 'Blink' the LED example from the 0022 adruino 'examples' sub menu.
IT WORKED!

The only difference between the two is that instead of using a integer value of 13 directly as on the web site, the working example used a variable to hold that integer value of 13.  They were functionally equivalent!

So after some playing with the code, this is what it came down to.

This failes  (solid on board LED after uploading)
Code:
/*
  Blink
  Turns on an LED on for one second, then off for one second, repeatedly.
 
  This example code is in the public domain.
 */

int L3 = 13;
void setup() {               
  // initialize the digital pin as an output.
  // Pin 13 has an LED connected on most Arduino boards:
  pinMode(13, OUTPUT);     
}

void loop() {
  digitalWrite(13, HIGH);   // set the LED on
  delay(1000);              // wait for a second
  digitalWrite(13, LOW);    // set the LED off
  delay(1000);              // wait for a second
}

But this works (change a '1' to a 'L' in setup() )
Code:
/*
  Blink
  Turns on an LED on for one second, then off for one second, repeatedly.
 
  This example code is in the public domain.
 */

int L3 = 13;
void setup() {               
  // initialize the digital pin as an output.
  // Pin 13 has an LED connected on most Arduino boards:
  pinMode(L3, OUTPUT);     
}

void loop() {
  digitalWrite(13, HIGH);   // set the LED on
  delay(1000);              // wait for a second
  digitalWrite(13, LOW);    // set the LED off
  delay(1000);              // wait for a second
}


In other words, if I do the setup of the pin using a variable it works, but fails if I use a number directly.
No change was made to loop(), just the use of the variable in setup()
In the compiled 'C program' this should make no difference to the call structure, only adding a 'retrieve variable contents' before the actual call to the pin setup library function. Both should be seting a integer value to the library function. The two programs should be functionally equivalent, but that is not what happens!

In fact this small difference is reflected in the upload code sizes...
Using '13' directly creates a code size of  1020 bytes
Using a variable, (any name, though I used L3 for the test for ease of editing) I get a code size of 1024.

The 4 extra bytes would be the machine code to 'retrieve value from memory'.  Note that the code size going from 1020 (fail) to 1024 (success) is very suggestive, though I have not tried to played with that fact.

ASIDE:I am not a novice in programming or electronics, just a novice with the arduino!
I was programming in Z80 CPU machine language (ZX81) in the 1980's after all!
 
I have no idea why this small change causes it to fail/work.  My only thoughts on this is that...
* I am hitting a bug either in compiled code
* or in the specific hardware I am using,
* or perhaps it is the upload code (code size less than 1Kbyte)
and  as a result of whatever it is, the arduino is crashing during setup, before it gets to loop().

It will be hard to figure out too as any change, such as adding "Serial.begin(9600);" to the setup() makes the sketch work again!



Does anyone have any suggestions as to why one sketch works and the other does not?  If you give me some instructions I am also willing to go to a deeper level and upload the compiled code, or even assembly language to see what is the real difference.

Another user on the forum tried both the stetches his arduino, though it wasn't the same model as mine, and he said they both work!

Would others with a Arduino Duemilanove (especially if you have one with the 'RESET-EN' trace on the board next to the USB input), please try and see if they can get similar results?
Logged

Left Coast, CA (USA)
Offline Offline
Brattain Member
*****
Karma: 361
Posts: 17301
Measurement changes behavior
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Well to add more confusion for you, both versions compile and run fine on my arduino mega1280 board.

Lefty

Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 13
just learning the ropes.. err wires
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

The problem may be related to the linux compiler problem described in
  http://arduino.cc/forum/index.php/topic,49900.0.html

It is also looked at in these topics, which also point back to the one above.
  http://arduino.cc/forum/index.php/topic,68456.0.html
  http://arduino.cc/forum/index.php/topic,51000.0.html
Logged

Pisa - Italy
Offline Offline
Jr. Member
**
Karma: 0
Posts: 60
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Do you solve?
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 13
just learning the ropes.. err wires
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

No.  The solution is some type of patching of avr compiler packages.  There is no word if the upstream providers known and/or have fixed the problem, which has now spread to Fedora 14 packages.

The work around is to create a initialised global variable that is actually used in setup() or loop().  Basically any form of added complexity, will generally avoid the problem.

It is not good but it explains the weirdness.


The best intermediate idea may be to update that 'blink' example on the primary web site, to use a global variable, such as the 'blink' example distributed with the arduino GUI v22 software.  That way other new users do not accidentally hit the problem in the first place!

Logged

GA
Offline Offline
Newbie
*
Karma: 0
Posts: 43
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

newbee234,

Thanks for posting this...  I was preparing a long post myself, but instead, I'll just summarize what I've seen with my setup.

I have Arduino 0022 running on Fedora 15 (2.6.40-4.fc15.i686), also on Ubuntu 11.04 (2.6.38-10), and finally on Windows Vista.

I have the same version of your Arduino Duemilanove, as well as three other boards (each a little different).

I have the exact same problem you originally described, on ALL my boards, when running Arduino 0022 on Fedora 15.  I have NO problems at all, on any of my boards, when running Ubuntu or Vista.

My preferred OS is Fedora, so it's a real shame that whatever the issue or bug is, manifests itself on Fedora.  With such a fundamental error, I feel that Arduino + Fedora is an unreliable combination.

I'll look at the links you provided above, but have you implemented a fix yet?
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 13
just learning the ropes.. err wires
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

The problem only exists when no global variable is defined or used.  At least that is what I determined from the other threads. Adding a fake non-zero global, and using or incrementing it, fixes the problem.

Blink is the only example that is simple enough to not actually use a global variable!
Just enabling serial communications, is also enough to create a global variable.

I agree that it is a shame that Fedora has this fault.

Debian has a patch in its packages, which is why your unbuntu linux works.   The upstream provider however has not fixed it, or if they have, that fix has not made it into the fedora package repository.

Logged

Argentina
Offline Offline
Newbie
*
Karma: 0
Posts: 1
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi guys, I've got the same problem, came from Linux mint 9 and arduino UNO worked fine there even when it's quite an old version of that distro, switched to Fedora 15 and got the exact same problem described above, yesterday I gave my arduino to a friend that's got Windows 7 and it worked fine, now that I've read your post I got the blinking example to work as expected.
It would be interesting to see which versions of the avr tools is ubuntu including in its packages and compare them with Fedora's.
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 5
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Yessir, this is exactly my problem also.  I have spent most of a day chasing my tail.  I was uploading the blink demo to a Duemilanove board and the led would just stay on.  And it was known good hardware because it was running the demo fine yesterday when I started all this (uploaded into it over a year ago when I was first playing with Arduinos on a different computer).  Adding a bogus global variable gets things blinking.  I am running Fedora 14 x86_64 and used "yum install arduino" to get the collection of packages I needed.  Then wasted a bunch of time getting the Sun/Oracle jdk set up and pulling my hair out.  Well I am a better man for it I guess, and I found this forum, and a search on blink led me here ..... This needs to go to Fedora bugzilla if the F15 packages do not yet have the fix.
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 5
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

The fedora updates repository for Fedora 15 has newer versions of avr-gcc and avr-gcc-c++
than are available for Fedora 14.  Namely 4.6.1-2 for Fedora 15 as compared to 4.5.3-1 for Fedora 14.
These showed up 9-1-2011 on our mirror.   Unfortunately I cannot test them on the machine
I am using for arduino development as it is a Fedora 14 machine and trying to install the
Fedora 15 packages there fails due to library dependencies.  The folks that reported this
problem for Fedora 15 ought to do a yum update and try again and let us know if this version
fixes this problem.

Fedora 16 is in alpha, so Fedora 14 will soon be end of life if it isn't already, so I don't hold
out much hope that this will find its way into Fedora 14 updates (and I guess I should get ready
to upgrade my home system, probably to 16).
Logged

Offline Offline
God Member
*****
Karma: 7
Posts: 647
"In this house, we obey the Laws of Thermodynamics" Homer J. Simpson
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I have tried both sketches on a Uno from Windows XP and they both run fine. It does seem very like a compiler problem, once I had a program that was affected by adding or removing a comment  smiley-sad

On the Uno the LED that blinks is marked "L". This LED also blinks during uploading. I noticed a couple of things in the original post;
Quote
adding "Serial.begin(9600);" to the setup() makes the sketch work again!

Quote
Using '13' directly creates a code size of  1020 bytes
Using a variable, (any name, though I used L3 for the test for ease of editing) I get a code size of 1024.

Is there any possibility this is in some way related to how the USB/Serial Port is used by different operating systems, perhaps some obscure timing problem?

A couple of things you might try to gain more clues;
  • Do you get the same issue with any other pin or is it only pin 13 (which is used in some way during upload)?
  • Have you tried declaring a constant (not a variable) and then using it instead of 13 in the function call?



Logged

Offline Offline
God Member
*****
Karma: 7
Posts: 647
"In this house, we obey the Laws of Thermodynamics" Homer J. Simpson
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Sorry a couple of other things;

  • What happens when you press reset
  • Does it make any difference if you don't power the card from the USB
Logged

Miramar Beach, Florida
Offline Offline
Faraday Member
**
Karma: 148
Posts: 6104
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Just a suggestion. Take a look at this thread:
http://arduino.cc/forum/index.php/topic,71182.0.html
Linux and avr-libc-1.7.0 has a pretty serious delay() bug. A fix is available at the above link if that is the problem.
Logged

Pages: [1]   Go Up
Jump to: