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.
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?
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.
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.
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?
Frank Muenzner schrieb: > wie kann ich gcc zwingen bestimmte statements zu kompilieren bsbw die > nops? 1. GCC umschreiben oder 2. Inline Assembler, z.B
1 | #define NOP __asm ("nop")
|
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/*)
************************************************************************
*
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
1 | 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.)
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.