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?
Ich hab gerade gesehen, dass die neue Version 1.4 heißt: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=33545 Gruß, Michael
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...
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).
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.
> 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/avr-gcc/files/ http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/avr-binutils/files/ 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.
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
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.
> 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.
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.
> 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__avr__stdio.html#ga40 (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.
> 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
Sorry übrigens, die Forumsoftware vermasselt die Unterstriche in den Links in HTML <u> tags. Du müsstest dir URL mal cut&pasten.
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
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
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.