Forum: Compiler & IDEs Probleme mit io.h


von InTheSummer (Gast)


Lesenswert?

Hallo,

bin momentan am verzweifeln. Wenn ich diese zwei includes (Atmel Studio 
6) nutze:

#include <avr/io.h
#include <avr/wdt.h>

dann kann ich z.B. mit Rechtsklick "Goto Implementation" auf die wdt.h 
zugreifen (öffnet sich also). Bei der io.h funktioniert das nicht.

Der Compiler scheint sie zwar zu finden, denn er meckert nicht, aber es 
scheint trotzdem irgendwas nicht zu stimmen, denn sämtliche Zugriffe auf 
Register verursachen einen Fehler beim kompilieren - "xxx undeclared"

Die beiden haben ja aber den gleichen Includepfad, wdt.h findet er auch, 
also müssten die Includepfade doch schon mal stimmen, oder?

Bin für jeden Tipp dankbar!

von Stefan E. (sternst)


Lesenswert?

InTheSummer schrieb:
> Der Compiler scheint sie zwar zu finden, denn er meckert nicht, aber es
> scheint trotzdem irgendwas nicht zu stimmen, denn sämtliche Zugriffe auf
> Register verursachen einen Fehler beim kompilieren - "xxx undeclared"

Falschen Controller eingestellt?

von Karl H. (kbuchegg)


Lesenswert?

<avr/io.h>

ist nur ein Sammelbecken, aus dem je nach eingestelltem Controller in 
das tatsächlich zu benutzenden ioxxx.h verzweigt wird. Wenn also die 
Registernamen nicht gefunden werden, dann ist höchst wahrscheinlich in 
den Project-Settings der falsche Controller eingestellt.

von InTheSummer (Gast)


Lesenswert?

P.S.: Was Atmel angeht, bin ich noch relativ am Anfang, habe also nicht 
viel Erfahrung, auch nicht mit der Entwicklungsumgebung. Dies ist mein 
erster Versuch, Code wirklich komplett selbst zu schreiben, habe bisher 
eben einige Beispiele durchgearbeitet. (Habe vorher nur mit 
PICs/Microchip gearbeitet)

von InTheSummer (Gast)


Lesenswert?

Hallo und danke für die schnelle Antwort!

In den Projekteigenschaften unter "Device" steht der richtige uC drin, 
habe das gerade eben nochmal überprüft.

Hatte auch schon versucht, direkt die passende Header-Datei für den uC 
zu includieren (also die, die mittels io.h includiert wird) das brachte 
aber leider auch keinen Erfolg.

von Stefan E. (sternst)


Lesenswert?

InTheSummer schrieb:
> In den Projekteigenschaften unter "Device" steht der richtige uC drin,
> habe das gerade eben nochmal überprüft.

Dann rücke mal konkrete Details raus:
welcher Controller ist das, und für welche Register kommen die 
Fehlermeldungen (am besten Copy&Paste von ein paar der Fehlermeldungen).

von Oliver S. (oliverso)


Lesenswert?

In deiner Entwicklunsgumgebung sollte während es Kompilierens auch der 
Compileraufruf angezeigt werden (fängt mit "avr-gcc" an):

Was genau steht denn in dieser Zeile? Kopier die doch mal hier rein.

Oliver

von InTheSummer (Gast)


Lesenswert?

Stefan Ernst schrieb:
> Dann rücke mal konkrete Details raus:
> welcher Controller ist das, und für welche Register kommen die
> Fehlermeldungen (am besten Copy&Paste von ein paar der Fehlermeldungen).

Ich nutze einen AT90USB1287 (auf AT90USBKEY).

Nun ist mir gerade noch was aufgefallen...die Registernamen werden im 
Editor lila (oder was auch immer das für eine Farbe ist) eingefärbt. 
Heißt, er erkennt sie ja doch irgendwie als richtig...oder? Wenn ich 
nämlich z.B. irgendeinen Namen erfinde, den es nicht wirklich als 
Register gibt, färbt er nicht ein, bleibt also schwarz.

Fehlermeldung wäre z.B.:

C:\Users\...\Test.c(139,23): 'UBRR' undeclared (first use in this 
function)
C:\Users\...\Test.c(149,11): 'TXEN' undeclared (first use in this 
function)
C:\Users\...\Test.c(149,23): 'RXEN' undeclared (first use in this 
function)




Oliver S. schrieb:
> In deiner Entwicklunsgumgebung sollte während es Kompilierens auch der
> Compileraufruf angezeigt werden (fängt mit "avr-gcc" an):

Meinst du das hier?:
C:\Program Files\Atmel\Atmel Studio 6.0\make\make.exe "Test.o"
    Building file: .././Test.c
    Invoking: AVR/GNU C Compiler : (AVR_8_bit_GNU_Toolchain_3.4.0_663) 
4.6.2
    "C:\Program Files\Atmel\Atmel Studio 
6.0\extensions\Atmel\AVRGCC\3.4.0.65\AVRToolchain\bin\avr-gcc.exe" 
-funsigned-char -funsigned-bitfields -O1 -fpack-struct -fshort-enums -g2 
-Wall -c -std=gnu99 -MD -MP -MF "Test.d" -MT"Test.d" -MT"Test.o" 
-mmcu=at90usb1287   -o"Test.o" ".././Test.c"

von g457 (Gast)


Lesenswert?

> 'UBRR' undeclared (first use in this function)
> 'TXEN' undeclared (first use in this function)
> 'RXEN' undeclared (first use in this function)

..müssten das nicht UBRR0, TXEN0 und RXEN0 sein?

von g457 (Gast)


Lesenswert?

..kleine Korrektur: ist sogar UBRR1, TXEN1 und RXEN1 - warum fangen die 
nicht bei 0 an?

</ingrid>

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


Lesenswert?

g457 schrieb:
> ..kleine Korrektur: ist sogar UBRR1, TXEN1 und RXEN1 - warum fangen die
> nicht bei 0 an?

Weil die UART0 offenbar zugunsten des USB-Makros rausgeflogen ist.

Das Ganze ist doch letztlich ein modifizierter ATmega1281.

von InTheSummer (Gast)


Lesenswert?

g457 schrieb:
> ..kleine Korrektur: ist sogar UBRR1, TXEN1 und RXEN1 - warum fangen die
> nicht bei 0 an?
>
> </ingrid>

Keine Ahnung warum das so ist. Sind aber korrekt im Code...der Compiler 
scheint nur "allgemein" am nicht bekannten(?) Register zu meckern.

Habe dort z.B. so etwas:
1
out((uint8_t)baud, UBRR1);

Keine Ahnung was da nicht passt...wahrscheinlich habe ich nur irgendwo 
eine Kleinigkeit übersehen/nicht beachtet.

von holger (Gast)


Lesenswert?

>Falschen Controller eingestellt?

Nö, Sourcecode für uralten Controller versucht auf neuem
Controller zum laufen zu bringen.

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.