www.mikrocontroller.net

Forum: Compiler & IDEs avr-libc-1.2.6


Autor: Birger* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt ja jetzt schon wieder 'ne neue avr-libc-1.2.6 - wie schön.
Leider kommt aber einfach keine neue Version von WinAVR mit
entsprechender Integration raus; ich warte schon lange auf die volle
Unterstützung der neuen Controller wie zum Beispiel AT90CAN128. Deshalb
möchte ich jetzt doch mal versuchen, das selber zu kompilieren. Nur, ich
verstehe bis jetzt nur Bahnhof². Mir fehlt noch eine hilfreiche korrekte
Anleitung, was unter Windows(und das dürfte ja wohl sicher die
gigantische Mehrheit sein) zu tun ist. Mingw hab ich und was nu?

Autor: MSE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab gerade gesehen, dass die neue Version 1.4 heißt:

http://www.avrfreaks.net/index.php?name=PNphpBB2&f...

Gruß, Michael

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

Bewertung
0 lesenswert
nicht lesenswert
Suche nach Kai Klenovsek's Anleitung, die er hier im Forum
geschrieben hat.

Der AT90CAN128 dürfte allerdings bereits in der existierenden
WinAVR-Version unterstützt gewesen sein...

Autor: Birger* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was den Bereich EEprom betrifft, leider eben noch nicht.

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

Bewertung
0 lesenswert
nicht lesenswert
Dafür solltest du theoretisch mit einem reinen Upgrade der avr-libc
auskommen, d.h. du musst dir eigentlich keinen neuen Compiler bauen.
Da wir mittlerweile (seit version 1.2.6) auch Binärversionen
mitliefern (die sind letztlich komplett unabhängig vom
Betriebssystem), müsste dir eine solche genügen.

Aber (und daher der Konjunktiv): ich habe einen Bericht gelesen, in
dem jemand einen Compilerfehler gemeldet hat beim Einbinden der neuen
<avr/eeprom.h> mit GCC 3.4.3.  Es könnte also sein, dass du aus diesem
Grunde doch einen neueren Compiler brauchst (dann vergiss aber bitte
nicht, ihn vor dem Bauen zu patchen, sonst hat er keinen AT90CAN128
Support).

Autor: Birger* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, ich hab zwar nach Anleitung
http://kk.elektronik-4u.de/index.php?Sid=12 einen Compiler erstellen
können. Als GCC-Core ging GCC 4.0.2 nicht, da hab ich den bekannten
3.4.3 genommen. Nur nach dem langen Kompilieren kennt der nun gar
keinen AT90CAN128 mehr. Du schreibst was von Patchen. Ja, aber was und
wo denn blos? Jörg, stell dir vor, du bist selber neu in dem Gewerbe
und man gibt dir deine Antworten. Mußte zugeben, die helfen so noch
nicht weiter.

Autor: Axel Gartner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Inzwischen gibt es die avr-libc-1.4.0.
Gruß
Axel

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

Bewertung
0 lesenswert
nicht lesenswert
> Nur nach dem langen Kompilieren kennt der nun gar
> keinen AT90CAN128 mehr. Du schreibst was von Patchen. Ja, aber
> was und wo denn blos? Jörg, stell dir vor, du bist selber neu
> in dem Gewerbe und man gibt dir deine Antworten.

Nun, wie man binutils und Compiler baut, musstest du ohnehin
erstmal lernen.  Daher wollte ich dir nicht gleich die URLs
für die Patches kundtun, um den Klumpen, der auf dich einschlägt,
nicht noch größer werden zu lassen.  Das mit dem Compilieren war
erstmal das Handwerkszeug.

Btw., nimm bitte den GCC 3.4.4, nicht 3.4.3.  Es genügt, wenn
du core und ggf. c++ saugst.

Grundregel des Patchens: du gehst in das ausgepackte Verzeichnis,
und rufst dort auf:

patch -p0 < Name-der-Patchdatei

Die Patches meiner FreeBSD-Ports kannst du über diese Links
erreichen:

http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/...
http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/...

Insebesondere werden dich dabei die "new device" Patches
interessieren.  Die anderen kannst du natürlich auch mit
angucken, zumal fast alle (in dieser oder einer geringfügig
anderen Form) auch im WinAVR waren/sind.

Ich würde dir empfehlen, zuerst die binutils-2.16 mit den
Patches zu bauen und zu installieren und danach den GCC 3.4.4.

Autor: Daniel J. (deejay)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich wollte an dieser Stelle nur mal ein Dankeschön an Jörg Wunsch
loswerden (und natürlich auch an alle anderen, die am AVR-GCC, an der
AVR Libc und was sonst noch dazugehört mitwirken).
Dank der neuen AVR LibC und den oben genannten Patches kann ich nun
auch in gewohnter Manier für den Tiny45 entwickeln. :-)
Besten Dank!

