Hallo, da ich die Hardware für das Projekt noch nicht gebaut habe wollte ich fragen, ob mir jemand sagen kann, ob es normal ist, dass identischer C-Sourcecode bei Windows (AVR Studio 4) ein hex-file mit 32.663 Bytes erzeugt, während dies unter Linux lediglich 21.949 Bytes werden? Der Output von make unter Linux zeigt lediglich eine warnung: make avr-gcc -mmcu=atmega168 -Wall -gdwarf-2 -Os -std=gnu99 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT clock.o -MF dep/clock.o.d -c ../clock.c avr-gcc -mmcu=atmega168 -Wall -gdwarf-2 -Os -std=gnu99 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT Heliostep_15.o -MF dep/Heliostep_15.o.d -c ../Heliostep_15.c avr-gcc -mmcu=atmega168 -Wall -gdwarf-2 -Os -std=gnu99 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT lcd-routines.o -MF dep/lcd-routines.o.d -c ../lcd-routines.c avr-gcc -mmcu=atmega168 -Wl,-Map=Heliostep_15.map clock.o Heliostep_15.o lcd-routines.o -o Heliostep_15.elf /usr/bin/avr-ld: warning: -z relro ignored. avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature Heliostep_15.elf Heliostep_15.hex avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 --no-change-warnings -O ihex Heliostep_15.elf Heliostep_15.eep || exit 0 avr-objdump -h -S Heliostep_15.elf > Heliostep_15.lss AVR Memory Usage ---------------- Device: atmega168 Program: 7820 bytes (47.7% Full) (.text + .data + .bootloader) Data: 111 bytes (10.8% Full) (.data + .bss + .noinit) Das hex-file wird ja erzeugt, so dass ich denke, dass alles i. O. ist. Oder trügt der Schein? Was kann man machen, um das festzustellen ohne die Hardware zu bemühen? Danke für Eure Tips. Gruß Michael
Gast
#4639429
Michael P. schrieb: > Was kann man machen, um das festzustellen erste einmal die Version vom GCC vergleichen.
Gast
#4639436
- Optionen beim Compiler? (zeig auch mal den Output bei Windows!) - Welche Compilerversionen? - Irgendwelche Libraries verwendet (floating point etc.?)
Wenn der Unterschied nicht so groß wäre, hätte ich auf die Zeilenumbrüche getippt (Linux 0xa, bei Windows 0xd + 0xa), aber so schließe ich mich meinen Vorpostern an.
Gast
#4639471
Michael L. schrieb: > hätte ich auf die > Zeilenumbrüche getippt im Binary?
Ein Hexfile ist reines ASCII...
Gast
#4639475
Alleine die Compiler Option -Os kann schon solche Unterschiede bewirken. Ansonsten kann man bei HEX Dateien nicht unbedingt anhand ihrer Größe sagen dass der erzeugte Code größer oder kleiner ist. Es gibt da Möglichkeiten unbenutzte Zellen nicht in die HEX Datei zu übernehmen. Da müsste man entweder einen HEX zu BIN Konverter bemühen oder den Inhalt der HEX Dateien selber mal analysieren wenn man es kann.
Hallo und danke für die zahlreichen Anregungen. Die avr-gcc Version unter Linux ist 4.8.3-1.1 Bei Windows weiß ich nicht, wie ich die herausbekommen kann. In dem Verzeichnis, in dem sich avr-gcc.exe befindet (erstellt am 19.01.2010) befindet sich auch avr-gcc4.3.3.exe. Vielleicht hilft das. Und hier noch der Output unter Windows: rm -rf clock.o Heliostep_15.o lcd-routines.o Heliostep_15.elf dep/* Heliostep_15.hex Heliostep_15.eep Heliostep_15.lss Heliostep_15.map Build succeeded with 0 Warnings... avr-gcc -mmcu=atmega168 -Wall -gdwarf-2 -std=gnu99 -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT clock.o -MF dep/clock.o.d -c ../clock.c avr-gcc -mmcu=atmega168 -Wall -gdwarf-2 -std=gnu99 -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT Heliostep_15.o -MF dep/Heliostep_15.o.d -c ../Heliostep_15.c In file included from ../Heliostep_15.c:78: ../lcd-routines.h:54:1: warning: "F_CPU" redefined <command-line>: warning: this is the location of the previous definition avr-gcc -mmcu=atmega168 -Wall -gdwarf-2 -std=gnu99 -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT lcd-routines.o -MF dep/lcd-routines.o.d -c ../lcd-routines.c In file included from ../lcd-routines.c:16: ../lcd-routines.h:54:1: warning: "F_CPU" redefined <command-line>: warning: this is the location of the previous definition avr-gcc -mmcu=atmega168 -Wl,-Map=Heliostep_15.map clock.o Heliostep_15.o lcd-routines.o -o Heliostep_15.elf avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature Heliostep_15.elf Heliostep_15.hex avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 --no-change-warnings -O ihex Heliostep_15.elf Heliostep_15.eep || exit 0 avr-objdump -h -S Heliostep_15.elf > Heliostep_15.lss Build succeeded with 4 Warnings... Prinzipiell höre ich aber raus, dass es Differenzen geben kann. Michael
Gast
#4639514
Michael P. schrieb: > Bei Windows weiß ich nicht, wie ich die herausbekommen kann. gcc --Version von 4.3 auf 4.8 ist schon ein etwas größere Sprung - da kann es durchaus solche unterschiede geben.
Librabries fehlen noch: #include <avr/io.h> //AVR Register und Konstantendefinitionen #include <avr/interrupt.h> //AVR Interrupt Vektoren #include <stdlib.h> #include <inttypes.h> #include <math.h> #include "clock.h" #include "lcd-routines.h"
Michael P. schrieb: > Hallo, > > da ich die Hardware für das Projekt noch nicht gebaut habe wollte ich > fragen, ob mir jemand sagen kann, ob es normal ist, dass identischer > C-Sourcecode bei Windows (AVR Studio 4) ein hex-file mit 32.663 Bytes > erzeugt, während dies unter Linux lediglich 21.949 Bytes werden? Liegt das möglicherweise an den Zeilenumbrüchen? UNIX und Linux benutzen da nur ein Linefeed ("\n"), während Windows die Kombination aus Carriage-Return und Linefeed ("\r\n") verwendet.
Bin kein Windows-Mensch daher funktionierte gcc --version in CMD erstmal nicht. Gut, hab's noch hinbekommen: C:\Users\mp>avr-gcc --version avr-gcc (WinAVR 20100110) 4.3.3 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. Also tatsächlich 4.3.3 Ich gehe davon aus, dass die Lösung damit klar ist. Danke für die Infos. Michael
Sheeva P. schrieb: > Liegt das möglicherweise an den Zeilenumbrüchen? Läge es an den Zeilenumbrüchen, würde pro Zeile im Hex-File ein Byte dazukommen. Damit hätte die Datei bei 11 kByte Zuwachs also 11000 Zeilen. Das wiederum würde bedeuten, daß nur ein Nutzbyte pro Zeile vorhanden sein kann (die kleinere Datei ist ja nur ca 21 kByte groß). Manchmal hilft so eine simple Betrachtung, um herauszufinden, ob etwas wahrscheinlich ist ...
Beim intel hex Format ist die Länge der Datenzeilen nicht festgelegt, sondern flexibel. Und wenn bei Windows-GCC z.B. 8 Byte pro Zeile übertragen werden, dann erzeugt das mehr Overhead, als wenn 16 Bytes in einer Zeile stehen. Könnnnnnnte auch eine Möglichkeit sein. Die Länge eines HEX-Files sagt nichts über die Länge des Inhalts aus. Michael P. schrieb: > Program: 7820 bytes (47.7% Full) Was sagt denn der Windows-Compiler? Gruß Jobst
Eine solche Aussage (xx % Full) habe ich bei AVR-Studio 4 nicht gesehen. Kann ich also nicht liefern. Michael