Hallo Forum, habe hier ein Problem mit einem typedef struct
in Datei a.h
steht
1
typedefstruct{
2
chara;
3
intb;
4
}my_struct;
5
6
my_structmy_funktion(charmy_variable);
hier für my_funktion mecktert der Kompiler noch nicht am Typ rum.
in meiner zweiten header-Datei b.h steht
1
#include"a.h"
2
voidmy_funktion2(my_structmy_variable2);
allerdings bekomm ich hier den Fehler:
unknown type name 'my_struct'
Versteh ich nicht ganz, durch das #include "a.h" müsste doch in b.h auch
my_struct beklannt sein, oder?
der Bob
Edit:
meine vorherige Lösung war ohne typedef, da konnte das Problem durch die
Zeile
bob blob schrieb:> Versteh ich nicht ganz, durch das #include "a.h" müsste doch in b.h auch> my_struct beklannt sein, oder?
Richtig.
Das Problem steckt in den Teilen, die du nicht gezeigt hast.
An dem, was du gezeigt hast, gibt es erst mal nichts auszusetzen.
bob blob schrieb:> aww, dachte das reicht so.
Naja, das was du gepostet hast ist wie Karl Heinz bereits sagte
fehlerfrei. Der Fehler liegt also woanders. Du hast 2 Möglichkeiten:
- selber weitersuchen
- hier das komplette Projekt als Anhang posten und hoffen das sich das
jemand anschau(h?)t.
bob blob schrieb:> ok ihr beiden, hier nochmal etwas weniger gekürzt :)>> #include <misc.h>
Es gibt einen Systemheader names "misc.h"???
> #include "../inc/main.h"
Besser als die Raufruntergekraxel mit .. ist, das Verzeichnis dem
Compiler per -Ipfad mitzuteilen.
> [...]>> Ich seh das Problem immernoch nicht :|
Übersetzet die zugehörigen C-Dateien mit -save-temps -g3 und schau in
die erzeugten .i-Dateien, wo was wie included und defined wird.
Ausserdem brauchen die Header stdint.h wegen uint16_t.
Ich rate mal mit Rosenthal:
In deinem .c-File steht:
1
...
2
#include"../inc/a.h"
3
#include"../inc/b.h"
4
...
In ../inc/main.h steht:
1
...
2
#include"../inc/b.h"
3
...
Rekursionen in Include-Files sind immer gefährlich.
Das ist aber nur eine von 7586 Fehlerquellen, die ich jetzt nicht alle
aufzählen möchte.
Besser ist es, du postest auch das .c-File und ../inc/main.h.
Falls misc.h von dir selbst geschrieben ist: her damit.
Falls in ../inc/main.h weitere von dir selbst geschriebene Files
includet werden: her damit.
Kurz: Wir brauchen so viel Quellcode, dass wir das ganze Ding ohne die
Meldung "No such file or directory" compilieren können.
Yalu X. schrieb:> Kurz: Wir brauchen so viel Quellcode, dass wir das ganze Ding ohne die> Meldung "No such file or directory" compilieren können.
Oder selber shauen was passiert wie eben beschrieben, d.h. das
Präcompilat durchschauen; da stehen alle Defines drin (eischliesslich
dir per -D und die Built-in Macros) und auch die Include-Pfade sind zu
sehen.
Und das nächste mal braucht blobbob dann keine Nanny mehr (und diesmal
eigentlich auch nicht) :-)
hmm, kann die Optionen nicht setzen, sind in Atollic Lite nicht
editierbar. Das ist ja blöd :)
Mal schaun ob dich das ganze auf uvision umbrechen kann, also wird ein
Stückchen dauern...
Der kennt die wahrscheinlich nur, wegen der header die davor kamen.
Solltest also die stdint trotzdem includieren. Finde heraus wie du nur
den preprozessor laufen laesst, und sie dir das ergebnis an.(beim gcc
isses -E)
bob blob schrieb:> hmm, kann die Optionen nicht setzen, sind in Atollic Lite nicht> editierbar. Das ist ja blöd :)
Ja, blöd.
Werden denn die anbgesetzten Befehle nacht mal angezeigt?
Dann kannste die rauskopieren, per copy & paste in ne Shell und da von
Hand ausführen und die Schalter setzen.
Vielen Dank Leute :)
Lösung:
Die Fehlermeldung hat irgendwie(?) auf die falsche Datei gezeigt. Per
Konsole war diese fehlerfrei kompilierbar, dafür eine andere nicht.
Diese andere, nicht kompilierbare Datei, war eben diese in der das
typedef struct steht, mit dem Fehler das typedef struct sei unbekannt.
Das lag wiederrum daran, dass das typedef struct nach den includes
stand, aber es in den includes schon gebraucht wurde. Erkennbar war das
ganze dann in der *.i-Datei
Btw der komplette Aufruf:
C:\Users\bob\Atollic\TrueSTUDIO\ARM_workspace\test\Debug>arm-atollic-eab
i-gcc -c -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=softfp
-std=gnu90 -DUSE _STM32F4_DISCOVERY -DHSE_VALUE=8000000 -DSTM32F4XX
-DUSE_STDPERIPH_DRIVER -I../s rc -I../inc -I..\Libraries\CMSIS\Include
-I..\Libraries\Device\STM32F4xx\Include
-I..\Libraries\STM32F4xx_StdPeriph_Driver\inc -I..\Utilities\STM32_EVAL
-O0 -ff unction-sections -fdata-sections -g3 -Wall -save-temps -o
src\uart.o ..\src\uart.c