triviales Problem mit include - aber ich sehe es nicht

[avus (Gast)]

Moin Inkludierprofis,

ich frage mich gerade, ob ich völlig verblödet bin. Seit 1h versuche 
ich, einem C-File beizubringen, daß in der "main.h" Deklarationen und 
Definitionen stehen.
Vielleicht seht ihr den Baum, ich sehe inzwischen nicht mal mehr den 
Wald.

Die "main.h" sieht so aus:

#include "stm32f4xx.h"
#define TIME 0x0001
#define TOUCH 0x0002
#define BUTTON 0x0004
#define UART2RX 0x0008
#define UART2RDY 0x0010
void wait(uint16_t timeout);
extern volatile uint16_t flag;
extern volatile uint16_t deltim;

Im Sourcefile "main.c", das "main.h" inkludiert, werden alle Variablen, 
Funktionen, Definitionen und Deklarationen akzeptiert. In "main.c" sind 
die Variablen "flag" und "deltim" definiert:
"main.c":

volatile uint16_t deltim=0; //Hilfsvariable, wird im 10ms-Abstand runtergezählt
volatile uint16_t flag=0;

In einem zweiten Sourcefile, das ebenfalls die "main.h" inkludiert, wird 
NICHTS erkannt. Da wird an TIME, an wait() und an flag etc. 
rumgemeckert.
Also z.B. Fehlermeldung =  error: 'TIME' undeclared (first use in this 
function)
Obwohl "main.h" inkludiert ist. Der Sch**** tut so, als wäre diese Zeile 
#include "main.h" gar nicht da.

Ich benutze die CooCox IDE 1.75 mit arm-gcc-compiler.
Noch ärgerlicher: In meinem anderen, viel größeren Project funktioniert 
dieser Quark bestens - und von diesem habe ich das Zeug einfach kopiert.
Das gibt's doch nicht!
Kann es sein, daß es an irgendwelchen Compilereinstellungen liegt, die 
im anderen Projekt anders sind? Aber eine simple ".h"-Datei zu 
inkludieren, dürfte doch wohl nicht davon abhängen?!

[lalala (Gast)]

ohne Deine 2te Datei zu sehen können wir nur raten. 1ter Rateversuch : 
Deine Datei includiert ein anderes main.h (da im anderen Verzeichnis)

[avus (Gast)]

Verstehe, hier die 2. Source ("stm32_camera.c") stark verkürzt

#include "main.h"
void Init(void);
//--------------------------------------------------------------
void Init(void)
{
  uint8_t i;
  if (flag & TIME) i++;
}

Fehlermeldung:
D:\stm32_camera.c: In function 'Init':
       [cc]   if (flag & TIME) i++;
       [cc] D:\stm32_camera.c:8:6: error: 'flag' undeclared (first use 
in this function)
       [cc]       ^
       [cc] D:\stm32_camera.c:8:6: note: each undeclared identifier is 
reported only once for each function it appears in
       [cc] D:\stm32_camera.c:8:13: error: 'TIME' undeclared (first use 
in this function)
       [cc]   if (flag & TIME) i++;
       [cc]              ^


Was mich sehr irritiert: Wenn ich z.B. im obigen File "TIME" und "open 
declaration" (in CooCox) anklicke, verweist er ganz richtig auf die 
Definition von "TIME" in der "main.h".
Ein falsches "main.h" ist weder im realen Ordner noch im Projektordner 
drin... vielleicht kann man im Compiler die Option anklicken, daß er für 
Leute mit IQ<20 optimiert? ;)
Also echt schleierhaft. Ich hab den Rechner auch schon neu gestartet, 
weil CooCox manchmal zickt, aber - no change.

[avus (Gast)]

P.s.: Optimierung ist ausgeschaltet (None -O0)

[Oliver S. (oliverso)]

Der gezeigte Code ist in Ordnung.

