dafid: In fact you're right. I looked at wiring.c a couple of days ago and for some reason I remembered it using delayMicroseconds(), but I just checked again and the implementation of delay() is identical in my wiring.c as what you posted above. It does indeed use micros() - my mistake!
stimmer: I'm running 64 bit Arch Linux and Arduino 0021. The IDE installation on Arch is a bit of a mess since it bundles its own patched avrdude and librxtx with it instead of using the system wide ones. Also, the installation requires removing 64 bit gcc and gcc-libs and installing 64 and 32 bit compatible versions of these packages (gcc-multilib), which is pretty hackish IMHO. In addition, the package is not available from official "repository" but it is user contributed, so it is very likely to be an installation problem. I have removed everything and reinstalled again but the results are the same.
I would like to report that I have the same problem using the delay() function on arch 32 bit and avr-gcc 4.5.2
I have the problem on 3 different boards, the arduino nano, arduino duelmilanove 168 and the 328.
On the 168 the LED blinks very fast and on the 328 and the nano the led is just on all the time.
I've duplicated the problem on three different computers running arch. On one of them I downgraded the avr-gcc to 4.3.5 and the problem was still there.
The delay() works ok when I compile my code and upload it using Ubuntu 10.04 and avr-gcc 4.3.5.
I'm baffled by this one. I tried to compile GCC 4.5.2 on Ubuntu but just got too many errors. I also tried to install Arch Linux but Virtualbox was not cooperating, so gave up on that too.
Are either of you able to disassemble the object file and see what the compiler is doing to the delay function?
I wonder if the compiler is misconfigured or picking up a delay function from some other header somewhere... Does Arch set any environment variables that might interfere with GCC, like CFLAGS, CXXFLAGS, C_INCLUDE_PATH, CPLUS_INCLUDE_PATH and LIBRARY_PATH ?
I'll dive into the issue in more detail as soon as I get some free time. I just updated Arch linux and saw it pulled a new gcc in, so I will recompile the sketches and see if anything changes. If I can't figure anything out, I'll get in touch with the Arch linux arduino package maintainer and let him know about this issue, since it seems to be Arch specific.
igor86:
None of those environment variables seem to be set:
None of those variables should be set normally; the makefile sets them, and they basically are only set while make is running (i.e. during the build process).
Well, that disassembly looks correct, it's slightly different to mine but not significantly.
Could you disassemble it again and post the entire disassembly? I am wondering if something is clobbering r1 (which should usually be zero) or if an ISR is clobbering something else, the only way to find out is to look through the whole lot
OK... I finally managed to install Arch linux on Virtualbox and I think I'm getting to the bottom of this. It appears that the Arch compiler sometimes generates code that writes to addresses before the start of memory. RAM starts at address 0x200 on the mega, but the Blink code has the delay() timer variables located at 0x100-0x10b. This only seems to happen when the code contains no initialised global variables (.data segment in asm-speak) - the linker is told that the data segment starts at 0x200, but if there's nothing to go in it it generates an incorrect start address for the uninitialised global variables (.bss segment). Since the timer variables are uninitialised globals (or globals initialised to zero) they end up at an illegal address.
Here's my blink code that worked, with an initialised global. Could you test this and tell me if it is at the correct speed?
char dummyvariablecuzmaintainerborkedthecompiler = 123; // force something into the .data segment with non-zero initializer
/*
Blink
Turns on an LED on for one second, then off for one second, repeatedly.
This example code is in the public domain.
*/
void setup() {
dummyvariablecuzmaintainerborkedthecompiler++; // stops the linker from removing the global variable
// 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
}
Any code that uses the Serial class won't be affected by this, as Serial contains an initialised global.
Wow, well the Blink sketch with global var inserted functions correctly for me! Compiles and uploads fine and the led blinks on and off at the correct rate on the Uno.
Will be interesting to know how this tests out for Igor's Mega 1280 as well as Uno board and Aleks' various boards on 32 bit Arch...
As an arduino newbie I'm not sure where to go next with this but it seems it is an Arch specific problem?
Seriously the Arch maintainers are doing a great job, from what I can tell there's still issues with the Arduino IDE distribution containing 32bit rxtx but there is rxtx replacement in AUR (Arch User Repos)
But this problem sounds like it will be with gcc-avr, gcc-binutils or something?
I strongly agree with Igor's statement that:
Open source hardware should have a good IDE implementation for open source software, no?
and the kind of help Stimmer, Dafid et al are providing on this forum will no doubt be invaluable for getting Arduino stable on Arch's rolling releases insofar as that's possible ]
I'm following with interest and I guess this will filter over to the Arch forums or bug reports as it develops...?
Yes, it sounds like an Arch specific problem at the moment. Maintaining a cross compiler is probably one of the harder jobs, they are a pain to compile and bug reports are hard to replicate.
A potential solution has been posted in another thread by dsh1. This involves downgrading to GCC 4.3.5 and applying Debian patches:
stimmer:
Yes, it sounds like an Arch specific problem at the moment. Maintaining a cross compiler is probably one of the harder jobs, they are a pain to compile and bug reports are hard to replicate.
A potential solution has been posted in another thread by dsh1. This involves downgrading to GCC 4.3.5 and applying Debian patches:
However the 'blink' example that comes with the arduino v22 software, initializes a LEDPin global variable and that, as has been said fixes the problem.
I am a newbe to using the arduino, and the fact that it fails like this with a very basic example has been a worry for me. Any idea when the real problem will be fixed?