mikrocontroller.net

Forum: Compiler & IDEs Namenschaos beim avr-gcc


Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, ich hatte die Frage zwar schonmal in meinem Forum gestellt, aber da 
sich hier einige Entwickler rumtreiben ist die Diskussion hier 
vermutlich besser aufgehoben.

Es geht um das Durcheinander von Registernamen, Interrupts usw, das sich 
im laufe der Zeit gebildet hat. Hier ist zum größten Teil Atmel schuld. 
Nur ein Beispiel: der USI Start IRQ heißt einmal USI_START, einmal 
USI_STRT und einmal USI_STR.

Jetzt ist die Frage, ob man da nicht mal was dagegen tun könnte. Z.B. in 
dem man für identische Interrupts oder Register einen einheitlichen 
Namen hinzufügt. So wie es derzeit ist muss man viel basteln, wenn man 
eine halbwegs universell verwendbare Funktion schreiben will.

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,


eine ähnliche Anfrage gabs vor geraumer Zeit schonmal.
"man da nicht mal was dagegen tun könnte"

Ergebnis: "Man" kann was dagegen tun, es steht jedem frei sich zu 
betätigen :)


Gruß,
Alex

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>So wie es derzeit ist muss man viel basteln, wenn man
>eine halbwegs universell verwendbare Funktion schreiben will.

