Problem mit typedef und enum

Und wo kommt message_buffer_msg_source_t her?

Das ist ein enum, der in einer anderen Datei "message_buffer.h" 
definiert wird:

1

  enum message_buffer_msg_source_t_ {

2

    MSG_SOURCE_TTYS0,         // serial interface

3

    MSG_SOURCE_TTYEXTDISPLAY, // interface of the graphic-display-card

4

    MSG_SOURCE_TTYINTDISPLAY, // interface of the hd44780-display

5

    MSG_SOURCE_SYSTEM         // internal message

6

  };

7

  typedef enum message_buffer_msg_source_t_ message_buffer_msg_source_t;

Also im Prinzip das gleiche Problem, aber das wird (noch) nicht 
angezeigt.

Michael Strosche schrieb:
> Also im Prinzip das gleiche Problem, aber das wird (noch) nicht
> angezeigt.

Nein, DAS ist das Problem, was obige Fehlermeldung auslöst. In der steht 
doch auch, das bereits vor dem Auftauchen von 'gcode_handler_type_t' ein 
Problem aufgetaucht ist.

Falls es Dir noch nicht klar ist: Du musst message_buffer.h in 
command_buffer.h inkludieren.

So. Hier dann mal die entsprechenden Dateien. Die confg.h hab ich 
beschnitten!

1

Error  6  expected ')' before 'type'  H:\...\command_buffer.h  32  55

2

Error  5  expected specifier-qualifier-list before 'gcode_handler_type_t'  H:\...\command_buffer.h  22  5

Viele Grüße
Stroggi

Michael Strosche schrieb:
> So. Hier dann mal die entsprechenden Dateien.

Klasse, der echte Code ist in Bezug auf die Include-Logik also ganz 
anders, als dein Code im OP. Das zeigt mal wieder schön, wie sinnvoll es 
ist, Phantasie-Code zu posten statt dem Echten.

Wenn config.h inkludiert wird, wird dort command_buffer.h VOR 
gcode_handler.h eingebunden, also sind dort dann die Sachen aus 
gcode_handler.h noch nicht bekannt.

Schön und gut, aber wenn es so eine simple das vor dem Sache wär, dann 
hätt ich bestimmt net hier gefragt, sondern wär selbst drauf gekommen. 
Ich hab das eben nochmal in allen Kombinationen ausprobiert und von 0 an 
neu compilieren lassen. Der Fehler bleibt der selbe.

Michael Strosche schrieb:
> Schön und gut, aber wenn es so eine simple das vor dem Sache wär, dann
> hätt ich bestimmt net hier gefragt, sondern wär selbst drauf gekommen.

Wie sieht überhaupt die C-Datei aus, bei deren Übersetzen der Fehler 
kommt? Wird dort direkt einer der spezifischen Header eingebunden, oder 
nur config.h (daraus ergeben sich unterschiedliche Reihenfolgen)? Was 
wird dort sonst noch eingebunden? Ist überhaupt uint8_t dort bekannt?

Ich habe jedenfalls keine große Lust mehr auf Raten.

Tu Dir einen Gefallen und inkludiere in den h-Dateien einfach genau das, 
was darin benötigt wird anstatt sämtliche h-Dateien in eine config.h zu 
packen.

In den C-Dateien wird der dazugehörige header mit eingebunden. Also zur 
command_buffer.c gehört die command_buffer.h. Sonst wird dort nix 
eingebunden. Über die config.h in den entsprechenden header-dateien ist 
der Rest dann bekannt.
uint8_t ist natürlich bekannt, da in der config.h alle relevanten header 
(  avr/io.h, <stdint.h>, <string.h>, <avr/interrupt.h>, <util/delay.h>, 
<math.h>) VOR allem anderen eingebunden werden.

Des Weiteren habe ich meine Gründe den Code nicht vollständig zu posten, 
da die Logik hinter dem ganzen closed source ist (bzw. sein wird)!

Michael Strosche schrieb:
> In den C-Dateien wird der dazugehörige header mit eingebunden. Also zur
> command_buffer.c gehört die command_buffer.h. Sonst wird dort nix
> eingebunden. Über die config.h in den entsprechenden header-dateien ist
> der Rest dann bekannt.

Womit du wieder eine wichtige Information ausgelassen hättest, nämlich 
bei welcher C-Datei denn nun der Fehler kommt. Ein letztes Raten von 
mir: es ist gcode_handler.c. Wenn du das mal schrittweise durchgehst, 
wirst du feststellen, dass dort command_buffer.h immer vor 
gcode_handler.h bearbeitet wird, egal welche Reihenfolge du in config.h 
angibst.

Ich hab jetzt in allen c-files die benötigten header inkludiert und aus 
der config verbannt. Seltsamerweise funktionierts jetzt ohne Fehler.

Michael Strosche schrieb:
> Ich hab jetzt in allen c-files die benötigten header inkludiert und aus
> der config verbannt. Seltsamerweise funktionierts jetzt ohne Fehler.

Weil jetzt in gcode_handler.c command_buffer.h nicht mehr inkludiert 
wird (und damit natürlich auch nicht mehr in der falschen Reihenfolge 
bezüglich gcode_handler.h).