typedef struct unbekannt

[bob b. (blobbob)]

Hallo Forum, habe hier ein Problem mit einem typedef struct

in Datei a.h
steht

typedef struct{
char a;
int b;
}my_struct;

my_struct my_funktion(char my_variable);

hier für my_funktion mecktert der Kompiler noch nicht am Typ rum.

in meiner zweiten header-Datei b.h steht

#include "a.h"
void my_funktion2(my_struct my_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

struct frame;

behoben werden.

[Karl H. (kbuchegg)]

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 b. (blobbob)]

aww, dachte das reicht so. Was was noch dasteht kann ja nicht die 
definition wieder löschen. Was brauchst du ncoh um helfen zu können?

[trollalala (Gast)]

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 b. (blobbob)]

ok ihr beiden, hier nochmal etwas weniger gekürzt :)

a.h:

#ifndef A_H_
#define A_H_

  #include <stm32f4xx.h>
  #include <misc.h>
  #include <stm32f4xx_usart.h>
  #include "../inc/main.h"


  struct frame{        //aus erstem Versuch ohne typedef
      uint16_t a;
      uint16_t b;
      uint16_t c;
      };

  typedef struct{
      uint16_t a;
      uint16_t b;
      uint16_t c;
      }FrameTypeDef;

  FrameTypeDef uart_string2struct(volatile char *uart_string);

#endif /* A_H_ */

und b.h

#ifndef B_H_
#define B_H_

  #include "../inc/a.h"
  #include "../inc/main.h"

  //struct frame;
  void uart_cmd_execute(FrameTypeDef frame_in);

#endif /* B_H_ */

Ich seh das Problem immernoch nicht :|

[Johann L. (gjlayde)]

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.

[Yalu X. (yalu) (Moderator)]

Ich rate mal mit Rosenthal:

In deinem .c-File steht:

...
#include "../inc/a.h"
#include "../inc/b.h"
...

In ../inc/main.h steht:

...
#include "../inc/b.h"
...

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.

[Johann L. (gjlayde)]

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) :-)

[bob b. (blobbob)]

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...

[bob b. (blobbob)]

hab den Fehler zwar nicht gefunden, aber eine Lösung.

für die typedef einfach einen eigenen header:

#ifndef TYPE_DEF_H_
#define TYPE_DEF_H_

  //#include "stdint.h"

  typedef struct{
      uint8_t cmd;
      uint8_t data1;
      uint8_t data2;
      }FrameTypeDef;


#endif /* TYPE_DEF_H_ */

und er kennt irgendwie ohne stdint.h uint8_t

LG Bob

[asdf (Gast)]

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)

[Johann L. (gjlayde)]

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.

[bob b. (blobbob)]

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

[Johann L. (gjlayde)]

bob blob schrieb:

> Die Fehlermeldung hat irgendwie(?) auf die falsche Datei gezeigt.

Fehlender Zeilenumbruch am Ende eines Headers?

[bob b. (blobbob)]

Nein, das wars nicht. Aber werds nun auch nichtmehr rausfinden :)