Entweder, wie schon geschrieben, wird da ein falsches main.h inkludiert, 
oder in der Datei "stm32f4xx.h" ist was kaputt, was sich auf den Inhalt 
von main.h auswirkt.

gcc kennt die Compileroption -E. Damit bekommst du die Datei nach dem 
Preprozessorlauf zu sehen. Da sollte man erkennen können , was falsch 
läuft.

Oliver

[Karl H. (kbuchegg)]

avus schrieb:

> Was mich sehr irritiert: Wenn ich z.B. im obigen File "TIME" und "open
> declaration" (in CooCox) anklicke, verweist er ganz richtig auf die
> Definition von "TIME" in der "main.h".

Danach würde ich nicht gehen.
Das eine ist die IDE und das andere ist der Compiler. Wie deine IDE die 
Files findet hat nichts damit zu tun, wie der Compiler das macht. Deine 
IDE kann dir nach wie vor die richtige main.h zeigen, das heißt noch 
lange nicht, dass der Compiler beim #include auf dasselbe File stösst.


Sind alle Files im selben Verzeichnis?


Du kannst mal folgendes probieren:
bau einen absichtlichen Fehler in main.h ein.
Wenn du dann stm32_camera.c compilierst musst du diesen forcierten 
Fehler sehen können. Wenn nicht, dann hat der Compiler ein anderes 
main.h includiert. Wo immer er das auch her hat.

[Dr. Sommer (Gast)]

Aufruf "gcc -v ..." hilft auch.

[avus (Gast)]

-E läuft gerade noch durch ;)

[avus (Gast)]

Erstmal herzlichen Danke euch allen!

Die Files sind alle im selben Ordner ("workspace\Test"), allerdings 
befinden sich auch noch andere Ordner mit anderen Projekten 
("workspace\Test2") etc.
(Ich hatte diese Ordnernamen aus den Fehlermeldungen oben entfernt, aus 
privaten Gründen).

Sowohl mit -E als auch mit -v habe ich gesehen, daß an einer Stelle 
(kurz bevor "stm32_camera.c" kompiliert wird, auf ein main.h aus einem 
anderen realen Ordner zugegriffen wird.

D.h., die main.c greift auf das korrekte main.h zurück, wie auch noch 4 
weitere Sourcen. Nur die "stm32_camera.c" greift auf ein benachbartes 
"main.h" zu - Nun muß ich mal kucken, wie ich dem das abgewöhne.

Das ist ja irre g. Hab ich noch nie erlebt ;))
Danke nochmal für eure schnelle Hilfe, das sollte ich jetzt vollends 
allein knacken können.

[Karl H. (kbuchegg)]

avus schrieb:
> Erstmal herzlichen Danke euch allen!
>
> Die Files sind alle im selben Ordner ("workspace\Test"), allerdings
> befinden sich auch noch andere Ordner mit anderen Projekten
> ("workspace\Test2") etc.
> (Ich hatte diese Ordnernamen aus den Fehlermeldungen oben entfernt, aus
> privaten Gründen).

d.h. workspace ist auch nicht der richtige Name?

IM richtigen Pfad-Namen kommt sowas vor wie

d:\users\karl heinz\dokumente und einstellungen\test

dann lass dir gesagt sein, dass es immer noch extrem unklug ist, mit 
Pfadnamen zu operieren, in denen Leerezeichen und Sonderzeichen oder 
Umlaute vorkommen. Beschränke dich in deinen Entwicklungsverzeichnissen 
auf Buchstaben (Gross und Klein), Ziffern, Unterstrich und vielleicht 
noch das ein oder andere Sonderzeichen. Um alles andere machst du einen 
großen Bogen.
Datei und Pfadnamen mit Leerezeichen und dem ganzen restlichen PiPaPo 
sind was für BWL Studenten und Manager, die ihre Powerpoint 
Präsentationen nicht mehr finden, wenn der Ordner nicht im Gott 
gegebenen Dokumenten Ordner liegt und UMlaute enthalten darf. Wir sind 
Programmierer. Wir haben kein Problem damit, wenn eine Datei 
'Lohnst.doc' heißt und nicht 'Steuerhinterziehungen und Schmiergelder 
2014.doc'