MfG
  Daniel Jelkmann

Autor: Birger* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, nach mehreren Versuchen mit Binutils 2.16.1, GCC 3.4.4, AVR-LIBC
1.2.6 u. 1.4.0 hab ich jetzt endlich auch einen funktionsfähigen neuen
Compiler. Da die neue AVR-LIBC 1.4.0 einige Änderungen an meinem
bisherigen Quellcode (z.B. fdevopen) erfordert, habe ich auch versucht,
die ältere 1.2.6 zu integrieren. Beim Compilieren klemmte es dann aber
fast immer an so Sachen wie "SIGNAL ... type of __vectorxx defaults to
int" oder "crtm128.o No such file". Also bin ich bei 1.4.0 erstmal
geblieben, obwohl ich dachte, dass es möglich sei, fast jede (neuere)
AVR-LIBC mit jedem (neuerem) GCC zu verheiraten. Das scheint aber wohl
so nicht zu gehen, bzw. dann wären wohl weitere Patches von Nöten.

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

Bewertung
0 lesenswert
nicht lesenswert
> Da die neue AVR-LIBC 1.4.0 einige Änderungen an meinem
> bisherigen Quellcode (z.B. fdevopen) erfordert, ...

Keinesfalls.

fdevopen() ist nach wie vor vorhanden und wird es sicher auch bleiben,
wobei ich aber vermute, dass es künftig nur noch wenige Leute benutzen
werden.

Die einzige Änderung, die wirklich Code-Modifikationen nach sich zieht
ist, dass der INTERRUPT()-Makro nur noch via <compat/deprecated.h> zu
erreichen ist.  Ansonsten würden wir dir natürlich nahelegen,
allmählich auf ISR() statt SIGNAL() und die neuen Interruptvektor-
Namen umzustellen.  Meine persönliche Idee ist, dass in avr-libc-1.6
SIGNAL() ebenfalls in <compat/deprecated.h> landet.  Die alten
Vektornamen werden dagegen vermutlich aus pragmatischen Gründen (die
Namen sind über die vielen avr/io*.h-Dateien verstreut) noch länger
verfügbar bleiben.  Aber das ist Zukunftsmusik.

Wenn du natürlich avr-libc-1.4 benutzen magst, kannst du vom neuen
stdio-Modell dahingehend profitieren, dass kein malloc() mehr nötig
ist.

> Beim Compilieren klemmte es dann aber fast immer an so Sachen wie
> "SIGNAL ... type of __vectorxx defaults to int" oder "crtm128.o
No
> such file".

Klingt sehr schräg.

> ..., obwohl ich dachte, dass es möglich sei, fast jede (neuere)
> AVR-LIBC mit jedem (neuerem) GCC zu verheiraten. Das scheint aber
wohl
> so nicht zu gehen, bzw. dann wären wohl weitere Patches von Nöten.

Keineswegs.  Ich compiliere ja auch problemlos beide Varianten.  Die
1.2.6 ist schließlich nur paar Tage älter als die 1.4.0, und
möglicherweise wird's auch noch eine 1.2.7 irgendwann geben.
Allerdings habe ich bislang keinen GCC 4.x, sondern noch 3.4.4, aber
ich wüsste nicht, was das dahingehend ändern soll.

