Wofür #define PA0_PORT PORTADC?

[Np R. (samweis)]

Hallo zusammen,

da ich zu vergesslich bin, mir die Bits für ADPS[2:0], REFS[2:0] und 
MUX[4:0] zu merken
und zu faul, sie jeweils in den Datenblättern nachzuschauen, hatte ich 
die Idee, meine adc.h so aufzupeppen, dass diese Parameter 
hardwareunabhängig (halb-)automatisch gesetzt werden.
So wollte ich z.B. für ADMUX einfach Bitmasken als ADC0 bis ADC11 
#definieren.

Nun stelle ich fest, dass ADC0-ADC10 sowie PORTADC, PINADC und DDRADC 
bereits in den hardware-spezifischen header-Dateien zugewiesen werden.
Z.B. in avr/iotn861a.h:

#define PA0_DDR   DDRADC
#define PA0_PORT  PORTADC
#define PA0_PIN   PINADC
#define PA0_BIT   ADC0

Dabei sind PORTADC, ADC0 usw. nirgendwo definiert, d.h. es werden nur 
die Namen blockiert, aber es ist "nix drin".

Welchen Sinn hat das?
Kann mir einer von Euch Cracks das leicht verständlich erklären oder 
ggfs. ein Anwendungsbeispiel geben?

P.S.: Betrifft avr-libc 1.8.0

[Jörg W. (dl8dtl) (Moderator)]

np rn schrieb:
> Welchen Sinn hat das?

Gar keinen.  Die Files sind offenbar von Atmel mit einem Script
generiert worden, der schlicht und ergreifend Unsinn produziert
hat.

Bitte schreib' einen Bugreport:

https://savannah.nongnu.org/bugs/?func=additem&group=avr-libc

Es wäre nett, wenn du im Bugreport alle Files aufzählen könntest, die
davon betroffen sind.

[Jörg W. (dl8dtl) (Moderator)]

Jörg Wunsch schrieb:
> Bitte schreib' einen Bugreport:

Danke! ;-)

[Np R. (samweis)]

Hab' ich soeben gemacht - aber wie ich sehe, bist Du mit dem 
Bug-Tracking-System direkt verkabelt ;-)

Noch eine Frage, wenn ich schon mal Dich selbst erreiche:

Wäre es nicht schick, wenn in den Headern ADCn als ADMUX bits definiert 
würden?
z.B.
#define ADC1 1
...
#define ADC10 10

Man könnte dann einfach mit #ifdef ADC10 abfragen, ob der Kanal 
existiert, oder hardware-unabhängige Funktionen definieren wie
uint16_t readADC(uint8_t channel)
und als channel ADC10 mitgeben.

Oder wenn ADC_TMP auf den Kanal des internen Temperatur-Sensors zeigen 
würde... (beim ATtiny24a ADC8, beim ATtiny261a ADC11, beim ATtiny25 ADC4 
usw...).

Oh, ich komme richtig in Fahrt ;-)
Vielleicht sollte ich besser einen neuen Thread aufmachen.

[Jörg W. (dl8dtl) (Moderator)]

np rn schrieb:
> Wäre es nicht schick, wenn in den Headern ADCn als ADMUX bits definiert
> würden?
> z.B.
> #define ADC1 1
> ...
> #define ADC10 10

Naja, für die einzelnen Single-Ended-Kanäle mag das noch einigermaßen
angehen, aber wenn du bei differenziellen Kanälen und dann optional
auch Vorverstärkern bist, dürfte das schnell reichlich unübersichtlich
werden.

Die IO-Headerfiles sollen keine "über-alles-Abstraktion" liefern,
sondern deren Hauptaufgabe ist es, die in den Datenblättern genannten
Register und Registerbits in C (und Assembler) verfügbar zu machen.

Anders wäre das für Headerfiles, die unter <util/...> liegen, wobei
vermutlich (kenne ich nicht ernsthaft) Atmels Software Foundation
Library da noch einige Schritte weitergeht.

[Np R. (samweis)]

Jörg Wunsch schrieb:
> wenn du bei differenziellen Kanälen und dann optional
> auch Vorverstärkern bist, dürfte das schnell reichlich unübersichtlich
> werden.
Klar - irgendwann bleibt einem der wiederhote Blick ins Datenblatt nicht 
erspart. Aber für einfache Routine-Tasks?

Einen gewissen Drang zur Abstraktion scheint es ja bei vielen zu geben. 
Wenn ich nach avr + adc_read google, dann finde ich einen Haufen ähnlich 
gestrickter Funktionen.
Auch für µc-Newbies, die sich an die "Bitschubserei" noch nicht gewöhnt 
haben, wäre es eine Hilfe.

> Anders wäre das für Headerfiles, die unter <util/...> liegen, wobei
Naja, gerne auch unter util/. ;-)

> vermutlich (kenne ich nicht ernsthaft) Atmels Software Foundation
> Library da noch einige Schritte weitergeht.
Danke! Guter Tipp. Das ASF werde ich mir gleich mal anschauen (ATtinies 
scheinen aber auf den ersten Blick nicht abgedeckt zu sein.)

[Achim Kraus (Gast)]

Hallo,

wurde das Problem inzwischen behoben? Bei meinem AVR8-GCC (3.4.2.1002, 
vom AStudio 6.1) ist er noch drin. Gibt es da Updates?

(Hm, ist zwar eine neue Frage, aber in einem neuen Beitrag würde sie den 
Kontext verlieren.)