So, wie es jetzt derzeit ist, sind die Interrupt-Namen nur defines auf 
die entsprechenden Vektoren (so in der Art wie
#define INT0_vect _Vector(1)
, und damit ist es überhaupt kein Problem, sich da selber 
vereinheitlichte Namen auszudenken.

Musst du einfach nur machen.

Oliver

Autor: Benedikt Köppel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

melde dich doch bei der avr-libc [1] als Entwickler, schreibe Patches um 
die Namensgebung zu vereinheitlichen und reiche sie ein.

Ich denke das klappt schon... Eine Anfrage à la "könntet ihr das bitte 
machen?" wird wahrscheinlich abgelehnt. Eine Anfrage im Stil "ich habe 
das und das gemacht und als Patch im Anhang" resultiert wohl eher darin, 
dass sie den Patch aufnehmen.

[1] http://savannah.nongnu.org/projects/avr-libc

Gruss,
Benedikt

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
naja, dann wird halt alles beim alten bleiben weil ich keine Zeit habe, 
mehrere Dutzend Dateien zu überarbeiten

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus Burrer schrieb:
> naja, dann wird halt alles beim alten bleiben weil ich keine Zeit habe,
> mehrere Dutzend Dateien zu überarbeiten

Das Überarbeiten an sich ist nicht so sehr das Problem.
Das Problem ist, mit einem Schema hochzukommen, welches für tatsächlich 
alle AVR gilt.

Und ja, mich nervt das auch. Mich nervt auch, dass in den Prozessoren 
manchmal verschiedene Konfigurationsflags in unterschiedlichen 
Prozessorregistern abgelegt sind und man beim Wechsel zwischen den 
Prozessoren höllisch aufpassen muss, was sich dann an dieser Stelle 
ändert und was nicht. Das wär mir viel lieber, wenn man diese 
Unterschiede auf Library-Ebene verstecken könnte.

Aber im Moment leb ich damit.

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Das Überarbeiten an sich ist nicht so sehr das Problem.
> Das Problem ist, mit einem Schema hochzukommen, welches für tatsächlich
> alle AVR gilt.
Da sähe ich das kleinere Problem. Gerade bei den Interrupts ist 
normalerweise eindeutig, wofür der IRQ gedacht ist. Dementsprechend 
könnte man einheitliche Namen vergeben. Z.B. könnte man den USI Start 
IRQ überall einheitlich USI_START_vect nennen

Bei den meisten Registern könnte man das auch machen. So würde ich dem 
UDR Register beim ATmega8 noch den Namen UDR0 geben. UCSRA würde zu 
UCSR0A usw.
>
> Und ja, mich nervt das auch. Mich nervt auch, dass in den Prozessoren
> manchmal verschiedene Konfigurationsflags in unterschiedlichen
> Prozessorregistern abgelegt sind und man beim Wechsel zwischen den
> Prozessoren höllisch aufpassen muss, was sich dann an dieser Stelle
> ändert und was nicht. Das wär mir viel lieber, wenn man diese
> Unterschiede auf Library-Ebene verstecken könnte.
Das mit den Bits in unterschiedlichen Registern ist das größte Problem. 
Ich wüsste da zwar eine Lösung, aber die will sicher keiner. Das würde 
dazu führen, das man zumindest die kritischen Bits im Programmcode 
einzeln setzen muss.

Ein Beispiel: Die Clock Select Bits von Timer0 beim Mega8 und Mega88. 
(die Defines natürlich in der entsprechenden ioxxx.h)
#if defined (__AVR_ATmega8__)
  #define T0CS_REG TCCR0
#elif defined (__AVR_ATmega88__)
  #define T0CS_REG TCCR0B
#endif

Um Clock Select zu setzten kann man dann schreiben:
 T0CS_REG |= (1<<CS0)|(1<<CS1);
>
> Aber im Moment leb ich damit.
Dir bleibt nicht viel anderes übrig

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab hier mal einige Defines für die UART0 gemacht:

Beitrag "AVR-GCC: UART mit FIFO"

Es sollte damit auf jedem AVR laufen.


Peter

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Ich hab hier mal einige Defines für die UART0 gemacht:
Das habe ich auch so ähnlich gemacht.
http://avr-gcc-library.svn.sourceforge.net/viewvc/...

Aber gerade das ist es ja, was ich vermeiden will. Dieses ganze 
"gepatche" in den einzelnen Header Dateien könnte man sparen, wenn das 
in den ioxxx.h schon für jeden Controller definiert wäre.

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

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:

> Das Überarbeiten an sich ist nicht so sehr das Problem.
> Das Problem ist, mit einem Schema hochzukommen, welches für tatsächlich
> alle AVR gilt.

...und das dann noch automatisch appliziert werden kann, zumindest
für alle künftigen AVRs.  Das Ziel ist es, dass man die ioxxx.h-
Dateien automatisch aus den XML-Beschreibungen generieren kann.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus Burrer schrieb:

> Um Clock Select zu setzten kann man dann schreiben:
>
 T0CS_REG |= (1<<CS0)|(1<<CS1);

Ich denke, das ist der falsche Weg. Als 'Anwendungsprogrammierer' möcht 
ich mich eigentlich um das ganze Bitgeschubse gar nicht mehr kümmern 
müssen. D.h. Wenn man das schon abstrahiert, dann sollte man da ruhig 
noch eine Stufe draufsetzen (In der Beziehung sollte man ruhig mal über 
den Tellerrand schauen und sich das mal bei BASCOM ansehen)
  ConfigPrecscaler( TIMER1, PRESCALE_1024 );

Ist doch viel einfacher zu lesen, zu analysieren und Fehler kann man 
auch weniger machen.

Das Problem ist nur: In den einzelnen Konfigurations-Registern tumnmeln 
sich die Bits ja nicht unbedingt themenbezogen. Ev. will man ja auch mal 
mehrere Bits in einem Rutsch beschreiben. Und das geht dann so nicht 
mehr.

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Markus Burrer schrieb:
>
>> Um Clock Select zu setzten kann man dann schreiben:
>>
 T0CS_REG |= (1<<CS0)|(1<<CS1);
>
> Ich denke, das ist der falsche Weg.
Nein, das wäre schon der richtige Weg. Es wäre eine einheitliche Basis 
für alles, was danach folgt.

> Als 'Anwendungsprogrammierer' möcht
> ich mich eigentlich um das ganze Bitgeschubse gar nicht mehr kümmern
> müssen. D.h. Wenn man das schon abstrahiert, dann sollte man da ruhig
> noch eine Stufe draufsetzen (In der Beziehung sollte man ruhig mal über
> den Tellerrand schauen und sich das mal bei BASCOM ansehen)
Das ist schon richtig. Aber so wie ich viele C Programmierer kennen 
wollen die das Bitgeschubse.
>
>
>   ConfigPrecscaler( TIMER1, PRESCALE_1024 );
> 
Das kann man dann ja auf Basis der geänderten ioxxx.h immer noch 
implementieren. Aber bei der Implementierung würden die geänderten 
ioxxx.h erheblich helfen.

> Das Problem ist nur: In den einzelnen Konfigurations-Registern tumnmeln
> sich die Bits ja nicht unbedingt themenbezogen. Ev. will man ja auch mal
> mehrere Bits in einem Rutsch beschreiben. Und das geht dann so nicht
> mehr.
Das ist das, was ich oben schon erwähnt habe.

>Ich wüsste da zwar eine Lösung, aber die will sicher keiner. Das würde
>dazu führen, das man zumindest die kritischen Bits im Programmcode
>einzeln setzen muss.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus Burrer schrieb:
> Karl heinz Buchegger schrieb:
>> Das Überarbeiten an sich ist nicht so sehr das Problem.
>> Das Problem ist, mit einem Schema hochzukommen, welches für tatsächlich
>> alle AVR gilt.
> Da sähe ich das kleinere Problem. Gerade bei den Interrupts ist
> normalerweise eindeutig, wofür der IRQ gedacht ist. Dementsprechend
> könnte man einheitliche Namen vergeben. Z.B. könnte man den USI Start
> IRQ überall einheitlich USI_START_vect nennen

Du siehst ein ganz großes Problem nicht:
Wie Jörg ja schon gesagt hat, ist es zielführend die IO-Headerdateien 
aus den von Atmel mitgelieferten XML Dateien zu erzeugen. Das wird ja 
nicht von Hand gemacht (was aus gutem Grunde verständlich ist).

Man könnte basierend auf diesen IO-Headerdateien eine andere Headerdatei 
mit vielen #if defined(...) aufsetzen.

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. schrieb:

> Du siehst ein ganz großes Problem nicht:
> Wie Jörg ja schon gesagt hat, ist es zielführend die IO-Headerdateien
> aus den von Atmel mitgelieferten XML Dateien zu erzeugen. Das wird ja
> nicht von Hand gemacht (was aus gutem Grunde verständlich ist).
Ich sehe das Problem schon. IMHO wird damit das eigentliche Problem aber 
nur verlagert. Von der avr-libc zum Programmierer. In der avr-libc 
müsste man die Änderung nur einmal machen, der Programmierer darf sich 
jedes mal damit rumschlagen. Das ist kurzsichtiges Denken.

> Man könnte basierend auf diesen IO-Headerdateien eine andere Headerdatei
> mit vielen #if defined(...) aufsetzen.
Fände ich auch unpraktisch.

Vielleicht könnte man ja einen Kompromiss finden. Kennt ihr die *.po 
Dateien, um Programmtexte in verschiedene Sprachen zu übersetzten? 
Vielleicht könnte man ja ein Tool schreiben, das die XML Dateien von 
Atmel importiert. In diesem Tool können dann Änderungen vorgenommen 
werden und anschließend wird alles als ioxxx.h exportiert. Wenn man das 
richtig anstellt, könnte man das auf verschiedene Leute verteilen und 
die Änderungen bleiben auch dann erhalten, wenn sich am original XML 
File etwas ändert. Also wirklich nur einmal auf die Hinterbeine stellen, 
einmal alles sauber aufräumen und in Zukunft hat man als Programmierer 
seine Ruhe.

Wenn sich ein paar Leute finden, wäre ich bei so einer Aktion dabei. 
Alleine mach ich das nicht.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach so, noch mal zum klar stellen. Für das Namenschaos kann der avr-gcc 
genau so wenig wie die avr-libc (Die Überschrift suggeriert das).
Das ist mehr oder weniger die "Schuld" von Atmel.

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. schrieb:
> Ach so, noch mal zum klar stellen. Für das Namenschaos kann der avr-gcc
> genau so wenig wie die avr-libc (Die Überschrift suggeriert das).
> Das ist mehr oder weniger die "Schuld" von Atmel.

Das weiß ich. Aber der avr-gcc reicht das Problem einfach 1:1 an den 
Programmierer weiter. Es wäre in meinen Augen ein erheblicher 
Fortschritt, bereits an dieser Stelle anzusetzen.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus Burrer schrieb:
> Das weiß ich. Aber der avr-gcc reicht das Problem einfach 1:1 an den
> Programmierer weiter. Es wäre in meinen Augen ein erheblicher
> Fortschritt, bereits an dieser Stelle anzusetzen.

Ja, das stimmt allerdings.

>> Du siehst ein ganz großes Problem nicht:
>> Wie Jörg ja schon gesagt hat, ist es zielführend die IO-Headerdateien
>> aus den von Atmel mitgelieferten XML Dateien zu erzeugen. Das wird ja
>> nicht von Hand gemacht (was aus gutem Grunde verständlich ist).
> Ich sehe das Problem schon. IMHO wird damit das eigentliche Problem aber
> nur verlagert. Von der avr-libc zum Programmierer. In der avr-libc
> müsste man die Änderung nur einmal machen, der Programmierer darf sich
> jedes mal damit rumschlagen. Das ist kurzsichtiges Denken.

Ja, klar. Da hast du voll und ganz Recht. Allerdings kann der Computer 
(und somit auch kein Script) "menschlich" denken.
Das Script kann nicht (okay, oder nur schwer) entscheiden, "Was ist 
jetzt der USI Start Interrupt?" und dann das entsprechende (genormte) 
Define dafür erzeugen.

Dafür müsste das Script irgendwie die XML Datei nach "USI", "Start" und 
"INT" parsen oder sowas in der Art, wenn ich das richtig sehe. Das 
dürfte auf längere Sicht hin schwer zu warten sein.
Das Script müsste also Eigenintelligenz haben und das hat es, meiner 
Auffassung nach, (im Moment) nicht. Es wandelt also tatsächlich nur die 
Namen in den XML Dateien irgendwie in Defines um (nach bestimmten 
Schemata).
Und das ist gewissermaßen auch gut so wie es ist.
Die Entwickler der avr-libc haben meiner Meinung nach andere Baustellen.

Außerdem wird Programmcode in der Regel sowieso nur für 1, 2 oder 3 
verschiedene MCUs erstellt. Da hält sich das rum-ge-#ifdef-e im Programm 
dann noch in Grenzen.

PS: Ach so, wenn sich da "externe" Leute dran setzen würden, würde ich 
es natürlich auch begrüßen, dass die Namen vereinheitlicht werden. Es 
ist aber kein Muss für mich.

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. schrieb:

> Ja, klar. Da hast du voll und ganz Recht. Allerdings kann der Computer
> (und somit auch kein Script) "menschlich" denken.
Deshalb ja der Vorschlag, ein Tool zu schreiben, das die beiden Aspekte 
kombiniert: Automatisierung und menschliche Intelligenz.

Klar, es macht erstmal viel Arbeit, aber es würde in der Folge viel 
Arbeit einsparen.

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal eine Frage am Rand: weiß jemand definitiv, unter welcher Lizenz die 
Partdescriptionfiles stehen? Dürfte man die in einem Projekt wie dem 
avr-gcc mit ausliefern?

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus Burrer schrieb:

> Es geht um das Durcheinander von Registernamen, Interrupts usw, das sich
> im laufe der Zeit gebildet hat. Hier ist zum größten Teil Atmel schuld.
> Nur ein Beispiel: der USI Start IRQ heißt einmal USI_START, einmal
> USI_STRT und einmal USI_STR.
>
> Jetzt ist die Frage, ob man da nicht mal was dagegen tun könnte. Z.B. in
> dem man für identische Interrupts oder Register einen einheitlichen
> Namen hinzufügt. So wie es derzeit ist muss man viel basteln, wenn man
> eine halbwegs universell verwendbare Funktion schreiben will.

Sehe ich nicht so.

Die Namen sind konsistent mit den Handbüchern, das ist die Hauptsache. 
Daß der Hersteller hier viel Phantasie bei der Auswahl der Namen hat, 
ist nun mal so...

Indem man noch mehr Bezeichner einführt, gewinnt man nix ausser 
Verwirrung. Oder wie der Lateiner sagt:
"entia non sunt multiplicanda praeter necessitatem"

:-)

