next topic »

[on:]

Hi, I just set up a fedora 14 ix86 box with the arduino software(both the fedora supplied 0021 version and a downloaded 0022 version) and am noticing what I think is a bug.

when I download the blink sketch from the 0022 distribution the led comes on and stays on without blinking. the code for this example follows:

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
}

If I change the code to pass a variable to the pinMode function rather than the decimal literal 13, then the led blinks as expected.
here is the "working" code:

int ledPin = 13;

void setup() {               
  // initialize the digital pin as an output.
  // Pin 13 has an LED connected on most Arduino boards:
  pinMode(ledPin, 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
}


both of these programs work and blink the led as expected if compiled, and downloaded using arduino-0017 on my MacOS X machine.

Any ideas what might be going on here?

-Matt

[Reply #1 on:]

...
Any ideas what might be going on here?...

There is a version of the binary utilities package (the stuff with GNU assembler and linker that actually puts the compiled object code together) that doesn't work properly unless your code has some variables in RAM address space.  This isn't a very big shortcoming (in my opinion) for "real" programs, since I just about (almost) always have some global variables.  It is, however, very disappointing to someone new to Arduino (on a particular platform) who can't figure out why the simplest example doesn't work.

It's not an Arduino bug or even a gcc bug, it's a binutils bug.

Regards,

Dave

Footnote:
I first ran into this bug when compiling avr-gcc and the binutils and avr-libc stuff from source for my Centos 5 workstation.  Binutils 2.21 showed this problem, but binutils 2.20.1 works just fine.  (Using avr-gcc version 4.3.4)

If you are curious you can run the following from a command line (assuming the avr stuff is on your $PATH) and tell us what you get:

avr-as --version

[Reply #2 on:]

Looks like it's version 2.21:

% avr-as --version
GNU assembler (GNU Binutils) 2.21
Copyright 2010 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `avr'.

-Matt

[Reply #3 on:]

Looks like it's version 2.21...

That's what I thought.  It's a bug in binutils.  Bummer.

You have found one workaround: Make sure your sketch uses a global variable.  At least it fixes it for this simple sketch.

I am not aware of other bugs, but once you see one flaky thing like this, any time in the future that something doesn't work as expected, your mind will inevitably go in the direction that, "maybe something is wrong with the tools."  Too bad.

What version of avr-gcc is in your distribution?

Try running:

avr-gcc --version

Maybe you can compile from source and use binutils-2.20.1

For my Centos 5 workstations (same as RedHat EL 5) I followed the sequence detailed here: http://www.nongnu.org/avr-libc/user-manual/install_tools.html, using binutils version 2.20.1, avr-gcc version 4.3.4, and avr-libc version 1.6.8

Or you can live with what you have until and unless you discover some other bug for which there is no workaround.


Regards,

Dave

Footnote:
This version of compiler does not support the ATmega2560 without some patch(es).  Since I don't have an Arduino Mega2560 board, I have no way of testing, so I haven't tried.  I have used the above combination for '328p boards and '1280 boards that I have.  Note that if you do compile from source you should compile all three.  At least that was my experience.