Der Lohn der Sache: Du hast viel weniger Probleme mit deinen Werkzeugen, 
die zum Teil ihren Ursprung in einer Zeit hatten, als Dateinamen aus 8 
Zeichen plus Extension bestanden haben.

[avus (Gast)]

Servus Karl Heinz,

ist klar, die Berichte zu Leer- oder Sonderzeichen und daraus 
resultierenden Problemen kenne ich. DIESER Kelch ist gerade nochmal so 
vorbeigeschlittert.


Ich glaube, daß ich beim Kopieren einer ganz anderen Datei den Fehler 
gemacht habe. Ursprünglich gab es eine "uart.c", die ich mir als File 
aus einem anderen realen Ordner in den aktuellen rüberkopiert hatte und 
dann in "stm32_camera.c" umbenannte.

Auf jeden Fall habe ich jetzt eure Annahmen verifiziert, indem ich das 
komplette Projekt mal durchgenudelt habe - mit der absoluten Pfadangabe 
zu "main.h" in der "stm32_camera.c". Und es compiliert fehlerfrei.
Hachja...

[avus (Gast)]

Vergessen: Nein, workspace war schon richtig. Auf dem Weg dahin sind 
auch keine Unterstriche, Leerzeichen etc.. Ich mag's nur nicht, wenn ein 
Ordnername im Klartext auftaucht - manchmal ist der Rechner vielleicht 
doch an einer Stelle nach außen offen, und dann kann man sich 
blitzschnell in meine Projekte reinhacken (wohl bekomm's bzw. eher nicht 
gg)

[Dr. Sommer (Gast)]

Karl Heinz schrieb:
> Datei und Pfadnamen mit Leerezeichen und dem ganzen restlichen PiPaPo
> sind was für BWL Studenten
Naja. Würden die dateinamen nicht 100x durch shellscripte und erweiterte 
shellscripte (= makefiles) durch dumme string-konkatenation verarbeitet, 
und wäre auf der Kommandozeile nicht das leerzeichen trenner für 
argumente, wäre das alles kein problem... wir leben im 21. Jhdt. ich 
schreibe dies von einem Telefon aus, aber warum muss man die natürliche 
sprache bei dateinamen derart zerstückeln - da könnte man ja gleich 
inode-nummern verwenden! Und korrekte dateinamens-verarbeitung & 
programm-argumente ist an sich ganz einfach - zB in Java mit 
java.io.File, in ruby mit Pathname etc. + jeweilige Array-Klasse - man 
müsste sich nur die "naiven" shell scripte abgewöhnen.
Ich habe mir zB ein ruby basiertes eigenes make-unabhängiges buildsystem 
gebaut, und es war kein problem es so zu programmieren, dass es 
wunderbar mit leerzeichen, umlauten & chinesischen zeichen in dateinamen 
klarkommt. Ich sehe nicht ein dass man sich künstlich wie in den 80ern 
beschränken muss.

[Dennis H. (t1w2i3s4t5e6r)]

Karl Heinz schrieb:
> Datei und Pfadnamen mit Leerezeichen und dem ganzen restlichen PiPaPo
> sind was für BWL Studenten und Manager, die ihre Powerpoint
> Präsentationen nicht mehr finden, wenn der Ordner nicht im Gott
> gegebenen Dokumenten Ordner liegt und UMlaute enthalten darf. Wir sind
> Programmierer. Wir haben kein Problem damit, wenn eine Datei
> 'Lohnst.doc' heißt und nicht 'Steuerhinterziehungen und Schmiergelder
> 2014.doc'

Hier musste ich doch sehr schmunzeln, vorallem beim Gott gegebenen 
Dokumenten-ordner :))

Man merkt förmlich, wie es dich richtig ankotzt :))


Dennis