Macros - Verständnisproblem.

[Christian Schmidt (Gast)]

Hallo zusammen,

ich hätte eine Frage zu folgendem Codeabschnitt:

#if F_CPU == 16000000UL
uint8_t CANBT_1000K[] EEMEM  = {0x00, 0x0C, 0x37};
uint8_t CANBT_500K[]  EEMEM  = {0x02, 0x0C, 0x37};
uint8_t CANBT_250K[] EEMEM  = {0x06, 0x0C, 0x37};
uint8_t CANBT_200K[]  EEMEM  = {0x08, 0x0C, 0x37};
uint8_t CANBT_125K[] EEMEM  = {0x0E, 0x0C, 0x37};
uint8_t CANBT_100K[]  EEMEM  = {0x12, 0x0C, 0x37};
#elif F_CPU == 12000000UL
uint8_t CANBT_1000K[] EEMEM  = {0x00, 0x08, 0x25};
uint8_t CANBT_500K[]  EEMEM  = {0x02, 0x08, 0x25};
uint8_t CANBT_250K[] EEMEM  = {0x04, 0x0C, 0x37};
uint8_t CANBT_200K[]  EEMEM  = {0x04, 0x0E, 0x4B};
uint8_t CANBT_125K[] EEMEM  = {0x0A, 0x0C, 0x37};
uint8_t CANBT_100K[]  EEMEM  = {0x0A, 0x0E, 0x4B};
#else
#error "F_CPU undefined!"
#endif

Ich erhalte in Atmelstudio 6 die Fehlermeldung, die CANBT_xxxx seinen 
mehrfach definiert, obwohl F_CPU global auf bspw. 1200000UL gesetzt 
wurde. Irgendwie verstehe ich es gerade nicht, vielleicht hat ja jemand 
eine Idee...

schöne Grüße

Chris

[Yalu X. (yalu) (Moderator)]

Der Code-Abschnitt an sich ist in Ordnung, aber vielleicht includest du 
ihn versehentlich zweimal (weil bspw. die Guards fehlen).

[Christian Schmidt (Gast)]

Hi,

Danke für die schnelle Antwort. Habe gerade selbst herausgefunden, dass 
es an 2 Stellen als include steht, allerdings habe ich die Guards in der 
Header-Datei. Nehme ich das include an einer der beiden Stellen weg, 
funktionierts einwandfrei...werde mal weiter suchen...


schöne Grüße

Chris

[Dr. Sommer (Gast)]

Dann sind die Guards vermurkst, oder du #undef'inierst sie irgendwo 
wieder

[Johann L. (gjlayde)]

Kommt die Fehlermeldung vom Compiler oder vom Linker?

Compiler --> Mehrfachincludein einer Datei

Linker --> Includes in unterschiedlichen C-Dateien

[mitleser (Gast)]

>#elif F_CPU == 12000000UL

Bin mir jetzt nicht sicher, aber ,muss das nicht #elsif heisen ??

[Mr.T (Gast)]

mitleser schrieb:
>>#elif F_CPU == 12000000UL
>
> Bin mir jetzt nicht sicher, aber ,muss das nicht #elsif heisen ??

Nein.

[Christian Schmidt (Gast)]

Hallo,

das #elif ist korrekt, ich komme aber auch desöfteren mit der 
VHDL-Syntax durcheinander, obwohl es an der Stelle wirklich zwei Paar 
Schuhe sind :)

Also der Fehler wird durch den Linker erzeugt. die Guards sind korrekt 
und das steuernde #define wird auch nirgends undefined... Ich muss die 
Datei in 2 C-Files includieren, sonst beschwert sich wiederum der 
Compiler, dass er Variablen etc., die in dem Header deklariert sind, 
nicht kennt. Eigentlich sollte das mit Hilfe der Guards ja gelöst sein, 
man wendet sie ja an, um mehrfachinkludieren zu verhindern...

schöne Grüße


Chris

[Oliver (Gast)]

Nein. Die guards verhindern nur, daß innerhalb einer .c-Datei eine 
include-Datei mehrfach inkludiert wird.

Du aber legst die Variablen in einer .h-Datei an, daher seiht der linker 
die in jeder deiner .c-Dateien, und beschwert sich zu Recht.

Die Definition von globalen Variablen gehört daher grundsätzlich in eine 
.C-DAtei. In den headern darf dazu nur eine extern-Deklaration stehen.

Oliver

[Matthias L. (matze88)]

Wobei in diesem Fall vermutlich sowieso static Arrays erwünscht waren - 
diese dürfen dann auch im Header definiert werden.

[Christian Schmidt (Gast)]

Oliver schrieb:
> Nein. Die guards verhindern nur, daß innerhalb einer .c-Datei eine
> include-Datei mehrfach inkludiert wird.

Wooop, korrekt! Habe jetzt den Teil mit den EEPROM_Daten in eine 
einzelne Header ausgelagert, der Rest in der alten Headerdatei sind nur 
defines.

Danke für eure Hilfe xD

schöne Grüße

Chris

[Läubi .. (laeubi)]

Im übrigen ist deine Fehlermeldung, im Fall das F_CPU nicht deinen 
Vorstellungen entspricht, irreführend.