Forum: Compiler & IDEs ADCW - Compiler meldet Fehler


von hal (Gast)


Lesenswert?

Hallo,
in meinen ATmega128 Projekt habe ich folgende Routine:
1
uint16_t read_adc(uint8_t adc_input)
2
{
3
  ADMUX = (ADMUX & 0b11110000)|(adc_input & 0b00001111);
4
  
5
  ADCSRA |= (1<<ADSC);
6
  while(ADCSRA & (1<<ADSC));
7
  
8
  return ADCW;
9
  
10
}

Das Ding hat immer funktioniert. Jetzt meldet der Compiler allerdings 
folgenden Fehler:
1
Error  1  attempt to use poisoned "ADCW"  Y:\...\XXX.c  401  9  XXX
2
Error  2  'ADCW' undeclared (first use in this function)  Y:\...\XXX.c  401  9  XXX

Ich verstehe leider nur Bahnhof. Weiß jemand Rat?

Gruß
hal

von Magnus M. (magnetus) Benutzerseite


Lesenswert?

Der ATmeg128 hat kein Register mit dem Namen "ADCW".

von Karl H. (kbuchegg)


Lesenswert?

hal schrieb:

> Ich verstehe leider nur Bahnhof. Weiß jemand Rat?

Autsch. Wasn da passiert?
Sieht so aus, als ob der Compiler da irgendwas verwechselt.


Kontrollier mal die Projekteinstellungen. Ist da sicher ein Mega128 
eingestellt? Hast du sicher avr/io.h inkludiert (und keines der 
speziellen io-Prozessor Files))

Welche includes hast du sonst noch?

von hal (Gast)


Lesenswert?

Ja, stimmt! Hat aber bisher immer funktioniert? Das Register heißt ADC.

In der iom128.h hab ich folgendes gefunden.
1
/* ADC Data Register */
2
#define ADCW      _SFR_IO16(0x04) /* for backwards compatibility */
3
#ifndef __ASSEMBLER__
4
#define ADC       _SFR_IO16(0x04)
5
#endif
6
#define ADCL      _SFR_IO8(0x04)
7
#define ADCH      _SFR_IO8(0x05)

danke.

gruß
hal

von Karl H. (kbuchegg)


Lesenswert?

Magnus M. schrieb:
> Der ATmeg128 hat kein Register mit dem Namen "ADCW".

Aber der Compiler weiß, was er damit machen muss.
Zumindest die vorhergehenden Versionen wussten, dass mit ADCW das 
Registerpärchen ADCH und ADCL gemeint ist.


Das das Teil ADCW heißt, hat historische Gründe, damit das ganze nicht 
mit der µC-Assembler Instruktion ADC (Add with Carry) verwechselt wird.
(weil die Include Files auch beim Assembler benutzt wurden)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Lösch die Zeile
1
#pragma GCC poison ADCW

aus dem Header.  Da war Eric etwas vorschnell.

von Michael B. (planlessmichi)


Angehängte Dateien:

Lesenswert?

Ich bin mit dem neuen AVR-Studio jetzt eben über die gleichen Fehler 
gestoßen und die Google-Suche schickte mich dann auf den Thread hier.
Danke für den Tipp mit dem Löschen in der iom128.h

Jörg Wunsch schrieb:
> Lösch die Zeile
> #pragma GCC poison ADCW


Wenn ich das include-File aber richtig verstehe, wurde das absichtlich 
in einen Preprozessor-Block gebunden, der mit 
"__AVR_LIBC_DEPRECATED_ENABLE__" ein- und ausgeschaltet werden kann...
Ich habe bei mir jetzt in den Projekteinstellungen dieses define gesetzt 
und denke, dass das der sauberer Weg sein sollte.
Bei einem Update der AVR-Sourcen würde man ja sonst die gelöschten 
Zeilen wieder mit "aktivieren" und das Problem ist wieder da.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Michael B. schrieb:
> Ich habe bei mir jetzt in den Projekteinstellungen dieses define gesetzt
> und denke, dass das der sauberer Weg sein sollte.

Nein, eigentlich ist das Löschen dieser Zeile schon der saubere
Weg.  Die hat nur aus Versehen das #pragma poison bekommen, weil
da oben bei der Definition stand "for backwards compatibility".
Das war aber ein uralter Kommentar, und wir (die avr-libc-Leute)
sind uns einig, dass ADCW durchweg unterstützt werden soll.

Im SVN sind beides (der alte Kommentar und das #pragma) bereits
entfernt, in der nächsten avr-libc-Version wird das also korrigiert
sein.

von Michael B. (planlessmichi)


Lesenswert?

Ah, o.k.; hoffentlich bekommen die ATMEL-Leute das dann auch bald mit 
:-)
Ich habe nämlich gerade eben die derzeit aktuellste Studio6-Version 
(6.0.1996 Service Pack 2) heruntergeladen und auf meinem frisch 
aufgesetztem Rechner installiert. Und plötzlich konnte ich das Projekt, 
das vor zwei Wochen auf dem alten Rechner mit WinAVR noch einwandfrei 
compilierbar war, nicht mehr übersetzen.
Ich hatte allerdings diese poison-Meldung bei einer SIG_OUTPUT_COMPARE1A 
ISR...

Also verstehe ich das richtig, dass man vorsichtshalber alle pragma 
poison Zeilen löschen sollte? Falls ja: Wo ist der Unterschied zu dem 
angesprochenem define?

von Marius W. (mw1987)


Lesenswert?

Michael B. schrieb:
> Ich hatte allerdings diese poison-Meldung bei einer SIG_OUTPUT_COMPARE1A
> ISR...

Die SIG_*-Bezeichnungen sind deprecated. Vielleicht ein Wink mit dem 
Zaunpfahl die mal umzubenennen...

Gruß
Marius

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Marius Wensing schrieb:
> Die SIG_*-Bezeichnungen sind deprecated.

Und dies bereits seit vielen Jahren.

Michael B. schrieb:
> Also verstehe ich das richtig, dass man vorsichtshalber alle pragma
> poison Zeilen löschen sollte?

Keineswegs.  Ausschließlich diese eine in iom128.h.

Bitte 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
Noch kein Account? Hier anmelden.