Ich musste gerade mit Erschrecken(!) feststellen, dass die AVR-LIBC komplette Pin/Port Definitionen einfach so klammheimlich umgestellt hat? Bei den *P AVRs heißt es zum Beispiel nicht mehr PC0, sondern PORTC0. Dabei steht in den Migration AppNotes von Atmel extra drin, dass, wenn man symbolische Namen benutzt hat, es keine Probleme bei der Migration geben soll. Na ganz toll. Ist das beabsichtigt?
PORTC0 ist der Namen, der das Bit 0 im Register PORTC beschreibt. Analog beschreibt PINC0 das Bit 0 im PINC-Register. avr-libc bietet noch zusätzliche ,generische' Aliasnamen wie PC0 an, deren Zweck es ist, dass man sie auf PORTC/PINC/DDRC gleichermaßen anwendet; diese sind jedoch nicht Bestandteil des Datenblatts. Die Intention ist aber, dass sie innerhalb von avr-libc für alle unterstützten AVRs zur Verfügung stehen, sofern es die entsprechenden Portbits gibt. Allerdings zäumt die Logik in <avr/portpins.h> das Pferd von hinten auf: dort werden nicht etwa zusätzlich PC0 etc. definiert, sofern PORTC0 in der gerätespezifischen Datei gefunden wurde, sondern genau andersrum: die gerätespezifische Datei muss den (nicht datenblattkonformen) Namen PC0 haben, damit <avr/portpins.h> dann zusätzlich noch PORTC0 daraus definiert. Dadurch kann es schon mal zu Ungereimtheiten kommen, die aber nicht beabsichtigt sind.
Wenn das so sein soll, dann ist aber irgendwas falsch gelaufen bei der "iom328p.h". Da sind nämlich (Im Gegensatz zum "iom168.h") keine "generischen" Definitionen ala PB0, PC0 etc. drin, sondern direkt die, die portpins.h erzeugt, bzw. erzeugen soll. Bzw. anders gesagt wird die "iomx8.h" dort nicht inkludiert. Ich benutze seit Jahren aber die kürzeren Definitionen und nicht die aus portpins.h.
Simon K. wrote: > Da sind nämlich (Im Gegensatz zum "iom168.h") keine "generischen" > Definitionen ala PB0, PC0 etc. drin, sondern direkt die, die portpins.h > erzeugt, bzw. erzeugen soll. Ja, ich schrob doch, dass portpins.h das Pferd von hinten aufzäumt. Da die neuen Header-Dateien im Gegensatz zu den alten nun automatisch aus den XML-Beschreibungen erzeugt werden, haben sie natürlich auch nur noch die Namen, die es im XML gibt (und das sollten auch die sein, die es im Datenblatt gibt). Man müsste also portpins.h umdrehen und alle alten Headerdateien entsprechend ebenfalls von den kurzen auf die langen Namen drehen. Oder aber, man macht die Logik in portpins.h aufwändiger, kann dann aber darauf verzichten, den alten Krempel anzufassen, ungefähr so:
1 | #if defined(PC0) && !defined(PORTC0)
|
2 | # define PORTC0 PC0
|
3 | #elif defined(PORTC0) && !defined(PC0)
|
4 | # define PC0 PORTC0
|
5 | #endif
|
Patches are welcome...
Das heißt alle Programme, die die kurzen Definitionen benutzen, können jetzt nicht mehr ohne Änderung kompiliert werden? Das finde ich gerade sehr fragwürdig. Wenn dann sollte man alle Headerdateien umstellen und in jeder Headerdatei einen weiteren Header einbinden, der einfach nur PA0 bis PX7 definiert, damit man da noch abwärtskompatibel ist.
Simon K. wrote:
> Wenn dann sollte man [...]
Ja, mach mal. Auch du fällst unter "man".
Ich habe aber keine Ahnung mit welchem Skript die Headerdateien erzeugt werden, also kann ich keine "neuartigen" Headerdateien erzeugen. Wenns dir natürlich was bringt, kann ich einen Header bauen, der nichts anderes als #if defined(PORTA) # if !defined(PA0) # define PA0 0 # endif ... #endif enthält. Viel mehr steckt ja nicht hinter den Definitionen. Das könnte man (ich) also in eine Headerdateien (von mir aus eben genportpins.h) schreiben, die dann von allen "neuartigen" IO Headern eingebunden wird. Ich hoffe doch, dass es noch möglich ist in das Skript eine #include Direktive einzubauen, die dann die neue genportpins.h inkludiert?
Simon K. wrote: > Ich habe aber keine Ahnung mit welchem Skript die Headerdateien erzeugt > werden, also kann ich keine "neuartigen" Headerdateien erzeugen. An dem würde ich nichts ändern. Der soll einfach weiterhin so werkeln, dass er datenblattkonforme Namen schreibt, statt irgendwas dazu zu erfinden. > Wenns dir natürlich was bringt, kann ich einen Header bauen, der nichts > anderes als > > #if defined(PORTA) > # if !defined(PA0) > # define PA0 0 > # endif > ... > #endif > > enthält. Das Prinzip hatte ich ja oben schon skizziert, wie man <avr/portpins.h> umbauen muss. Der Rest ist 'ne Fleißarbeit, vor allem muss es natürlich mal getestet werden. Das bedeutet eigentlich, dass man auch noch einen Testscript aufsetzen müsste. Aber das erste wäre wohl, erstmal einen Bug einzureichen dafür.
Ok, dann war meine Annahme falsch, dass da irgendetwas an der "API" umgebaut wird, sondern es ist einfach nur eine Neuigkeit hinter der Fassade, die man so als normaler Programmierer sieht. Und, dass die generischen Konstanten fehlen ist ein Bug (mehr oder weniger) und es hat sich noch niemand drum gekümmert ;) Jörg Wunsch wrote: > An dem würde ich nichts ändern. Der soll einfach weiterhin so > werkeln, dass er datenblattkonforme Namen schreibt, statt irgendwas > dazu zu erfinden. Das heißt, man müsste die alten Programme aber trotzdem ändern (um sie kompatibel auf die neuen Headerdateien zu machen). Nämlich um das #include von portpins.h einzubinden. Selbst das kann man nicht ins Skript übernehmen lassen? EDIT: Ich seh schon, portpins.h wird in io.h eingebunden. Dann ist alles klar. > Das Prinzip hatte ich ja oben schon skizziert, wie man <avr/portpins.h> > umbauen muss. Aaaah, ich hatte den #define Block gestern falsch gelesen und verstanden. Besonders den #elif Zweig. Jetzt ist alles klar. > Der Rest ist 'ne Fleißarbeit, vor allem muss es natürlich > mal getestet werden. Das bedeutet eigentlich, dass man auch noch einen > Testscript aufsetzen müsste. Testskript? Wie soll das funktionieren? Einfache .c Datei, die sich kompilieren lässt und ein paar #defines und #undefs beinhaltet um die neuen Defines zu testen? (Und die Defines auch anwendet im Programm, sonst meckert der Compiler ja nicht). > Aber das erste wäre wohl, erstmal einen Bug einzureichen dafür. Gute Idee.
Anbei mal die Version nach dem Muster wie du es vorgeschlagen hast. Damit lässt sich mein ursprüngliches Projekt sowohl für Mega168 als auch für Mega328P kompilieren. Mit dem Testskript kann ich dir aber (glaube ich) nicht helfen.
Simon K. wrote: > Anbei mal die Version nach dem Muster wie du es vorgeschlagen hast. > Damit lässt sich mein ursprüngliches Projekt sowohl für Mega168 als auch > für Mega328P kompilieren. Danke. Schön, dann ist ja zumindest die erste Verifikation da, dass das Teil auch das tut, was man von ihm erwartet. Ich würde dich bitten, einen Bugreport bei https://savannah.nongnu.org/bugs/?group=avr-libc aufzumachen und das File dann dort als Attachment zu hinterlassen. > Mit dem Testskript kann ich dir aber (glaube ich) nicht helfen. Damit kann ich wohl leben. ;-) Mach ich dann selbst. Ja, im Prinzip nur ein Programm, das sich nachher noch fehlerfrei compilieren lässt. Normalerweise werden die Programme aber noch für einen ATmega8 und einen ATmega128 simuliert, der Simulator kennt jedoch keinen der neuen Controller, bei denen das ursprüngliche Problem auftrat. Da muss ich mal gucken, wie man ihm das dann beibringen würde, denn im Prinzip läuft's hier ja wirklich nur auf einen Compile-Test hinaus.
Jörg Wunsch wrote: > Simon K. wrote: >> Anbei mal die Version nach dem Muster wie du es vorgeschlagen hast. >> Damit lässt sich mein ursprüngliches Projekt sowohl für Mega168 als auch >> für Mega328P kompilieren. > > Danke. Schön, dann ist ja zumindest die erste Verifikation da, dass > das Teil auch das tut, was man von ihm erwartet. > > Ich würde dich bitten, einen Bugreport bei > > https://savannah.nongnu.org/bugs/?group=avr-libc > > aufzumachen und das File dann dort als Attachment zu hinterlassen. Feddich. https://savannah.nongnu.org/bugs/index.php?25930
Simon K. wrote:
> Feddich.
Danke sehr, hab' die Mails gesehen. Nun, dann guck ich mir mal die
testsuite an.
Jörg Wunsch wrote: > Simon K. wrote: > >> Feddich. > > Danke sehr, hab' die Mails gesehen. Nun, dann guck ich mir mal die > testsuite an. Danke sehr ebenfalls! Ich würde auch mehr an der avr-libc rumbasteln, wenn das nicht alles böhmische Dörfer wären. Aber genau das Problem haben ja die meisten hier, die helfen wollen.
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.