Auch, wenn ich diesmal nicht so viel selbst beitragen konnte, gab es
in letzter Zeit eine Reihe anderer Mitwirkender, die fleißig an der
avr-libc weitergearbeitet haben. Der letzte Release liegt mehr als
2,5 Jahre zurück, sodass es dringend nötig scheint, endlich mal einen
neuen zu machen. Leider hatte ich nicht die Zeit für meinen üblichen
„Spaziergang“ durch die Bug- und Patch-Datenbank, nur einen kurzen
Blick auf ein paar Bugs, die sich schnell beheben ließen.
Hier der Abschnitt aus der NEWS-Datei betreffend Version 1.8.1:
1
*** Changes in avr-libc-1.8.1:
2
3
* Bugs fixed:
4
5
[#31267] misleading header iom128rfa1.h
6
[#35197] sleep.h _BV defined as __BV in AT90S8515 section
7
[#35226] Online-documentation broken - [...]
8
[#35398] assert doesn't work unless stdlib.h is also included
9
[#35498] misspelled in <util/setbaud.h>
10
[#35539] stdlib.h does not provide EXIT_SUCCESS et al.
11
[#35948] iom32u4.h for ATmega32U4 incorrectly defines Timer 2
Johann L. schrieb:> AFAIK unterstützt die 1.8.1 auch das neue Multilib-Layout?
Ich hoffe mal, dass sie das tut. ;-) Die Multilib-Geschichten sind
eins der Dinge, bei denen ich nie so richtig den Durchblick bekommen
habe, leider.
Hallo Jörg,
ich habe gerade versucht, die avr-libc zu kompilieren, allerdings kommt
es zu Fehlermeldungen (Auszug aus /build/avr-libc-1.8.1/config.log):
/tmp/cciUM8wi.s:13: Error: too many memory references for `in'
18
/tmp/cciUM8wi.s:14: Error: too many memory references for `in'
19
/tmp/cciUM8wi.s:19: Error: no such instruction: `ldi r24,0'
20
/tmp/cciUM8wi.s:20: Error: no such instruction: `ldi r25,0'
Compiliert habe ich mit dem avr-gcc 4.9.1 unter arch linux. Setzt die
avr-libc einen aktuelleren Compiler voraus (Anspielung auf die
unbekannten Optionen -V und -qversion) oder liegt das Problem eher an
meinem System?
Die avr-libc 1.8.0 liess sich mit dem avr-gcc 4.9.0 ohne Probleme
kompilieren.
Danke & Gruß,
Oliver
Stimmt wohl was mit deiner Umgebung / Installation nicht: Es wird der
falsche Assembler verwendet.
Außerdem ist es eher unwahrscheinlich, daß die GMP-Header in einer
installierten AVR-Toolchain zu finden sind...
Hallo Johann,
danke für die Hinweise. Zur Erstellung der avr-Toolchain verwende ich
die Scripts von Bingo aus dem avrfreaks Forum; die einzigen Änderungen,
die ich vorgenommen habe, sind die Anpassungen der Versionsnummern. Bis
jetzt hat dieses immer funktioniert und zu einer benutzbaren Toolchain
geführt.
Ich lasse gerade einen Referenzbuild mit der avr-libc-1.8.0 durchlaufen
und werde das log-File auf Deine Anmerkungen hin kontrollieren.
Dass das Configscript 'avr-gcc -V' und 'avr-gcc -qversion' aufruft, ist
also nicht seltsam? Der avr-gcc in der Version 4.9.1 kennt diese
Parameter nicht.
Update Mit dem gcc 4.9.1 und avr-libc-1.8.0 werden im config.log die
gleichen Fehlermeldungen bzgl. den Optionen '-V' und '-qversion'
erzeugt. Es wird auch hier '--with-gnu-as' verwendet, allerdings kommt
es nicht zu den besagten Fehlermeldungen; die avr-libc wird anstandslos
erzeugt.
Das Seltsame ist, dass ich bei einem zweiten Versuch, die avr-libc-1.8.1
zu erstellen, keine Probleme mehr hatte. Aus irgendeinem Grund hat es
nun funktioniert...
Makefile:423: recipe for target 'install-recursive' failed
37
make: *** [install-recursive] Error 1
38
(./buildavr-toolchain.sh) libc build failed
Die detailierten Config- und Build-Logs habe ich angehangen.
Die Fehlermeldung weist zwar darauf hin, einen Bug-Report einzustellen;
mir wäre aber lieber, wenn jmd. ebenfalls versuchen könnte, die Lib mit
dieser Option zu compilieren, um sicherzustellen, dass das Problem nicht
nur auf meinem System (gcc 4.9.1, binutils 2.24, avr-libc-1.8.1)
auftritt.
Hallo Johann,
interessant... Verstehe ich den letzten Eintrag aus dem bug report
richtig, dass es für dieses Problem nun einen Patch (aktualisiertes
"cfgexpand.c") gibt?
Oopzz
Habe nicht die dwarf4 fehler gesehen , nur die erste avrlibc-1.8.1.
Die dwarf4 fehler sind vermotlich auch im meiner version , als das ist
einer "stock" 4.9.1 source.
/Bingo
Oliver schrieb:> Compiliert habe ich mit dem avr-gcc 4.9.1 unter arch linux.
Mittlerweile befindet sich eine aktualisierte Version in
community-testing [1]. Aufgrund eines Bugs, lässt sich avr-libc 1.8.1
nicht mit avr-gcc 4.9.0 kompilieren, mit 4.9.1 klappt es aber
problemlos. Keine Ahnung was du da falsch gemacht hast ;).
Mit freundlichen Grüßen,
Karol Babioch
[1]:
https://mailman.archlinux.org/pipermail/arch-general/2014-August/037028.html
Hallo Karol,
wurde die avr-libc in dem Paket mit "--enable-debug-info=dwarf-4"
konfiguriert?
Wenn ja, wäre ich an weiteren Details/einem Link zu den Details
interessiert. Ohne diese Option habe ich auch keine Probleme, die
Toolchain zu erzeugen.
Grüße,
Oliver
Hallo Joerg.
Zunaechst einmal Danke fuer den neuen Release.
Jörg Wunsch schrieb:> * New devices supported:>> [...], ATmega8A, [...]
Was ist da jetzt dazugekommen? Inwiefern untescheidet sich jetzt der
ATmega8A vom ATmega8 ?
MfG
Ja.
Ich mein ja auch in der Library. (Nicht in der Hardware.)
Der Atmega8A hat effektiv die gleiche Signatur wie der ATmega8.
Es sollte also gar keine Unterscheidung in 8/8A softwareseitig geben,
oder?
MfG
Nur Jörg kan mit 100% sicherheit das sagen , aber von die intro ich
vollte sage ja ... Sie sind 100% identisch , als sehen von die compiler.
Nur die electric specs. hast verändert.
Intro:
1
In order to optimize the manufacturing process and to further reduce current
2
consumption, an optimized version of ATmega8 has been introduced.
3
Application Note
4
The ATmega8A is a functionally identical, drop-in replacement for the ATmega8.
5
All devices are subject to the same qualification process and same set of
6
production tests, but as the manufacturing process is not the same some electrical
7
characteristics differ.
Die makefiles und ioregs indikere kein verschideness.
Siehe anhang.
mfg
Bingo
Hoffe Sie verstehe meiner (nur 2 jahre deutch im schule)
Karsten F. schrieb:> Hoffe Sie verstehe meiner (nur 2 jahre deutch im schule)
Leider manchmal etwas schwierig, den Sinn zu erkennen.
Wenn Sie deutsch besser lesen koennen, als schreiben:
Es hat hier sicherlich auch niemand was dagegen, wenn Sie vereinzelt
ihre Antworten in englisch verfassen?
MfG
Oliver schrieb:> wurde die avr-libc in dem Paket mit "--enable-debug-info=dwarf-4"> konfiguriert?
Nein, das schlägt in der Tat fehl. Habe das an offizieller Stelle
gemeldet [1] und laut Jörg liegt es wohl an einem Bug innerhalb von GCC
selbst und ist dort bereits bekannt [2]. So wie ich das sehe gibt es
bereits einen Patch, das Ganze sollte also hoffentlich irgendwann einmal
(in naher Zukunft) funktionieren ;).
Mit freundlichen Grüßen,
Karol Babioch
[1]: https://savannah.nongnu.org/bugs/index.php?43049
[2]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62084
Karol Babioch schrieb:> Nein, das schlägt in der Tat fehl. Habe das an offizieller Stelle> gemeldet [1] und
Hey - danke fürs Reproduzieren/Bestätigen und 'kümmern' ;)
Grüße,
Oliver
Mal 'ne dumme Frage:
Wie kommt man als Anwender des aktuellen Atmel-Studio 6.2 in den Genuß
dieser Lib? Muß man da (ggf. länger) auf ein Update von Atmel warten?
Wie bekomme ich überhaupt die Version der avr-libc heraus, die im
Atmel-Studio verwendet wird? Habe da bislang nix zu gefunden.
Habe das letzte AVR8-Toolchain-Update fürs Atmel-Studio installiert (das
ist vom 30.04.2014), die Toolchain liegt offenbar im Verzeichnis
Wenn ich das richtig sehe, ist die 3.4.1056 die Atmel-interne
Versionsnummer, und die GCC-Version dort anscheinend die 4.8.1, aber wo
finde ich die Version der avr-libc?
Gruß,
Thorsten
Thorsten S. schrieb:> Wie bekomme ich überhaupt die Version der avr-libc heraus, die im> Atmel-Studio verwendet wird? Habe da bislang nix zu gefunden.
Include-Datei avr/version.h suchen, reinsehen.
Mark 99 schrieb:> Include-Datei avr/version.h suchen, reinsehen.
Besten Dank!
Manche Dinge sind ganz einfach, wenn man nur weiß wie's geht. ;-)
Versions-String ist "1.8.0svn" also die Vorgängerversion
(was logisch erscheint, da die Toolchain vom 30.04.2014 ist).
Ist es möglich, und falls ja, überhaupt sinnvoll, die libc unabhängig
vom Rest der Toolchain upzudaten?
Gruß,
Thorsten
Möglich: ja.
Sinnvoll: Musst du entscheiden. Brauchst du eines der neuen Features?
Willst du einen der Bugfixes? Ansonsten "never change a running system"
ist das Gegenargument.
Thorsten S. schrieb:> Wie kommt man als Anwender des aktuellen Atmel-Studio 6.2 in den Genuß> dieser Lib? Muß man da (ggf. länger) auf ein Update von Atmel warten?
Ich vermute mal, daß Atmel keine 1.8.0 ausliefert sondern eine neuere
(inoffizielle) Version, denn die 1.8.0 kann mit avr-gcc 4.7+ nicht
funktionieren.
Such einfach mal im Installationsverzeichnis nach 'tiny-stack'; wenn's
solche Verzeichnisse gibt, dann ist's keine avr-libc 1.8.0.
Johann L. schrieb:> Ich vermute mal, daß Atmel keine 1.8.0 ausliefert sondern eine neuere> (inoffizielle) Version, denn die 1.8.0 kann mit avr-gcc 4.7+ nicht> funktionieren.
Offensichtlich hast Du recht, denn die Lib des Atmel-Studio 6.2
unterstützt bereits die in Jörgs Post oben unter "new devices supported"
gelisteten Controller, wie den ATMEGA256RFR2, XMEGA16A4U ...
Hab jetzt nicht alle durchgesehen, aber die, bei denen ich nachgeschaut
habe, waren schon drin.
> Such einfach mal im Installationsverzeichnis nach 'tiny-stack'; wenn's> solche Verzeichnisse gibt, dann ist's keine avr-libc 1.8.0.
Ja, gibt's.
Besten Dank. Atmel hat ganz offensichtlich da was dran verändert.
Also werde ich schön die Finger davonlassen, an der Lib rumzufummeln,
zumal ich bislang kein Problem damit feststellen konnte.
Stephan B. schrieb:> Ja. Atmelt patcht meines Wissens nach aber nur die avr-libc nach eigenen> Vorstellungen.
Die kooperieren bzw. bringen sich seit einigen Jahren bei allen
benötigten Werkzeugen der Toolchain ein, also auch bei der gcc und den
binutils.
Allerdings sitzen die noch auf einer Menge von Patches und Anpassungen,
die sie nur sehr mühselig in die entsprechenden Projekte einbringen.
Laut E-Mail Kontakt mit einem Atmel Mitarbeiter liegt das wohl in erster
Linie daran, dass sie schlichtweg noch nicht dazu gekommen sind.
Mich z.B. stört derzeit der fehlende Support für ATtiny441/841 am
Meisten. Mittlerweile ist zwar wenigstens die gcc im SVN trunk soweit,
innerhalb von avr-libc fehlt davon aber immer noch jede Spur. Mal sehen
wie lange sie sich hierfür noch Zeit lassen werden bzw. wann die nächste
Version von avr-libc dann überhaupt veröffentlicht wird ;).
Zumindest nach meinem Verständnis machen sich die Leute von Atmel das
Leben aber selbst schwer, weil sie trotz der gleichen Codebasis den
Überblick über etliche Versionen behalten müssen. Allein für das Atmel
Studio gibt es, soweit ich weiß, ja mehrere Support Packages usw. Keine
Ahnung warum da nicht einfach alles in die Upstream Projekte gepusht
wird, sodass man keine (oder möglichst wenige) interne Anpassungen mehr
vornehmen muss.
Mit freundlichen Grüßen,
Karol Babioch
Karol Babioch schrieb:> Mich z.B. stört derzeit der fehlende Support für ATtiny441/841 am> Meisten. Mittlerweile ist zwar wenigstens die gcc im SVN trunk soweit,> innerhalb von avr-libc fehlt davon aber immer noch jede Spur.
Du sprichst hierbei von gcc und avr-libc, richtig?
Bei Atmels Version der (Linux-)Toolchain mit avr-libc habe ich mir damit
bisher noch keine Probleme eingehandelt. Aber ich würde auch lieber mit
"regulären" Releases arbeiten, zumal ATtiny441/841 nicht erst seit
gestern auf dem Markt sind.
Konrad S. schrieb:> Du sprichst hierbei von gcc und avr-libc, richtig?
Ja.
Konrad S. schrieb:> Bei Atmels Version der (Linux-)Toolchain mit avr-libc habe ich mir damit> bisher noch keine Probleme eingehandelt.
Probleme gibt es damit wohl keine (zumindest nicht mehr als mit den
regulären Versionen). Das Problem ist halt, dass die "veraltet" sind
(gcc 4.4.7?). Für den Download muss man sich registrieren und überhaupt
ist die Installation viel "komplizierter". Die regulären Versionen
finden sich hingegen in der Paketverwaltung jeder Distribution.
Konrad S. schrieb:> Aber ich würde auch lieber mit> "regulären" Releases arbeiten, zumal ATtiny441/841 nicht erst seit> gestern auf dem Markt sind.
Eben.
Mit freundlichen Grüßen,
Karol Babioch
Karol Babioch schrieb:> Das Problem ist halt, dass die "veraltet" sind> (gcc 4.4.7?).
avr-gcc --version
avr-gcc (AVR_8_bit_GNU_Toolchain_3.4.3_1072) 4.8.1
> Für den Download muss man sich registrieren
Wohl wahr!
> und überhaupt> ist die Installation viel "komplizierter".
tar xzf avr8-gnu-toolchain-3.4.3.1072-linux.any.x86_64.tar.gz
> Die regulären Versionen> finden sich hingegen in der Paketverwaltung jeder Distribution.
Leider zuweilen auch ganz schön veraltet.
Konrad S. schrieb:> bal schrieb:>> Installieren != Entpacken>> Gelaber!
Nö, damit hat er schon nicht ganz unrecht. Zumindest einmal müsste man
den Ordner noch in die PATH Umgebungsvariable packen. Nutzbar ist das so
aber nur für den einzelnen Nutzer, ansonsten müsste man es außerhalb des
Home-Verzeichnisses ablegen. Und ohne es dem Paket-Manager mitzuteilen
(d.h. ein Paket zu erstellen) ist das nicht unbedingt die feine
englische Art. Prinzipiell alles lösbare "Probleme", aber das alles
sollte halt eigentlich gar nicht notwendig sein - vor allem weil Atmel
versprochen hat enger mit den Upstream Projekten zusammen zu arbeiten.
Konrad S. schrieb:> Karol Babioch schrieb:>> Das Problem ist halt, dass die "veraltet" sind>> (gcc 4.4.7?).>> avr-gcc --version> avr-gcc (AVR_8_bit_GNU_Toolchain_3.4.3_1072) 4.8.1
Ich habe diese Information aus den dazugehörigen Release Notes.
Scheinbar ist das dann nicht korrekt? Ist die Version unter Windows die
selbe?
Konrad S. schrieb:>> Die regulären Versionen>> finden sich hingegen in der Paketverwaltung jeder Distribution.>> Leider zuweilen auch ganz schön veraltet.
Nicht bei Arch Linux ;).
Mit freundlichen Grüßen,
Karol Babioch
Karol Babioch schrieb:> Konrad S. schrieb:>> bal schrieb:>>> Installieren != Entpacken>>>> Gelaber!>> Nö, damit hat er schon nicht ganz unrecht. Zumindest einmal müsste man> den Ordner noch in die PATH Umgebungsvariable packen. Nutzbar ist das so> aber nur für den einzelnen Nutzer, ansonsten müsste man es außerhalb des> Home-Verzeichnisses ablegen. Und ohne es dem Paket-Manager mitzuteilen> (d.h. ein Paket zu erstellen) ist das nicht unbedingt die feine> englische Art. Prinzipiell alles lösbare "Probleme",
Nun, ich habe viele Jahre eine größere (überwiegend) Unix-Umgebung
betreut und ausgebaut und bin dadurch "vorbelastet". Und aus dieser
Erfahrung heraus kann ich sagen, dass eine "Installation" eines
positionsunabhängigen Softwarepakets, das noch nicht einmal eine harte
Abhängigkeit von einer bestimmten Distribution oder Version aufweist,
aus einem tar.gz heraus zu den einfacheren Dingen des SysAdmin-Lebens
gehört. Insofern hat Atmel hier gute Arbeit geleistet.
Das Verseuchen von PATH mit allen möglichen Verzeichnispfaden, die auch
nur irgenwas Ausführbares enthalten (generell des Environments mit
Konfigurationsdaten), führt früher oder später zum Tod eines geordneten
Betriebsablaufs. Spätestens dann, wenn mehrere Versionen einer Software
vom selben User benutzt werden müssen, am Besten noch gleichzeitig.
Ein bewährter Lösungsansatz nimmt ein einziges Verzeichnis in PATH auf.
In dieses Verzeichnis kommen symbolische Links auf Programme bzw.
Aufrufscripts für Programme, die spezielles Environment benötigen.
> aber das alles> sollte halt eigentlich gar nicht notwendig sein - vor allem weil Atmel> versprochen hat enger mit den Upstream Projekten zusammen zu arbeiten.
Ja, diese Hoffnung bleibt. Es ist doch angenehmer per Paketverwaltung -
klickediklick - die aktuelle Toolchain zu installieren. Muss man nicht
soviel nachdenken - äääähmmm?!? - hat man mehr Zeit, die man ins Ziel
investieren kann, anstatt in den Weg.
> Konrad S. schrieb:>> Karol Babioch schrieb:>>> Das Problem ist halt, dass die "veraltet" sind>>> (gcc 4.4.7?).>>>> avr-gcc --version>> avr-gcc (AVR_8_bit_GNU_Toolchain_3.4.3_1072) 4.8.1>> Ich habe diese Information aus den dazugehörigen Release Notes.> Scheinbar ist das dann nicht korrekt? Ist die Version unter Windows die> selbe?
Ich habe die Linux-Version von hier:
http://www.atmel.com/tools/atmelavrtoolchainforlinux.aspx?tab=overview
Die dazu passende Windows-Version sollte hier sein:
http://www.atmel.com/tools/atmelavrtoolchainforwindows.aspx
Da findet sich auch:
> Konrad S. schrieb:>>> Die regulären Versionen>>> finden sich hingegen in der Paketverwaltung jeder Distribution.>>>> Leider zuweilen auch ganz schön veraltet.>> Nicht bei Arch Linux ;).
Ja, das ist schon vorgemerkt als Ablösung für mein aktuell noch
eingesetztes Ubuntu 10.04. Muss eh bald weg, weil es dann keine Updates
mehr gibt.
Karol Babioch schrieb:> Die regulären Versionen> finden sich hingegen in der Paketverwaltung jeder Distribution.
Dann ist Debian wohl keine Distribution. Da ist nämlich seit einiger
Zeit die Atmel Toolchain drin.
Konrad S. schrieb:> Nun, ich habe viele Jahre eine größere (überwiegend) Unix-Umgebung> betreut und ausgebaut und bin dadurch "vorbelastet".
Ein paar Jährchen Unix bzw. (überwiegend) Linux Erfahrung habe ich auch
schon sammeln dürfen - unter anderem auch auf Servern.
Konrad S. schrieb:> Insofern hat Atmel hier gute Arbeit geleistet.
Ja, verglichen mit vielen anderen Toolchains ist das wirklich
verhältnismäßig einfach.
Konrad S. schrieb:> Ein bewährter Lösungsansatz nimmt ein einziges Verzeichnis in PATH auf.> In dieses Verzeichnis kommen symbolische Links auf Programme bzw.> Aufrufscripts für Programme, die spezielles Environment benötigen.
Wobei das aktuell halten der symbolischen Links auf einem
Rolling-Release Desktop-System wie Arch Linux wohl auch nur bedingt Spaß
macht. Es kommen immer mal wieder neue Werkzeuge hinzu bzw. alte werden
ersetzt. Ich verlasse mich da größtenteils auf die Distribution (sowohl
bei Desktops als auch bei Servern) und hatte da noch nie größere
Probleme. Kleinere Anpassungen kann man ja z.B. über "/etc/profile.d"
vornehmen ...
Leo C. schrieb:> Dann ist Debian wohl keine Distribution.
Sehe ich genauso ;). Let the flame war begin ...
Leo C. schrieb:> Da ist nämlich seit einiger> Zeit die Atmel Toolchain drin.
Wenn ich das [1] gerade richtig interpretiere, dann aber erst im
aktuellen testing Zweig (jessie). Im stable Zweig findet man hingegen -
ganz in guter alter Debian Manier - nur eine "veraltete" Version
(4.7.2).
Unabhängig davon war meine "Kritik" ja hauptsächlich an Atmel selbst
gerichtet und ich wollte hier nicht die Vor- bzw. Nachteile der diversen
Distributionen diskutieren. Fakt ist, dass Atmel vor einiger Zeit
versprochen hat sich bei den Upstream Projekten einzubringen - bisher
leider nur mit mäßigem Erfolg, weil zum Teil fast selbst ein Jahr alte
Controller noch nicht von diesen Werkzeugen unterstützt werden.
Mit freundlichen Grüßen,
Karol Babioch
[1]: https://packages.debian.org/de/wheezy/gcc-avr
Leo C. schrieb:> Dann ist Debian wohl keine Distribution. Da ist nämlich seit einiger> Zeit die Atmel Toolchain drin.
Hm, die Toolchain, die hier
http://www.atmel.com/tools/atmelavrtoolchainforlinux.aspx?tab=overview
zu finden ist, hat Erweiterungen für z.B. ATtiny841 drin. Das bezeichne
ich als "Atmel Toolchain", im Sinne von: diese Toolchain stammt von
Atmel. Dagegen ist in den Debian-Paketen nur der avr-gcc usw. ohne diese
Erweiterungen enthalten. Falls ich mich diesbezüglich irre, lass es mich
wissen, denn ich würde auch lieber Pakete verwenden.
Konrad S. schrieb:> Dagegen ist in den Debian-Paketen nur der avr-gcc usw. ohne diese> Erweiterungen enthalten. Falls ich mich diesbezüglich irre, lass es mich> wissen, denn ich würde auch lieber Pakete verwenden.
Ohne es überprüft zu haben: Im testing Zweig befindet sich wohl
tatsächlich die gesamte Atmel Toolchain (basierend auf Version 3.4.4),
siehe [1] [2] [3]. Inwiefern das Ganze schon brauchbar ist (bzw. was das
alles für Abhängigkeiten aus testing nach sich zieht, kann ich gerade
nicht bewerten).
Alles in allem: Wie weiter oben schon angedeutet, halte ich das für eine
unnötige Fragmentation seitens Atmel.
Mit freundlichen Grüßen,
Karol Babioch
[1]: https://packages.debian.org/de/sid/binutils-avr
[2]: https://packages.debian.org/de/sid/gcc-avr
[3]: https://packages.debian.org/de/sid/avr-libc
Thread beobachten
Seitenaufteilung abschalten