mikrocontroller.net

Forum: Compiler & IDEs kompilerdifferenzen zwischen gcc 4.3.3 /4.4.3 oder DAUfehler -- Ich weiß nicht mehr weiter.


Autor: Frank Muenzner (frank_muenzner)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo ich habe folgendes Problem, vielleicht kann mir jemand helfen.


Ich habe hier ein sehr schönes Projekt zum Thema FFT und ATXmega 
gefunden. (von Christian Lauer)

Ich habe das gleiche Board und dachte mir - super - der code sollte so 
kompilierbar sein - AVRstudio projektfile war dabei - der code wird 
compiliert - alles super.

Allerdings funktioniert er nur leider nicht.

Vergleiche beim debuggen brachten unterschiede zwischen meinem hexfile 
und dem originalfile zu tage.
Jetzt weiß ich nur nicht woran das liegt.

Das .lss File zeigt auch unterschiede - doch ich weiß nicht mehr warum 
das teil nicht läuft. Kann mir jemand einen tip geben der sich mit gccc 
auskennt?

Ich habe auch noch andere Demobeispiele zu dem Board - läuft nur leider 
nichts....

der einzige mir bewußte unterschied ist die version vom gcc.


Ich habe die letzte Nacht vergeblich gesucht und bin heute sehr 
zerknirscht ins Bett gegangen - ohne das ich den code zum Laufen 
gebracht habe und da fragte ich mich ob ich nen DAU bin.

Vielleicht kann mich jemand erleuchten.

im angehängten File ist die Originalversion und die auf meinen Rechner 
compilierte version enthalten einschließlich .map und .lss


es wäre super wenn sich jemand das anschauen könnte und nen Rat hätte.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank Muenzner schrieb:

> Ich habe auch noch andere Demobeispiele zu dem Board - läuft nur leider
> nichts....

Wie? läuft nur nichts?

Da musst du zu arbeiten anfangen.
Solange einfache Demobeispiele, womöglich direkt vom Herstellerm, nicht 
funktionieren, hat es keinen Sinn, wenn du dich an der Königsklasse 
versuchst. Wenn du die Demos nicht zum laufen bringst, stimmt irgendwas 
in deiner Konfiguration nicht. Kannst du denn ein Programm an den µC 
übertragen?

