www.mikrocontroller.net

Forum: Compiler & IDEs Procyon AVRlib + AVR Studio + WinAVR 20070122


Autor: Clifford (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Clifford (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Clifford (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich werden das Beispiel heute abend testen.

Autor: Clifford (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ich nicht verstehe sind diese ganzen "dependecies" in dem Makefile, 
mal abgesehen davon das die meisten bei dem Beispiel eh überflüssig 
sind.
###### dependecies, add any dependencies you need here ###################
#  Dependencies tell the compiler which files in your code depend on which
#  other files.  When you change a piece of code, the dependencies allow
#  the compiler to intelligently figure out which files are affected and
#  need to be recompiled.  You should only list the dependencies of *.o 
#  files.  For example: uart.o is the compiled output of uart.c and uart.h
#  and therefore, uart.o "depends" on uart.c and uart.h.  But the code in
#  uart.c also uses information from global.h, so that file should be listed
#  in the dependecies too.  That way, if you alter global.h, uart.o will be
#  recompiled to take into account the changes.

buffer.o  : buffer.c  buffer.h
uart.o    : uart.c  uart.h    global.h
uart2.o    : uart2.c  uart2.h    global.h
rprintf.o  : rprintf.c  rprintf.h
a2d.o    : a2d.c    a2d.h
timer.o    : timer.c  timer.h    global.h
pulse.o    : pulse.c  pulse.h    timer.h  global.h
lcd.o    : lcd.c    lcd.h    global.h
i2c.o    : i2c.c    i2c.h    global.h
spi.o    : spi.c    spi.h    global.h
swpwm.o    : swpwm.c  swpwm.h    global.h
servo.o    : servo.c  servo.h    global.h
swuart.o  : swuart.c  swuart.h  global.h
tsip.o    : tsip.c  tsip.h    global.h
nmea.o    : nmea.c  nmea.h    global.h
vt100.o    : vt100.c  vt100.h    global.h
gps.o    : gps.c    gps.h    global.h
$(TRG).o  : $(TRG).c            global.h

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)...
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.

Autor: Clifford (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah, gut, danke. Damit komme ich jetzt vielleicht einen Schritt weiter

Autor: Clifford (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
>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:
Build started 13.3.2007 at 13:35:20

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

make: *** No rule to make target `..//C/Programme/AVRlib/rprintf.c', needed by `rprintf.o'.  Stop.
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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
  avr-objcopy ... || echo "There appears to be no EEPROM data to copy."

  

Autor: Clifford (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da hätt ich auch drauf kommen können. Vielen Dank.
vielleicht hilft's ja jetzt auch noch anderen

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit dem Minuszeichen ist ja pfiffig. Man lernt nie aus. 
http://www.gnu.org/software/make/manual/make.html#Errors

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

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.