Die alten Bezeichner will man nicht ändern aus Kompatibilitätsgründen.

Zudem sind die _vect-Namen der ISRs schon die zweite Staffel an 
ISR-Namen.

Wem diese zu uneinheitlich sind, kann doch z.B. verwenden:
 SIG_USI_START    statt USI_START_vect, USI_STRT_vect, USI_STR_vect 
 SIG_USI_OVERFLOW statt USI_OVERFLOW_vect, USI_OVL_vect
 SIG_EEPROM_READY statt EE_READY_vect, EE_RDY_vect, EEPROM_READY_vect 

Und schliesslich: wem diese Bezeichner zu altbacken sind, der hat 
schnell ein paar Defines zusammen:
#if defined(USI_STRT_vect) && !defined(SIG_USI_START)
#define SIG_USI_START SIG_USI_STRT
#endif

#if defined(USI_STR_vect) && !defined(SIG_USI_START)
#define SIG_USI_START SIG_USI_STR
#endif

Johann

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus Burrer schrieb:
> Mal eine Frage am Rand: weiß jemand definitiv, unter welcher Lizenz die
> Partdescriptionfiles stehen? Dürfte man die in einem Projekt wie dem
> avr-gcc mit ausliefern?

Selbst wenn das ginge... sowas hat in GCC nix zu suchen.

Johann

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:

> Indem man noch mehr Bezeichner einführt, gewinnt man nix ausser
> Verwirrung. Oder wie der Lateiner sagt:

> Die alten Bezeichner will man nicht ändern aus Kompatibilitätsgründen.

Ich will weder alte Bezeichner entfernen noch neue erfinden. Mir geht es 
lediglich um eine Vereinheitlichung.

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.