mikrocontroller.net

Forum: Compiler & IDEs ATmegaXXXP Versionen Portdefinitionen anders?


Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

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

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

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

Bewertung
0 lesenswert
nicht lesenswert
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:
#if defined(PC0) && !defined(PORTC0)
#  define PORTC0 PC0
#elif defined(PORTC0) && !defined(PC0)
#  define PC0 PORTC0
#endif

Patches are welcome...

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

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

Bewertung
0 lesenswert
nicht lesenswert
Simon K. wrote:

> Wenn dann sollte man [...]

Ja, mach mal.  Auch du fällst unter "man".

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

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

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Simon K. (simon) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

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

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

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

Bewertung
0 lesenswert
nicht lesenswert
Simon K. wrote:

> Feddich.

Danke sehr, hab' die Mails gesehen.  Nun, dann guck ich mir mal die
testsuite an.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

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.