Hi, ich programmiere mit dem AVR Studio (4.13) und WinAVR 20070122 und würde gerne Funktionen aus der Proycon AVRlib verwenden. Aber ich habe es noch nicht geschafft das die drei Produkte zusammenarbeiten. Nach Möglichkeit möchte ich die Makefiles vom AVR Studio generieren lassen und keine externen verwenden. Was kann ich da tun?
Hat keiner einen Vorschlag? Mir würde es ja schon helfen wenn die AVRlib überhaupt erstmal mit der aktuellen Version von WinAVR zusammenarbeitet. Wenn ich die Beispiele compiliere kommen jede Menge Fehlermeldungen. Nichtmal basictest.c krieg ich compilierte (vom PN2 aus). Hab die Fehlermeldungen mal angehängt. Ist die Proycon Lib so verbaut das man die mit dem GCC4.1 nicht mehr verwenden kann oder mache ich was falsch?
> avr-gcc basiciotest.o -Wl,-Map=basiciotest.map,--cref -mmcu=atmega163 -o
basiciotest.elf
Soweit ich das überblicke, fehlt dem Programm (*.elf) der C-Startupcode
(Vektoren, DATA+BSS Sektionen,...) und die C-Library. Das Programm
besteht im Moment nur aus dem Objektfile vom basiciotest. Es ist
natürlich, dass sich avr-objcopy daran verschluckt.
Wie sieht es aus, wenn du zuerst versuchst die Proycon AVRlib an sich zu
übersetzen, um die benötigte C-Library und den Startup-Code fürs
Zusammenlinken mit deinem Beispiel zu erhalten?
Gibt es ein eigenes Makefile für die Erstellung der Proycon AVRlib?
Wenn du die Library übersetzt hast, musst du anschliessend das Makefile
für dein Beispiel so abändern, dass die frisch erzeugte Library mit
eingebunden wird. Du kannst dich dabei an den Makefiles von Beispielcode
orientieren, die die avr-libc einbinden.
Nein, ein Makefile für die gesamte Lib hab ich nicht gefunden. Außerdem würde es doch keinen Sinn ergeben alles zu compilieren. Dann hab ich doch sämtliche Libs spezifisch für einen bestimmten AVR compiliert, oder? Außerdem wird bei dem basiciotest nicht wirklich Gebrauch von der Lib gemacht. Hab das Beispiel mal gepackt und angehängt. Die Datei avrproj_make ist eigentlich im Library Verzeichnis AVRlib\make abgelegt. Die Umgebungsvariable $(AVRLIB) ist gesetzt. Die Lib macht schon komische Sachen
Was ich nicht verstehe sind diese ganzen "dependecies" in dem Makefile, mal abgesehen davon das die meisten bei dem Beispiel eh überflüssig sind.
1 | ###### dependecies, add any dependencies you need here ################### |
2 | # Dependencies tell the compiler which files in your code depend on which |
3 | # other files. When you change a piece of code, the dependencies allow |
4 | # the compiler to intelligently figure out which files are affected and |
5 | # need to be recompiled. You should only list the dependencies of *.o |
6 | # files. For example: uart.o is the compiled output of uart.c and uart.h |
7 | # and therefore, uart.o "depends" on uart.c and uart.h. But the code in |
8 | # uart.c also uses information from global.h, so that file should be listed |
9 | # in the dependecies too. That way, if you alter global.h, uart.o will be |
10 | # recompiled to take into account the changes. |
11 | |
12 | buffer.o : buffer.c buffer.h |
13 | uart.o : uart.c uart.h global.h |
14 | uart2.o : uart2.c uart2.h global.h |
15 | rprintf.o : rprintf.c rprintf.h |
16 | a2d.o : a2d.c a2d.h |
17 | timer.o : timer.c timer.h global.h |
18 | pulse.o : pulse.c pulse.h timer.h global.h |
19 | lcd.o : lcd.c lcd.h global.h |
20 | i2c.o : i2c.c i2c.h global.h |
21 | spi.o : spi.c spi.h global.h |
22 | swpwm.o : swpwm.c swpwm.h global.h |
23 | servo.o : servo.c servo.h global.h |
24 | swuart.o : swuart.c swuart.h global.h |
25 | tsip.o : tsip.c tsip.h global.h |
26 | nmea.o : nmea.c nmea.h global.h |
27 | vt100.o : vt100.c vt100.h global.h |
28 | gps.o : gps.c gps.h global.h |
29 | $(TRG).o : $(TRG).c global.h |
Null Problemo. Dein Beispiel funktioniert. Schau mal nach, die ganze ELF, HEX, COF, MAP, LST Bande ist vorhanden. Nur das EEP drückt sich. Und das ist auch der Unterschied zwischen WinAVR 20060125 und WinAVR 20070122. avr-objcopy aus dem alten WinAVR meldet keinen Fehler, wenn keine EEPROM Daten da sind, aber die neue tut es. Weil aber der Fehler vom neuen avr-objcopy kommt, unterbricht make die Abarbeitung des makefile und der letzte Schritt - die Anzeige des Code und Speicherverbrauchs durch avr-size - fällt aus. Das ist aber nicht schlimm, sondern nur ein Schönheitsfehler. Du kannst ja das avr-size von Hand aufrufen (würde ich machen)...
1 | avr-size basiciotest.elf |
...oder das avrproj_make anpassen (würde ich nicht machen). Die anderen Warnungen sind pillepalle und vernachlässigbar. Die ganzen "dependecies" sind Vorabeinstellungen, falls du die Funktionen aus der Library verwendest. Angenommen du verwendest die Timer-Funktionen, dann änderst du makefile an dieser Stelle SRC = $(TRG).c $(AVRLIB)/timer.c Und durch die "dependecies" im makefile weiss make, dass es timer.o machen muss und wie es das machen muss und dass es beide *.o Dateien zum fertigen Programm zusammenbinden muss.
Ah, gut, danke. Damit komme ich jetzt vielleicht einen Schritt weiter
>avr-objcopy aus dem alten WinAVR meldet keinen Fehler, wenn keine EEPROM >Daten da sind, aber die neue tut es. Weil aber der Fehler vom neuen >avr-objcopy kommt, unterbricht make die Abarbeitung des makefile und der >letzte Schritt - die Anzeige des Code und Speicherverbrauchs durch >avr-size - fällt aus. Man kann auch einfach ein Byte im Eeprom definieren. Hab es gerade ausprobiert. Kostet ansonsten keinen zusätzlichen Speicher. Aber er beendet den Compilerlauf ohne Fehler. Aber jetzt nochmal zurück zum AVR Studio. Ich hab mir die neueste Version (4.13) installiert. Die unterstützt die neue Version des AVR GCC. Wenn ich aber ein Beispiel von der AVRlib compiliere (zb a2dtest.c) erhalte ich folgende Ausgabe:
1 | Build started 13.3.2007 at 13:35:20 |
2 | |
3 | avr-gcc.exe -I"C:\Programme\AVRlib" -I"J:\Eigene Dateien\AVRStudioProjects\a2dtest\." -mmcu=atmega32 -Wall -gdwarf-2 -DF_CPU=14745600UL -O0 -fsigned-char -MD -MP -MT a2dtest.o -MF dep/a2dtest.o.d -c ../a2dtest.c |
4 | |
5 | make: *** No rule to make target `..//C/Programme/AVRlib/rprintf.c', needed by `rprintf.o'. Stop. |
6 | Build failed with 1 errors and 0 warnings... |
Das AVR Studio erzeugt das Makefile automatisch (habe ich angehängt). Wenn ich das original Makefile vom Example verwende funktioniert es (logischerweise). Aber da ich ein fauler Mensch bin würde ich gerne die Möglichkeit des AVR Studio nutzen das Makefile automatisch erzeugen zu lassen. Vielleicht kann mir noch jemand bei der Lösung dieses Problems helfen
Das Dummybyte im EEPROM ist auch eine elegante Lösung ;-) Beim AVR Studio 4.13 kann ich dir nicht so weiterhelfen, weil ich das wieder runtergeworfen habe. Es lief als Betaversion miprä mit Windows98SE und als Releaseversion gar nicht mehr. Das XML-Parsing zerhaut bei meinem Rechner furchtbar den Speicher mit der Folge, dass mir die Exceptions an den unmöglichsten Stellen um die Ohren fliegen. Dieser Ausschnitt aus makefile zeigt, dass AVR Studio von der Position im Objektverzeichnis ausgeht. Von dort ein Verzeichnis hoch (..) und dann kommt die Konfusion mit dem Laufwerksbuchstaben... a2dtest.o: ../a2dtest.c $(CC) $(INCLUDES) $(CFLAGS) -c $< rprintf.o: ..//C/Programme/AVRlib/rprintf.c $(CC) $(INCLUDES) $(CFLAGS) -c $< Wie hast du es gemacht, dass die C-Files so im makefile stehen? Hast du die C-Files im Dateibaum-Fenster des AVR Studio in den Ordner Source aufgenommen? Mir fällt nur als Worst-Case die Umschiffung des Problems ein: Vermeide einen Laufwerkswechsel zwischen normalen Sourcefiles und Libraryfiles. D.h. Schaffe die AVRLIB z.B. auch auf dein J: Verzeichnis.
Stefan wrote: > Soweit ich das überblicke, fehlt dem Programm (*.elf) der > C-Startupcode (Vektoren, DATA+BSS Sektionen,...) und die > C-Library. ... Du überblickst das falsch. Das wäre der Fall gewesen, wenn er avr-ld direkt auf diese Weise aufgerufen hätte. Er hat aber den Compilertreiber avr-gcc benutzt, und der kümmert sich um Startupcode und Bibliothek. > Das Dummybyte im EEPROM ist auch eine elegante Lösung ;-) Nein, es ist eine sehr unelegante. Entweder kommentierst du das EEPROM-Handling aus dem Makefile raus, wenn du es nicht brauchst, oder aber du schreibst vor den Aufruf des avr-objcopy, mit dem die EEPROM-Datei erzeugt werden soll, ein Minuszeichen (direkt nach dem TAB). Schließlich kannst du es noch richtig schick lösen mit
1 | avr-objcopy ... || echo "There appears to be no EEPROM data to copy." |
Da hätt ich auch drauf kommen können. Vielen Dank. vielleicht hilft's ja jetzt auch noch anderen
Das mit dem Minuszeichen ist ja pfiffig. Man lernt nie aus. http://www.gnu.org/software/make/manual/make.html#Errors
> Du überblickst das falsch. Das wäre der Fall gewesen, wenn er avr-ld > direkt auf diese Weise aufgerufen hätte. Er hat aber den > Compilertreiber avr-gcc benutzt, und der kümmert sich um Startupcode > und Bibliothek. Ja, das war ein Denkfehler von mir. Ich dachte, die Procyon AVRlib sei ein kompletter Ersatz für die avr-libc. Ist sie aber nicht. Sie ist eine Sammlung von zusätzlichen Funktionen. Das habe ich gestern gesehen, als ich selbst das Beispielprojekt übersetzt habe.
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.