Yesterday I upgraded from 1.0 to 1.5.5. Since then my DCF77 clock http://blog.blinkenlight.net/experiments/dcf77/the-clock/ failed to lock to DCF77. As soon as I downgrade everything is fine again. What I noticed is that the compiled code differs significantly in size. I do not mind the size, however it seems that the upgrade disrupts my (critical) timing.
Has anyone a hint for me what exactly changed the compiler behaviour?
By now I tried different versions and found that the upgrade from 1.0 to 1.0.1 already causes my project to fail. The upgrade basically bloats the compiled code. It is larger AND slower. The code being slower makes it miss interrupts that it did not miss before.
Has anyone any idea why this happens?
These are the release notes : http://arduino.cc/en/Main/ReleaseNotes
The avr-gcc compiler is also being updated and further developed. I don’t know which version of the Arduino uses which version of the avr-gcc.
By now I had a very close look at the compiler output:
/home/udo/Desktop/arduino-1.0.1/hardware/tools/avr/bin/avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=101 -I/home/udo/Desktop/arduino-1.0.1/hardware/arduino/cores/arduino -I/home/udo/Desktop/arduino-1.0.1/hardware/arduino/variants/eightanaloginputs -I/home/udo/Desktop/arduino-1.0.1/libraries/dcf77 /tmp/build8292172423459455253.tmp/MB_Emulator.cpp -o /tmp/build8292172423459455253.tmp/MB_Emulator.cpp.o
<snip>
/home/udo/Desktop/arduino-1.0.1/hardware/tools/avr/bin/avr-gcc -Os -Wl,--gc-sections -mmcu=atmega328p -o /tmp/build8292172423459455253.tmp/MB_Emulator.cpp.elf /tmp/build8292172423459455253.tmp/MB_Emulator.cpp.o /tmp/build8292172423459455253.tmp/dcf77/dcf77.cpp.o /tmp/build8292172423459455253.tmp/core.a -L/tmp/build8292172423459455253.tmp -lm
/home/udo/Desktop/arduino-1.0.1/hardware/tools/avr/bin/avr-objcopy -O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0 /tmp/build8292172423459455253.tmp/MB_Emulator.cpp.elf /tmp/build8292172423459455253.tmp/MB_Emulator.cpp.eep
/home/udo/Desktop/arduino-1.0.1/hardware/tools/avr/bin/avr-objcopy -O ihex -R .eeprom /tmp/build8292172423459455253.tmp/MB_Emulator.cpp.elf /tmp/build8292172423459455253.tmp/MB_Emulator.cpp.hex
Binary sketch size: 19,400 bytes (of a 30,720 byte maximum)
avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=100 -I/usr/share/arduino/hardware/arduino/cores/arduino -I/usr/share/arduino/hardware/arduino/variants/eightanaloginputs -I/usr/share/arduino/libraries/dcf77 /tmp/build8021356485289965020.tmp/MB_Emulator.cpp -o/tmp/build8021356485289965020.tmp/MB_Emulator.cpp.o
<snip>
avr-gcc -Os -Wl,--gc-sections -mmcu=atmega328p -o /tmp/build8021356485289965020.tmp/MB_Emulator.cpp.elf /tmp/build8021356485289965020.tmp/MB_Emulator.cpp.o /tmp/build8021356485289965020.tmp/dcf77/dcf77.cpp.o /tmp/build8021356485289965020.tmp/core.a -L/tmp/build8021356485289965020.tmp -lm
avr-objcopy -O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0 /tmp/build8021356485289965020.tmp/MB_Emulator.cpp.elf /tmp/build8021356485289965020.tmp/MB_Emulator.cpp.eep
avr-objcopy -O ihex -R .eeprom /tmp/build8021356485289965020.tmp/MB_Emulator.cpp.elf /tmp/build8021356485289965020.tmp/MB_Emulator.cpp.hex
Binary sketch size: 18078 bytes (of a 30720 byte maximum)
So the most obvious difference is the compiler. I checked the version of the compilers:
avr-gcc: /usr/bin/avr-gcc /usr/bin/X11/avr-gcc
~$ nautilus /usr/bin/avr-gcc
~$ /home/udo/Desktop/arduino-1.0.2/hardware/tools/avr/bin/avr-g++ --version
avr-g++ (GCC) 4.3.2
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
~$ /usr/bin/avr-g++ --version
avr-g++ (GCC) 4.5.3
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
So the newer versions of Arduino come with an older compiler. This explains a lot. Is there any reason why Arduino uses 4.3.2 instead of 4.5.3?
I thinks there are some incompatibility problems between Arduino and avr-gcc. https://github.com/arduino/Arduino/issues/1208 Also the version 1.5.5r2 beta uses the older 4.3.2
I like the new optimizations for the new avr-gcc compiler, and I hope Arduino will soon use the newest avr-gcc compiler. Perhaps with an option to use the extra optimizations. Because the timing of the code will be changed a lot with some optimizations.
[quote author=Udo Klein link=topic=218014.msg1601539#msg1601539 date=1392953898] So the newer versions of Arduino come with an older compiler. This explains a lot. Is there any reason why Arduino uses 4.3.2 instead of 4.5.3? [/quote]
Which version of the Arduino IDE for Mac works with your DCF-77 Library? For me, with a Freaduino (which has a crystal instead of a resonator and thus should be precise enough), the scope-sketch works, but the the clock-sketch does not lock with the DCF-77 signal. It's the same with Arduino 1.0.0 and 1.0.5. This is what the versions.txt file says within the app container:
avarice: 2.8 avr-libc: 1.6.4 avrdude: 5.4-arduino binutils: 2.19 gcc-3: 3.4.6 gcc-4: 4.3.2 gdb: 6.8 libusb: 0.1.12 make: 3.81 simulavr: 0.1.2.5