Hallo,
ich brauche dringend eure Hilfe.
Mein erstes winAVR-Projekt ist ein Assemblerprogramm zur Ansteuerung
eines 8x24 Text-LCD an einem myAVR-ATmega8-Board mit myUSB MK2
winAVR Version 20090313
Ich verwende Assebler weil ich in C noch keine Erfolge erzielen konnte
:-))
Mein Programm läuft auch schon weitgehend, habe es bis jetzt immer mit
dem Demoprogramm von myAVR in den Controller reingebügelt. Das gefällt
mir aber nicht (nach zehn Minuten kommt die erste Meldung von wegen
"Demoprogramm...bezahlen...bla").
Ich habe nun schon Stunden damit verbracht (länger als für mein
ASS-Programm!) die Zusammenhänge im Makefile zu verstehen und habe auch
einige Forenbeträge hierzu gelesen, die mich aber nicht weiterbringen.
Beim "make all" kommt folgende Meldung:
> "make.exe" all
-------- begin --------
avr-gcc (WinAVR 20090313) 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.
Assembling: disp_m8_v3_1.S
avr-gcc -c -mmcu=atmega8 -I. -x assembler-with-cpp -DF_CPU=3686400
-Wa,-adhlns=./disp_m8_v3_1.lst,-gstabs,--listing-cont-lines=100
disp_m8_v3_1.S -o disp_m8_v3_1.o
Linking: disp_m8_v3_1.elf
avr-gcc -mmcu=atmega8 -I. -MMD -MP -MF .dep/disp_m8_v3_1.elf.d
disp_m8_v3_1.o --output disp_m8_v3_1.elf
-Wl,-Map=disp_m8_v3_1.map,--cref -lm
c:/programme/winavr/bin/../lib/gcc/avr/4.3.2/../../../../avr/lib/avr4/cr
tm8.o:(.init9+0x0): undefined reference to `main'
make.exe: *** [disp_m8_v3_1.elf] Error 1
> Process Exit Code: 2> Time Taken: 00:00
Wofür brauche ich denn diese .elf-Datei überhaupt? Die .hex-Datei wird
übrigens nicht erzeugt. Ich weis nicht wo ich ansetzen soll.
Danke vorab für jede Hilfe.
Die hex wird aus der elf erzeugt.
In deinem Makefile erzeugt du das Projekt wie ein C-Projekt, und ein
C-Programm hat eben ne main-Funktion...
Das Problem ist, weil du gegen die crtm8.o links, da steht der
Startup-Code drinne mit initialisierung von .data, .bss den Constructors
und danach eben den Spring zu main.
Es gibt ne gcc-Option -nostartfiles (oder so ähnlich, möglicherweise
auch ne ld-Option), falls das ist, was du suchst...
Johann
Nenn den Beginn deines Hauptprogramms doch einfach main, dann ist der
linker glücklich, und baut dir auch ein .hex-File. Als Vorlage kannst du
am besten ein einfaches WinAVR-C-Beispiel kompilieren, und dir im
.lss-File den erzeugten Assemblercode ansehen.
Oliver
Oh, ich habe ja schon Antworten.
Vielen Dank.
@Johann:
Was du da schreibst ist für mich wie Chinesisch.
Sie Frage, die in dem letzen Satz mitschwingt, kann ich leider nicht
beantworten :-))
Was ist eine gcc-Option?
@Oliver:
Die Hauptroutine war in dem Grundgerüst ursprünglich mit "main" benannt.
Dabei ist aber das gleiche Problem aufgetreten. Ich habe die
Hauptroutine dann umbenannt, weil ich dachte der Compiler hällt es für
einen Verweis auf ein c-Programm, dass ich nicht verwende. Wie gesagt:
Das Problem war vorher das gleiche, gerade auch nochmal getestet:
gleicher Fehler.
Was kann ich da machen?
Peter_Silie schrieb:
> Die Hauptroutine war in dem Grundgerüst ursprünglich mit "main" benannt.> Dabei ist aber das gleiche Problem aufgetreten.
Dann vermutlich das .global vergessen.
> Ich habe nun schon Stunden damit verbracht (länger als für mein> ASS-Programm!) die Zusammenhänge im Makefile
Mein Rat
Für Assembler nimm das AVR-Studio
Für C nimm ebenfalls das AVR-Sudio
Stefan Ernst schrieb:
> ...> Dann vermutlich das .global vergessen.
Danke für den Hinweis
Stimmt. Ich wusste ja nicht, dass ich es brauche :)
Wohin und wie müsste es denn?
Karl heinz Buchegger schrieb:
>> Mein Rat>> Für Assembler nimm das AVR-Studio> Für C nimm ebenfalls das AVR-Studio
Danke für den Tipp.
Das AVR-Studio habe ich auch schon installiert, bin aber von dem
Funktionumfang fast erschlagen worden =:-|
Damit wollte ich mich vertraut machen wenn ich in C-Programmierung
einsteige und den geplanten ATxmega verwende.
Ich kann ja noch gar nicht beurteilen welches Programm für meine Zwecke
besser geeignet ist.
AVR-Studio scheint mir auch eine Testversion zu sein.
winAVR ist etwas übersichtlicher, hier stecken aber die Stolperfallen im
Makefile
Habe schon einige Forenbeiträge gelesen, am Ende ist es wohl
Geschmackssache.
Werde das aber gleich mal ausprobieren.
Peter_Silie schrieb:
> @Johann:> Was du da schreibst ist für mich wie Chinesisch.
Naja, es ist das, was du in deinem Makefile machst...
Peter Silie schrieb:
> Karl heinz Buchegger schrieb:>>>> Mein Rat>>>> Für Assembler nimm das AVR-Studio>> Für C nimm ebenfalls das AVR-Studio>> Danke für den Tipp.> Das AVR-Studio habe ich auch schon installiert, bin aber von dem> Funktionumfang fast erschlagen worden =:-|
Jepp, ist nicht jedermanns Sache. Ich mag's auch nicht.
Zunächst solltest du dich mal für die Sprache entscheiden, also C,
Atmel-Assembler oder GNU-Assembler. Letztere beiden sind nicht
identisch. Während Atmel-ASM besser im AStudio unterstützt ist, kannst
du letzteren gut innerhalb von C-Projekten verwenden und C von Assembler
aus verwenden und umgekehrt.
> winAVR ist etwas übersichtlicher, hier stecken aber die Stolperfallen im> Makefile
Die Frage ist, warum die ein Makefile, das offenbar für ein C-Projekt
gedacht ist, für ein reines ASM-Projekt hernimmst. C-Programme haben
bestimmte (nicht viele) Konventionen, zB daß es eine main() gibt und daß
globale Variablen initialisiert werden etc. In ASM ist das nicht der
Fall.
Es ist nicht unbedingt Zeitverschwendung, sich mit make bzw. Makefiles
auseinanderzuseten. Automatisch erzeugte Makefiles sind schnell erzeugt,
aber leicht verständlich und nervensparend sind sie nicht unbedingt.
Trifft mehr oder weniger aber für alle Makefiles zu ;-)
Johann
Johann L. schrieb:
> Zunächst solltest du dich mal für die Sprache entscheiden, also C,> Atmel-Assembler oder GNU-Assembler. Letztere beiden sind nicht> identisch. Während Atmel-ASM besser im AStudio unterstützt ist, kannst> du letzteren gut innerhalb von C-Projekten verwenden und C von Assembler> aus verwenden und umgekehrt.
Das habe ich auch schon festgestellt :-(
> Die Frage ist, warum die ein Makefile, das offenbar für ein C-Projekt> gedacht ist, für ein reines ASM-Projekt hernimmst. C-Programme haben> bestimmte (nicht viele) Konventionen, zB daß es eine main() gibt und daß> globale Variablen initialisiert werden etc. In ASM ist das nicht der> Fall.
Ich habe das makefile über das von "MFile" mitgebrachte Template
erzeugt.
Keine Ahnung wie ich das für ASM umwurschteln soll, da ich nicht weis
welche Einträge zwingend sind (und wofür), habe ich es so gelassen.
> Es ist nicht unbedingt Zeitverschwendung, sich mit make bzw. Makefiles> auseinanderzuseten. Automatisch erzeugte Makefiles sind schnell erzeugt,> aber leicht verständlich und nervensparend sind sie nicht unbedingt.> Trifft mehr oder weniger aber für alle Makefiles zu ;-)
Würde mich schon gerne damit befassen, finde aber keinen Einstieg.
Da bräuchte ich wohl etwas Hilfe. Kannst Du mir evtl. sagen wie ich das
Makefile anpassen muss? Die Einträge für den C-compiler habe ich wohl
schon gesehen. Kann ich die einfach löschen? Was ist dann mit diesem
"Linker"??
Werde heute Abend nochmal reinschauen
Vielen Dank für die Hilfe :-)
Andreas
Ludger Manten schrieb:
> Schau mal hier:>> Beitrag "Minimalprogramm WINAVR Assembler (native)"
Damit ergibt sich das gleiche Problem, weil keine main darin ist. Oder
man muss eben von Hand seine Makefiles machen -- mach ich überigens
auch, weil mir mfile zu kompliziert ist.
Ein Minimalbeispiel könnte wie im Anhang aussehen, wobei ganz minimal
ist es nicht. Es definiert eine ISR nun initialisiert globale Daten.
Geschrieben ist es für einen ATmega48/88/168.
Übersetzen kann man zB mit
1
avr-gcc -mmcu=atmegsa88 minimal.S -o minimal.elf
Es wird dann automatisch ne Vektor-Tabell aufgebaut und .data
initialisiert (IRQs aktivieren geht natürlich simpler per SEI:
Danke für die freundliche Hilfestellung, aber leider produziert das
Miniprogramm auch Fehlermeldungen...
Ich bin jetzt mal dem Wink gefolgt, es mit AVR-Studio zu versuchen.
Dazu habe ich mein bisheriges Programm geladen und angepasst.
Die simulation läuft scheinbar auch, ich habe nur noch nicht
herausgefunden wie man Portzustände simuliert, damit das Programm auch
was zu schaffen hat.
Zumindest bekomme ich beim "build"-Prozess keine Fehlermeldungen :-))
Peter Silie schrieb:
> Danke für die freundliche Hilfestellung, aber leider produziert das> Miniprogramm auch Fehlermeldungen...
"Es gibt nen Fehler" ist die beste Fehlerbeschreibung überhaupt. Absolut
nutzlos, à la "nachts ist kälter als draussen"... Bingo.
Ich hatte doch die Architekturen als Kommentar ins makefile geschrieben.
Fuer Deinen Mega8 must du statt -mavr3 (fuer meinen 103er) -mavr4
eintragen.
Danach kann ich es zumindest hier fuer einen Mega8 fehlerfrei umsetzen.
Ludger Manten schrieb:
> Ich hatte doch die Architekturen als Kommentar ins makefile geschrieben.> Fuer Deinen Mega8 must du statt -mavr3 (fuer meinen 103er) -mavr4> eintragen.
Doch wohl -mmcu=avr4?
Oder besser den µC direkt angeben.
Johann L. schrieb:
> ...> Doch wohl -mmcu=avr4?> Oder besser den µC direkt angeben.
Bitte nicht falsch verstehen. Aber weil mir das alles spanisch vorkommt
und ich nicht einmal beurteilen kann, ob es sich hier (oder da) um einen
Tippfehler handelt oder ob ich es nur nicht verstehe, habe ich mich
entschieden das Problem zu vertagen.
Ich werde wohl doch erstmal AVR-Studio arbeiten. Bin gestern schon ein
Stück weiter gekommen. Compilieren, Brennen und Debugging funktionieren
hier und das reicht mir eigentlich
Deswegen habe ich das Problem bewusst nicht weiter ausgeführt, um das
Thema nicht weiter zu strapazieren. Es gibt ja unzählige Beiträge zu
diesem Stichwort. Wenn ich mal Muße habe, lese ich mich mal durch. Ich
habe ungefähr verstanden woran es liegen könnte, habe aber jetzt nicht
die Zeit mich damit zu befassen. Ich will ja nur meinen Controller
programmieren lernen.
Vielen Dank für die Interstützung.