Autor: Birger* (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
fdevopen() brauchte bislang 2 Routinen und einen nutzlosen
Dummyoperator, der jetzt weggefallen ist. Das führt zum Abbruch beim
Übersetzen von "altem" Code mit neuer AVR-LIBC, was also doch wohl
eine drastische Änderung ist. Außerdem müssen die PUT und GET
Funktionen nun einen Streamnamen (FILE*) mit sich führen, was bislang
nicht zwingend der Fall war - führt hier neu zum Warning.
Weshalb schreibst du, dass fdevopen() in Zukunft nicht mehr nötig ist?
Im Mikrocontroller gibt's ja kein STDIO auf die Console, deshalb
gibt's das doch erst.

Die Änderung auf ISR() und neue Namen statt SIGNAL() hab ich gleich
übernommen, weil's mir gefiel.

Ich hab dann heute morgen nochmal spaßeshalber versucht, GCC 3.4.3 mit
LIBC 1.2.6 zu verheiraten. Das scheitere mit Error schon beim
Übersetzen des GCC. Das Thema bleibt für mich recht nebulös, denn
deterministische Erfolge scheinen eher selten zu sein. Ich habe alles
genauso gemacht, wie ich es auf der
http://kk.elektronik-4u.de/index.php?Sid=12 vorfinde, bzw. teilweise
geht diese Anleitung gar nicht mehr, weil auch dort ein configure
eingeführt wurde. Immerhin habe ich herausgefunden, wie ich make
install dazu bewegen kann, in C:\WinAVR zu installieren. GCC 3.4.4 und
AVR-LIBC 1.4.0 scheinen aber bislang fehlerfrei zu funktionieren.

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

Bewertung
0 lesenswert
nicht lesenswert
> fdevopen() brauchte bislang 2 Routinen und einen nutzlosen
> Dummyoperator, der jetzt weggefallen ist. Das führt zum Abbruch beim
> Übersetzen von "altem" Code mit neuer AVR-LIBC, was also doch wohl
> eine drastische Änderung ist.

Please RTFDoc:

http://www.nongnu.org/avr-libc/user-manual/group__...

(Siehe die Anmkerkung unter "Note".)

> Weshalb schreibst du, dass fdevopen() in Zukunft nicht mehr nötig
> ist?

Hast du dir denn wenigstens mal die Einleitung der neuen Doku
angesehen?  Der Abschnitt "Running stdio without malloc()" sollte
das
eigentlich klar ausdrücken.  Wenn nicht, bitte ich um
Verbesserungsvorschläge.

Ich denke, dass im Laufe der Zeit wohl nahezu alle Applikationen zu
fdev_setup_stream() bzw. FDEV_SETUP_STREAM() migrieren werden.

> Immerhin habe ich herausgefunden, wie ich make install dazu bewegen
> kann, in C:\WinAVR zu installieren.

Ich hoffe, du hast es mit ./configure --prefix=c:/WinAVR gemacht
(bzw. für avr-libc < 1.4 mit ./doconf --prefix=c:/WinAVR) und nicht
etwa erst beim Installieren.  Es ist zwar möglicherweise kein krasser
Unterschied, aber die Angabe von --prefix ist auf jeden Fall die
Methode der Wahl.

> Das Thema bleibt für mich recht nebulös, denn deterministische
> Erfolge scheinen eher selten zu sein.

Dann müsstest du bitte mit konkreten Logfiles aufwarten.  Sorry, ich
habe kein Windows, ich kann Kais Anleitung nicht selbst testen.

Autor: Kai Klenovsek (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich hab dann heute morgen nochmal spaßeshalber versucht, GCC 3.4.3
mit
> LIBC 1.2.6 zu verheiraten. Das scheitere mit Error schon beim
> Übersetzen des GCC. Das Thema bleibt für mich recht nebulös, denn
> deterministische Erfolge scheinen eher selten zu sein. Ich habe
alles
> genauso gemacht, wie ich es auf der.

Tja unter Windows ist es halt jedesmal ein neuer Kampf die Toolchain zu
erstellen. Leider kann ich auf meiner Seite halt nicht alle Probleme
behandeln. Das soll nur ein kleiner Guide sein. Ein Update wird aber
folgen. Bei Problemen hilft nur jede Menge lesen von Dokumentationen
wie configure, make, gcc usw. und dann wächst man langsam in die Sache
rein. Ich bin auch keine Unix-Guru, habe mir halt nur die Zeit dafür
genommen :-).

Ciao,
Kai

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

Bewertung
0 lesenswert
nicht lesenswert
Sorry übrigens, die Forumsoftware vermasselt die Unterstriche in
den Links in HTML <u> tags.  Du müsstest dir URL mal cut&pasten.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
warum wird denn WinAVR nicht aktualisiert? Die letzte Version ist vom
Februar und wie es scheint hat sich sowohl beim Compiler als auch bei
der Lib einiges getan.

Es wäre für DAUs wie mich recht hilfreich. Ich hab von C wenig und von
Toolchains und Compiler compilieren überhaupt keine Ahnung. Desshalb
wäre es für mich ne erhebliche Erleichterung wenn ich mich auf das
Programmieren konzentrieren könnte. Wenn ich da Trittsicher bin kann
ich mich immer noch auf die unteren Ebenen wagen.

Wird es in absehbarer Zeit ein aktualisiertes Komplettpaket geben?

mfg

Autor: Roman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir geht es genau so. Ich habe den ATtiny 13 programmiert, der leider
vom Speicher nicht ausreichte. Jetzt bin ich umgestiegen auf den ATtiny
45. Leider komme ich jetzt nicht mehr weiter. Die zuvor beschriebenen
Anleitungen haben mich nicht weiter gebracht. Gibt es  in absehbarer
Zeit ein Komplettpaket?

mfg

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.