Ich möchte unter Ubuntu 10.04 die avr-Toolchain compilieren. Dazu habe
ich mich so weit möglich an
http://www.rn-wissen.de/index.php/Avr-gcc_und_avrdude_installieren
gehalten. binutils ging leicht und avr-gcc habe ich nach einigen
Klimmzügen compiliert bekommen. (Es fehlten mpc, mpfr und gmp im
System.)
Bei der avr-libc-1.7.1 beiße ich gerade auf was Hartes: config bricht ab
mit
Hmm, da machst du dich gerade zum Betatester für die allerneuesten
Toolversionen ... der internal compiler error ist im GCC selbst
bereits repariert, allerdings würde er dir dafür mit einem regulären
Compilierfehler um die Ohren fliegen. ;-)
Im Anhang mal ein Snapshot der aktuellen Quellen (SVN-Stand von
heute), der sich hoffentlich mit einem GCC 4.6.0 compilieren lassen
sollte.
Danke für die neue Version. Compilieren tut sie, nur beim make install
findet er avr-ranlib nicht, obwohl sie im PATH steht. Mal sehen, was da
los ist...
Daß die 1.7.1 Betastatus hat, war dort, wo ich sie gefunden hatte, aber
nirgends vermerkt: http://download.savannah.gnu.org/releases/avr-libc/
Uhu Uhuhu schrieb:> Daß die 1.7.1 Betastatus hat
Hat ja keiner behauptet, aber du hast einen Compiler genommen zum
compilieren, den bis zum Erstellen der avr-libc 1.7.1 noch niemand
benutzt hatte. Damit sind die Fehler (die eindeutig in der
Bibliothek lagen), die erst durch diese Compilerversion zutage
traten, vorher nicht entdeckt worden.
So, Compiler und libs sind gebaut.
Nun das nächste Problem mit der libc von hier:
Beitrag "Re: Problem beim compiliren der avr-libc-1.7.1"
Code von Peter Fleury, der im AVR-Studio 4 fehlerfreu läuft, produziert
zwei Fehler:
#define UART0_RECEIVE_INTERRUPT SIG_USART_RECV
#define UART0_TRANSMIT_INTERRUPT SIG_USART_DATA
1
../uart.c:148:36: error: attempt to use poisoned "SIG_USART_RECV"
2
../uart.c:149:36: error: attempt to use poisoned "SIG_USART_DATA"
Leider finde ich das entsprechende #pragma nicht, das die Ursache ist.
> ../uart.c:148:36: error: attempt to use poisoned "SIG_USART_RECV"
2
> ../uart.c:149:36: error: attempt to use poisoned "SIG_USART_DATA"
3
>
>> Leider finde ich das entsprechende #pragma nicht, das die Ursache ist.
Du sollst ja auch nicht die Augen zukleistern, damit du das Symptom
nicht mehr siehst, sondern die Ursache beseitigen. ;-) Die
Interruptvektornamen, die auf SIG_ beginnen, wurden vor nunmehr
5,5 Jahren als veraltet markiert zusammen mit dem kompletten Begriff
"signal" für das Interrupthandling, weil dieser immer wieder zu
Verwirrung geführt hatte.
Schreib' den Code um, dass er ..._vect-Namen benutzt.
Jörg Wunsch schrieb:> Du sollst ja auch nicht die Augen zukleistern, damit du das Symptom> nicht mehr siehst, sondern die Ursache beseitigen. ;-)
Ich hatte gehofft, dort irgend welche Hinweise zu finden. Wo ist denn
das Pragma zu finden?
Uhu Uhuhu schrieb:> Wo ist denn> das Pragma zu finden?
Irgendwo in den Headers. GCC benutzt weitgehend keine Pragmas, sondern
_attribute_. Da wirst du aber nicht viel mehr sehen außer
__attribute__((deprecated)) oder sowas. Lesen der avr-libc-Doku sollte
eigentlich genügen, um die passenden Vektornamen zu finden.
Jörg Wunsch schrieb:> [...] zusammen mit dem kompletten Begriff> "signal" für das Interrupthandling, weil dieser immer wieder zu> Verwirrung geführt hatte.
Ok, eine Wotrwahl ändern ist ja was anderes als
poisoned
WOAS??? poisoned?
> Schreib' den Code um, dass er ..._vect-Namen benutzt.
Mit einem Handstreich werden zig im Netz verfügbare Anwendungen
uncompilerbar???
Damit schiessen sich die GNU-Tools/avr-libc doch selbst ins Knie --
komplett ohne Not...
Nur weil ein paar Leute SIGNAL und INTERRUPT nicht richtig anzuwenden
wussten? Ist heutzutage auch nicht besser bei dem Code, den man oft
sieht mit CLI in ISR-Prolog und SEI im Epilog.
Johann L. schrieb:> Ok, eine Wotrwahl ändern ist ja was anderes als>> *poisoned*
Da musst du dich bei den GCC-Entwicklern beschweren, denn die haben
sich diesen Namen ja ausgedacht.
> Mit einem Handstreich werden zig im Netz verfügbare Anwendungen> uncompilerbar?
Die, die sich bereits seit vielen Jahren beharrlich weigern, die
vorgesehenen APIs zu benutzen.
Allerdings sollten wir irgendwie einen Schalter finden, wie man den
Sourcecode trotzdem noch compiliert bekommt, das sollte man auf der
avr-libc-Liste diskutieren. Da GCC ja auch C99-style _Pragma()
unterstützt, sollte das machbar sein, sowas zu #ifdef'en (bzw. über
ein #define wegzudefinieren).
> Nur weil ein paar Leute SIGNAL und INTERRUPT nicht richtig anzuwenden> wussten?
Das war dazumals ein Krampf, glaub's mir. Es gab verdammt viele Leute,
die ihre ISRs mit INTERRUPT() geschrieben haben, weil's ja ein
Interrupt ist ... dieser Name war ein Fehlschlag von Beginn an, warum
auch immer sich Marek und Denis damals SIGNAL() für die "normalen"
ISRs ausgedacht hatten. Mittlerweile diskutiert kein Schwein mehr
und will das alte SIGNAL() zurück haben, nur die blöden SIG_xxx-
Namen für die Vektoren halten sich wie Kletten, weil es halt 2005
noch keine Möglichkeit im GCC gab, derartige Namen "weich auszuführen".
Jörg Wunsch schrieb:> Allerdings sollten wir irgendwie einen Schalter finden, wie man den> Sourcecode trotzdem noch compiliert bekommt
Ähem, den gibt's schon:
-D__AVR_LIBC_DEPRECATED_ENABLE__
Jörg Wunsch schrieb:> Irgendwo in den Headers.
Z.B. in iomx8.h
> Die, die sich bereits seit vielen Jahren beharrlich weigern, die> vorgesehenen APIs zu benutzen.
Kein Wunder, denn AVR-Studio 4 nimmt das ohne Murren hin...
Jörg Wunsch schrieb:> Johann L. schrieb:>>> Ok, eine Wortwahl ändern ist ja was anderes als>>>> *poisoned*>> Da musst du dich bei den GCC-Entwicklern beschweren, denn die haben> sich diesen Namen ja ausgedacht.
poisoned ist mir bekannt. Aber das poisoning geschieht nicht im gcc,
sondern in der avr-libc wenn ich's recht versteh.
Was ich meinte war, daß es was anderes ist, die Wortwahl zu "signal" zu
ändern, als Makros in <avr/io.h> zu vergiften.
>> Mit einem Handstreich werden zig im Netz verfügbare Anwendungen>> uncompilerbar?>> Die, die sich bereits seit vielen Jahren beharrlich weigern, die> vorgesehenen APIs zu benutzen.
Wenn es eine Anwendung ist, die keine Änderung braucht -- eben weil
sie gut ist und schlicht und ergreifend läuft -- wird auch nix dran
geändert. Oft stehen sie irgendwo als Download bereit; die Projekte sind
abgeschlossen und eben fertig. Das hat nix mit weigern zu tun. Nur
weil Code älter als 5 Jahre ist, ist er dadurch doch nicht schlecht oder
ineffizient oder falsch. Er ist eben fertig und abgeschlossen -- ein
Zustand, den eine Bibliothek oder ein Compiler wohl nie erreichen wird,
aber dennoch gibt's so was ;-)
> Allerdings sollten wir irgendwie einen Schalter finden, wie man den> Sourcecode trotzdem noch compiliert bekommt, das sollte man auf der
Ok, ein Messer um die Kugel wieder aus dem Knie zu puhlen...
> avr-libc-Liste diskutieren. Da GCC ja auch C99-style _Pragma()> unterstützt, sollte das machbar sein, sowas zu #ifdef'en (bzw. über> ein #define wegzudefinieren).
... womit aber die Anwendungen immer noch nicht übersetzbar sind. Der
versierte Anwender wird wissen wo es hakt und an welchem
Stellschräubchen (irgendwelche Compilerflage in irgendwelchen Makefiles)
zu drehen ist.
Glaubst du etwa, ein Poisoning und die Myriaden Anfragen in allen Foren
erzeugen weniger Aufwand als die Header einfach so zu lassen wie sie
sind? Für neue Derivate ist's eh Wurscht und für die alten tun die paar
Zeilen doch keinem Weh.
Ich find's immer noch einen riesen Unterschied, ob ein Projekt, daß man
ausm Web runterlädt, ein paar Angestaubte Features benutzt und sich
klaglos übersetzten lässt und schnurrt; oder ob es schon den Build
verweigert.
Uhu Uhuhu schrieb:>> Die, die sich bereits seit vielen Jahren beharrlich weigern, die>> vorgesehenen APIs zu benutzen.>> Kein Wunder, denn AVR-Studio 4 nimmt das ohne Murren hin...
Klar, wie sollte das auch in der Lage sein, den Inhalt deines
Programms zu analysieren?
Johann L. schrieb:> Aber das poisoning geschieht nicht im gcc,> sondern in der avr-libc wenn ich's recht versteh.
Ja, aber es gibt keine andere Methode als dieses "Vergiften", die der
GCC uns bereitstellt, damit wir endlich die Leute mal dazu bringen,
seit Jahren in der Doku als "deprecated" markierte Dinge aus dem
Verkehr zu ziehen.
> Nur> weil Code älter als 5 Jahre ist, ist er dadurch doch nicht schlecht oder> ineffizient oder falsch.
Wenn das Projekt so lange nicht mehr gepflegt worden wäre, wäre es
schon längst in Stücke zerfallen. Seither haben sich doch viel öfter
schon IO-Register-Namen in den AVRs geändert (bis sie nun endlich mal
bei einer weitgehend einheitlichen Namensgebung angekommen sind,
gottlob) als die paar Änderungen in der avr-libc. (Pascal Stangs
avrlib ist ein typisches Beispiel dieser Kategorie, seit Jahren
ungepflegt und dadurch mittlerweile nicht mehr benutzbar.) Nein, der
Herr Fleury hat sich da, eben weil es keinen Compilerfehler gab, um
diese Stellen nie wieder drum gekümmert. Insofern wäre er
eigentlich der Adressat für die Beschwerden hier. (Headerfiles für
neue Controller haben übrigens die alten Namen nie erhalten, insofern
wird auch seine Bibliothek hier allmählich dem "bit rot" verfallen,
ganze ohne "Vergiftung".)
Aber bezüglich avr-libc das ist hier nicht der richtige Platz, das zu
diskutieren: das Ganze war letztlich Erics Idee, der auf der
avr-libc-Liste niemand widersprochen hat. Noch gibt es keinen
avr-libc-Release damit (das, was ich dem Uhu hier gegeben habe, war ja
nur ein SVN-Snapshot), insofern ist jetzt genau der richtige
Zeitpunkt, das auf der avr-libc-Liste in Frage zu stellen, wenn du
(oder jemand anders hier) denkst, dass das mit den "vergifteten"
SIG_xxx-Namen zu einem Problem wird.
Jörg Wunsch schrieb:> Insofern wäre er> eigentlich der Adressat für die Beschwerden hier.
Na ja, das mag von der Theorie her richtig sein, aber im praktischen
Einsatz ist das der Gaul von hinten aufgezäumt.
Uhu Uhuhu schrieb:> Na ja, das mag von der Theorie her richtig sein, aber im praktischen> Einsatz ist das der Gaul von hinten aufgezäumt.
Wieso? Was würde dir das auf einem der neueren Controller helfen,
auf denen es die alten Namen nie gegeben hat?
Nein, "Maintainer" eines Pakets zu sein, hat was mit "Maintenance"
zu tun, und das wiederum bedeutet, dass man zumindest gelegentlich
mal "nach dem Rechten schaut". (Nicht, dass ich in dieser Beziehung
ein guter Maintainer für all die Dinge wäre, die ich jemals angefasst
habe, aber ich bin mir da zumindest meiner Schuld bewusst.)
Wie schon geschrieben, wenn du den alten Schrott partout weiter
benutzen willst, bis er ganz auseinanderfällt, dann bau' das
-D__AVR_LIBC_DEPRECATED_ENABLE__ ins Makefile rein. Wenn du Peter
Fleury als Dank für seine Bibliothek einen Gefallen tun willst, dann
such dir raus, wie die Vektornamen jetzt heißen sollten (diese
stimmen übrigens seit der Umstellung mit dem Datenblatt überein,
während sie davor jeweils frei erfunden waren) und schick dem Peter
einen Patch. Dann wird seine Bibliothek das Problem noch vor dem
Release der avr-libc-1.7.2 los (wobei es sein kann, dass ich sie auch
als avr-libc-1.8.0 releasen werde, um auf die "Vergiftungserscheinung"
explizit hinzuweisen).
Jörg Wunsch schrieb:> Wie schon geschrieben, wenn du den alten Schrott partout weiter> benutzen willst, bis er ganz auseinanderfällt, dann bau' das> -D__AVR_LIBC_DEPRECATED_ENABLE__ ins Makefile rein.
Da waren wirklich nur die alten SIG-Namen gegen die neuen auszutauschen
und bevor die Funktionen auseinanderfallen, fällt der alte Mega88
auseinander...
Ich habe jedenfalls schon erlebt, daß ein altes Paket mal neu compiliert
werden mußte und die alte Generierungsumgebung nicht mehr verfügbar war
und dann ein Haufen Zeit für völlig unproduktive Änderungen verbraten
wurden mußte, um den alten Text an neue Konventionen anzupassen. Das
sind Fehlerquellen, die man lieber meidet.
Noch ne Frage zu den ISR-Nomenklatur: Gibt's da irgendein System?
Ich glaubte ja, zwischen den Zeilen rausgelesen zu haben, daß die
ISR-Namen geändert wurden, um die den Handbüchern anzugleichen.
Bei der Anpassung gab's direkt ne Bauchlandung:
Z.B: ATtiny24
Handbuch: TIMER1_CAPT
avr-libc: TIMER1_CAPT_vect
aber:
Handbuch: TIMER1_COMPA, TIMER0_OVF, ...
avr-libc: TIM1_COMPA_vect, TIM0_OVF_vect, ...
Gibt's da irgendein System? Wozu die ganze Umstellung, wenn's immer noch
Phantasienamen sind?
Johann L. schrieb:> Handbuch: TIMER1_COMPA, TIMER0_OVF, ...> avr-libc: TIM1_COMPA_vect, TIM0_OVF_vect, ...
Nö, die stimmen schon mit dem Datenblatt überein (leider, bei
anderen AVRs heißen die alle lang). Aber der TIMER1_CAPT_vect stimmt
nicht mehr. In der ersten Datenblattversion, die ich seinerzeit zur
Verfügung hatte, als ich das implementiert habe, hieß dieser Vektor
wirklich auch im Datenblatt noch anders. Das haben sie erst später
geändert, heimlich, still und leise.
Heisst also konkret:
Immer wenn Atmel lustig ist und Umbenennungen vornimmt, ändert sich das
Interface? Wäre doch sinniger -- wenn überhaupt -- neue Bezeichner
hinzuzufügen, auch eine ISR dann auf mehrere Namen horcht.
Werden die alten Namen dann auch alle vergiftet?
Jörg Wunsch schrieb:> Aber der TIMER1_CAPT_vect stimmt> nicht mehr.
Hab' gerade nochmal nachgesehen, der ist ja auch nur noch deshalb
drin, weil er eben in den ersten Versionen so im Datenblatt stand.
TIM1_CAPT_vect steht nun alternativ noch mit dabei.
Kann sein, dass die avr-libc-Doku hier nicht up-to-date ist; das war
eigentlich mal so gedacht, dass man diese automatisch aktualisiert
beim Generieren der Headerdateien aus den XML-Daten, aber das läuft
nun mittlerweile alles ganz anders, und die Doku ist leider in
diesem Prozess etwas stiefmütterlich behandelt. :/
Johann L. schrieb:> Immer wenn Atmel lustig ist und Umbenennungen vornimmt, ändert sich das> Interface? Wäre doch sinniger -- wenn überhaupt -- neue Bezeichner> hinzuzufügen, auch eine ISR dann auf mehrere Namen horcht.
Ist ja in diesem Falle auch der Fall.
Ja, glücklich über diese Umbenennungen in den Datenblättern
bin ich auch nicht, aber daran können wir nun kaum was ändern, und
die Datenblätter haben hier definitiven Charakter.
> Werden die alten Namen dann auch alle vergiftet?
Vermutlich nicht, allerdings sind derartige Umbenennungen (zum Glück)
doch eher die Ausnahme.
Thread beobachten
Seitenaufteilung abschalten