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.
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
>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
1
#define INT0_vect _Vector(1)
, und damit ist es überhaupt kein Problem, sich da selber
vereinheitlichte Namen auszudenken.
Musst du einfach nur machen.
Oliver
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
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.
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)
1
#if defined (__AVR_ATmega8__)
2
#define T0CS_REG TCCR0
3
#elif defined (__AVR_ATmega88__)
4
#define T0CS_REG TCCR0B
5
#endif
Um Clock Select zu setzten kann man dann schreiben:
1
T0CS_REG|=(1<<CS0)|(1<<CS1);
>> Aber im Moment leb ich damit.
Dir bleibt nicht viel anderes übrig
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.
Markus Burrer schrieb:
> Um Clock Select zu setzten kann man dann schreiben:>
1
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)
1
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.
Karl heinz Buchegger schrieb:
> Markus Burrer schrieb:>>> Um Clock Select zu setzten kann man dann schreiben:>>
1
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.
>>
1
>ConfigPrecscaler(TIMER1,PRESCALE_1024);
2
>
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.
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.
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.
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.
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.
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.
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.
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?
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:
1
"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:
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
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.
Thread beobachten
Seitenaufteilung abschalten