hex-File Größe bei Windows größer als bei Linux?

[Michael P. (mipl)]

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

[Peter II (Gast)]

Michael P. schrieb:
> Was kann man machen, um das festzustellen

erste einmal die Version vom GCC vergleichen.

[meckerziege (Gast)]

- Optionen beim Compiler? (zeig auch mal den Output bei Windows!)
- Welche Compilerversionen?
- Irgendwelche Libraries verwendet (floating point etc.?)

[Michael L. (michaelx)]

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.

[Peter II (Gast)]

Michael L. schrieb:
> hätte ich auf die
> Zeilenumbrüche getippt

im Binary?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Ein Hexfile ist reines ASCII...

[holger (Gast)]

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.

[Michael P. (mipl)]

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

[Peter II (Gast)]

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.

[Michael P. (mipl)]

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"

[Sheeva P. (sheevaplug)]

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.

[Michael P. (mipl)]

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

[Rufus Τ. F. (rufus)]

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 ...

[Jobst M. (jobstens-de)]

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

[Michael P. (mipl)]

Eine solche Aussage (xx % Full) habe ich bei AVR-Studio 4 nicht gesehen. 
Kann ich also nicht liefern.

Michael