Autor: Frank Muenzner (frank_muenzner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nun, was das laufen anbelangt, wenn ich die Beispiele für dieses Board 
kompiliere, gibt es zum Beispiel Probleme bei der Anzeige auf dem OLED.
Problem bedeutet es hört bei der Ausgabe der ersten Zeile auf.

Die Herstellerbeispiele..... da bin ich mir eben nicht so sicher, da 
Beispielsweise im OLED originalzustand ausgegeben wird: 
SSD1306_OLED_Test und im enthaltenen Code steht SSD1306_OLED_DEMO


Das bedeutet der Code ist nicht identisch......

ich habe das Originalprogramm auch im Disassembler angeschaut und es 
gibt unterschiede selbst zwischen der im ordner enthaltenen kompilierten 
Variante und meiner kompilierten Variante.
Da die Einstellungen mittels Projectfile vorgegeben sind vermute ich 
Unterschiede im gcc seit diesen Versionen.


Ich kann ein Programm übertragen allerdings nicht wie vom hersteller 
angegeben über AVRUBD sondern mittels AVRDRAGON direkt.
Ok, es war mir nicht so wichtig - doch

Ich habe Differenzen bei der OLED Ansteuerung vermutet aber nichts 
entdeckt.

dann schaute ich mir die beiden lss an - machte einen Vergleich im 
Notepad++ und sah das es noch mehr unterschiede gab.
Nur woher diese kommen weiß ich nicht - aber mit gcc bin ich wie gesagt 
unerfahren.
In der Vergangenheit habe ich beruflich gelegentlich mit IAR und KEIL 
gearbeitet.
Aber beispielprogramme mit soviel aufwand nicht zum laufen zu 
bekommen........ist sehr ärgerlich.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Solange du nicht exakt die gleiche Compilerversion/libc-Version wie das 
Original hast, ist es nicht ungewöhnlich, dass sich die HEX-Files 
unterscheiden.
Compiler entwickeln sich weiter, interne Verfahren zur Optimierung 
werden umgestellt oder verbessert, Bugs gefixt. Das alles kann zu 
Unterschieden führen.

Das alleine bedeutet daher noch gar nichts.
Du suchst an den falschen Stellen.

Autor: Frank Muenzner (frank_muenzner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann sein das ich an den falschen stellen suche - doch wenn ich wüßte wo 
ich suchen muß - dann wäre ich nicht hier.


Fehlersuche:
1. die Funktion des Boards ist sichergestellt (weil das enthaltene 
Demoprogramm läuft.
2. Programmieren funktioniert
3. Debuggen funktioniert
4. Schreiben auf OLED funktioniert bei mir nicht sauber.

Democode - egal ob vom Boardhersteller bzw. fremdcode der auf diesem 
board getestet wird läuft nicht.

Wenn das board den SSD1306 enthält dann verstehe ich nicht warum die 
Initialiesierungssequenz so ist. adafruit verwendet die Initialiesierung 
welche dem herstellerdatenblatt entspricht.
Aber vielleicht wird auch nur ein "kompatibles Derivat verwendet.

Da der Fehler beim ausgeben von Strings und grafiken auftritt könnte es 
auch mit kopieroperationen, wegoptimierten nops oder dem initialisieren 
des OLEDS zusammenhängen.


Wenn ich es wüßte, dann wäre ich schlauer - aber ich werde das Teil mal 
wieder aufbauen und mal sehen ob er die nops welche zum delay dienen 
wegoptimert hat.


gerade nachgeschaut..... der hat die nops tatsächlich wegoptimiert - 
allerdings wenn ich nichts falsch versteh dann schon im originalcode.... 
mal sehen.
wie kann ich gcc zwingen bestimmte statements zu kompilieren bsbw die 
nops?

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank Muenzner schrieb:

> wie kann ich gcc zwingen bestimmte statements zu kompilieren bsbw die
> nops?

1. GCC umschreiben oder
2. Inline Assembler, z.B
#define NOP __asm ("nop") 

Autor: Frank Muenzner (frank_muenzner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
aktuell:

#define NOP()    asm("nop")
#define Longnop() 
{NOP();NOP();NOP();NOP();NOP();NOP();NOP();NOP();NOP();}



Longnop wird laut lss zu einem nop => wegoptimiert


meinst du das _asm funktioniert?
werde es gleich mal testen....

also die vorgängerversion habe ich nicht getestet - allerdings stand 
hier im .lss auch ein nop, beim debuggen im disassembly fenster wurden 
es dann aber soviele wie beabsichtigt.

aber mir ist aufgefallen das er bei den OLED- routinen zurückspringt auf 
Adresse 0 - frage mich gerade ob das gestern auch war.

wie wird bei den ATXMEGA die stackgröße festgelegt?

Anbei das Makefile - vielleicht geht da ja die stackgröße hervor?

geht bei gcc mit sicherheit auch - ich weiß rfm....

kann trotzdem mal jemand draufschauen und mir sagen wie ich die 
optimierung rausnehme?
######################################################################## 
#######
# Makefile for the project scope
######################################################################## 
#######

## General Flags
PROJECT = scope
MCU = atxmega64a3
TARGET = scope.elf
CC = avr-gcc

CPP = avr-g++

## Options common to compile, link and assembly rules
COMMON = -mmcu=$(MCU)

## Compile options common for all C compilation units.
CFLAGS = $(COMMON)
CFLAGS += -Wall -gdwarf-2 -std=gnu99     -DF_CPU=32000000UL -O2 
-funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums
CFLAGS += -MD -MP -MT $(*F).o -MF dep/$(@F).d

## Assembly specific flags
ASMFLAGS = $(COMMON)
ASMFLAGS += $(CFLAGS)
ASMFLAGS += -x assembler-with-cpp -Wa,-gdwarf2

## Linker flags
LDFLAGS = $(COMMON)
LDFLAGS +=  -Wl,-Map=scope.map


## Intel Hex file production flags
HEX_FLASH_FLAGS = -R .eeprom -R .fuse -R .lock -R .signature

HEX_EEPROM_FLAGS = -j .eeprom
HEX_EEPROM_FLAGS += --set-section-flags=.eeprom="alloc,load"
HEX_EEPROM_FLAGS += --change-section-lma .eeprom=0 --no-change-warnings


## Objects that must be built in order to link
OBJECTS = scope.o adc.o clock.o display.o keys.o plotter.o fft.o

## Objects explicitly added by the user
LINKONLYOBJECTS =

## Build
all: $(TARGET) scope.hex scope.eep scope.lss size

## Compile
scope.o: ../scope.c
  $(CC) $(INCLUDES) $(CFLAGS) -c  $<

adc.o: ../adc.c
  $(CC) $(INCLUDES) $(CFLAGS) -c  $<

clock.o: ../clock.c
  $(CC) $(INCLUDES) $(CFLAGS) -c  $<

display.o: ../display.c
  $(CC) $(INCLUDES) $(CFLAGS) -c  $<

keys.o: ../keys.c
  $(CC) $(INCLUDES) $(CFLAGS) -c  $<

plotter.o: ../plotter.c
  $(CC) $(INCLUDES) $(CFLAGS) -c  $<

fft.o: ../fft.s
  $(CC) $(INCLUDES) $(ASMFLAGS) -c  $<

##Link
$(TARGET): $(OBJECTS)
   $(CC) $(LDFLAGS) $(OBJECTS) $(LINKONLYOBJECTS) $(LIBDIRS) $(LIBS) -o 
$(TARGET)

%.hex: $(TARGET)
  avr-objcopy -O ihex $(HEX_FLASH_FLAGS)  $< $@

%.eep: $(TARGET)
  -avr-objcopy $(HEX_EEPROM_FLAGS) -O ihex $< $@ || exit 0

%.lss: $(TARGET)
  avr-objdump -h -S $< > $@

size: ${TARGET}
  @echo
  @avr-size -C --mcu=${MCU} ${TARGET}

## Clean target
.PHONY: clean
clean:
  -rm -rf $(OBJECTS) scope.elf dep/* scope.hex scope.eep scope.lss 
scope.map


## Other dependencies
-include $(shell mkdir dep 2>NUL) $(wildcard dep/*)


************************************************************************ 
*

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank Muenzner schrieb:
> aktuell:
>
> #define NOP()    asm("nop")
> #define Longnop()
> {NOP();NOP();NOP();NOP();NOP();NOP();NOP();NOP();NOP();}
>
> Longnop wird laut lss zu einem nop => wegoptimiert

Ist es ein NOP oder werden die anderen nur nicht angezeigt? Ein NOP 
auf AVR ist 0x0000 und ohne disasemble zeroes (-z bei objdump) werden 
nur die dersten Nullen angezeigt.

> meinst du das _asm funktioniert?

Nein. Entweder __asm oder asm. gcc behandelt asm ohne Operanden wie asm 
volatile, also wird nix weggeworfen.

> also die vorgängerversion habe ich nicht getestet

Vielleicht verrätst du mal, welche Version von avr-gcc du überhaupt 
verwendest: die 4.3.3 oder die 4.3.4 als eigener Build oder als WinAVR 
oder den ATmel-Branch und welche Patches sind da drinne etc. Die 
ausfunft gibt dir
avr-gcc -v

> aber mir ist aufgefallen das er bei den OLED- routinen zurückspringt auf
> Adresse 0 - frage mich gerade ob das gestern auch war.

Keine Ahnung wie Degugging + Watchdog zusammenpassen. Geht das? Ist der 
WDT aktiv? Sind die Fuses gleich gesetzt?

> wie wird bei den ATXMEGA die stackgröße festgelegt?

Welche Stackgröße? Der Stack wächst/schrumpft dynamisch mit dem 
Programm, den Daten die darauf liegen, der Call-Tiefe, der 
Interrupt-Tiefe, etc.

> kann trotzdem mal jemand draufschauen und mir sagen wie ich die
> optimierung rausnehme?

-O0 (oder nix) anstatt -O2

Ich würd dir eher raten dich mit dem Autor in Verbindung zu setzen oder 
es wenigstens zu versuchen. Zudem tut sich die Option -W (aktiviert 
Warnungen) nicht schlecht, und wenn du denkst es liegt an der 
avr-gcc-Version, beschaff dir eben die passende Version. Ältere 
WInAVR-Versionen sind ja weiterhin verfügbar. WinAVR-20100110 beinhaltet 
zB avr-gcc 4.3.3, allerdings mit einigen Patches (ATXmega-Unterstützung 
in den Tool, etc.)

Autor: Frank Muenzner (frank_muenzner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey - es war einfacherals man denkt......


der nichtvorhandene bootloader wars.....
Mit Bootlader und Anwendung flashen unter dem bootlader gibts kein 
problem.

Jetzt wüßte ich nur zu gerne wie ich das ohne Bootlader hinbekomme.....
(so das ich ihn drinlassen kann und trotzdem alles läuft..

werde mir das mal genauer anschauen - allerdings erst in einer Woche - 
da sich sonst meine Freundin zu sehr freut wenn der atxmega wichtiger 
ist...

So ich danke euch für eure guten Tips und unterstützung - werde 
sicherlich nochmal nachfragen, der eigene code muß ja auch noch 
geschrieben werden...

also dann guts Nächtle und schöne Woche

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.