typedefs in h-File werden nicht erkannt

[Lief E. (kallisti)]

Hallo

Ich habe ein grösseres Projekt, welches mehrere - von verschiedenen 
Leuten erstellte - Hardwarelibraries verwendet.
Mir fiel nun auf, dass in jeder dieser Libs typedefs verwendet werden 
(entweder wurden sie direkt implementiert oder als h-File eingebunden).
Ich dachte mir, es sei sinnvoll, alle diese typedefs in einem einzigen 
File zusammen zu nehmen. Das habe ich auch gemacht und das File 
LibDefines.h genannt.
Es ist so, dass ich ein Hauptprogramm habe (nennen wir es main.c) und 
darin binde ich meine Hauptlibrary (lib.h) ein.
Und in lib.h binde ich dann wiederum die oben erwähnten 
Hardware-Libraries (a.h/b.h/c.h) ein.
Also habe ich mein LibDefines.h einfach zuoberst in meiner Hauptlibrary 
lib.h eingebunden, sodass dem Compiler bevor er a.h/b.h/c.h aufruft, die 
typedefs schon bekannt sind.
Leider funktioniert das nicht, der Compiler (msp-gcc) zeigt solche 
Fehlermeldungen:

In file included from ../../Library/ff.c:76:
../../Library/ff.h:429: error: expected specifier-qualifier-list before 
'BYTE'
../../Library/ff.h:466: error: expected specifier-qualifier-list before 
'WORD'
Etc etc.

Ich interpretiere das so, dass die typedefs dem Compiler nicht bekannt 
sind.

Ich habe dann LibDefines.h direkt in a.h/b.h/c.h eingebunden (wobei 
LibDefines.h einen Include-Guard hat).
Dann funktioniert die Software fehlerfrei.

Ich verstehe jedoch nicht, warum es dann im ersten Fall nicht 
funktioniert.

Ich bedanke mich im voraus für Eure Hilfe!

[Karl H. (kbuchegg)]

Lief Erickson schrieb:

> Ich verstehe jedoch nicht, warum es dann im ersten Fall nicht
> funktioniert.

Ohne ein bischen nachvollziehbaren Code wird dir da auch hier keiner 
helfen können.

Aber ein Tip:
Wenn ich mir nicht sicher bin, ob ein Header File überhaupt eingebunden 
wird, dann mach ich ganz gerne mal folgenden Test:

Ich provoziere im Header File einen Fehler.
Einfach am Anfang irgendeinen Text "hsdf8uzcinerwb" einfügen.

Die Erwartungshaltung ist:
Wenn dieses Header File eingebunden wird (egal über welche dubiosen 
Wege), dann muss ich den von mir provozierten Fehler beim Compilieren 
sehen. Kommt KEIN Fehler vom Compiler, dann kann ich sicher sein, dass 
dieses Header File nicht eingebunden wurde und mache mich auf die Suche, 
warum nicht. Das können dann zb irgendwelche #define / #ifdef 
Kombinationen sein, die diesen #include auslassen. Das können 
Namenskonflikte bei Include-Guards sein. Das kann alles mögliche sein.

Dieser 'Fehler provizier' Test ist meistens ziemlich wirkungsvoll, vor 
allen Dingen dann, wenn man dann anfängt den 'Fehler' zu verschieben um 
nachzuvollziehen, welcher Weg durch einen #ifdef Dschungel eigentlich 
genommen wird.

[Marwin (Gast)]

Ohne den konkreten Code zu sehen, ist das reines Raetselraten. Abgesehen 
davon ist es eine kluge Strategie, dass jedes File selbst das included, 
was es braucht und nicht in irgendwelchen Implementationsfiles 
Headerfiles includet werden, damit andere, spaeter includete Headerfiles 
funktionieren - wer soll darueber langfristig den Ueberblick behalten?

[Lief E. (kallisti)]

Also hier das erwähnte main:

// File:   13_Stoppuhr.c
// Date:   12.12.2009

#include <lib_v2.h>   // Hauptlib          

//---------------------------------------------------------------------------
//Hauptprogramm
//---------------------------------------------------------------------------
int main(void)
{

}

Lib_v2.h :

//#####################################################################
// Target....: TI MSP430F1611 microcontroller
// Date......: 2010.06.08
// Purpose...: Headerfile for Lib_v2.c. 
//######################################################################

//================================================================== includes
//------------------------------------------ compiler's include path 
#include <io.h>
#include <signal.h>
#include <stdio.h>

//--------------------- module headers for used modules defined in Hardware.h
#include <LibDefines.h>  //Lib mit den typedefs
#include <Hardware.h>    //Hier werden die unten geprueften defines gesetzt

//------------------------------------------------------------- TimerA module
#ifdef HwUSE_TIMER_A
  #include <LibTimerA.h>
#endif
  
//-------------------------------------------------- analog/digital converter
#ifdef HwUSE_ADC
  #include <LibAdc.h>
#endif
  
//-------------------------------------------------- digital/analog converter
#ifdef HwUSE_DAC
  #include <LibDac.h>
#endif

//-------------------------------------------------------------- UART1 module
#ifdef HwUSE_UART1
  #include <LibUart1.h>
#endif

//-------------------------------------------------------------- UART0 module
#ifdef HwUSE_UART0
  #include <LibUart0.h>
#endif

//-------------------------------------------------------- LCD display module
#ifdef HwUSE_LCD
  #include <LibLcd.h>  //Benoetigt LibDefines.h
#endif  

//-------------------------------------------------------- SD Card
#ifdef HwUSE_SDCard
  #include <ff.h>     //Benoetigt LibDefines.h
  #include <fat.h>    //Benoetigt LibDefines.h
#endif

LibDefines.h

//#####################################################################
// Target....: TI MSP430F1611 microcontroller
// Date......: 05.06.2012
// Purpose...: Global #defines and type definition in this file
//###########################################################################
#ifndef _LIBDEFINES
#define _LIBDEFINES
//******************************************************** global definitions
//======================================================= common data types
// Due to the fact that not every compiler treats the standard C datatypes
// the same way (e.g. unsigned short may be 8 bits wide on some compilers,
// 16 bits on others), it is useful to define own types, which can be made
// the same across all platforms. The code will get more portable.
//=========================================================================
                      
typedef unsigned char       BYTE;                         // 8 bits
typedef unsigned char       UCHAR;                        // 8 bits used for SD Card

typedef unsigned int        WORD;                         // 16 bits
typedef unsigned int        UINT;                         // 16 bits used for SD Card
typedef unsigned short      USHORT;                       // 16 bits used for SD Card
typedef unsigned short      WCHAR;                        // 16 bits used for SD Card

typedef unsigned long       DWORD;                        // 32 bits
typedef unsigned long       ULONG;                        // 32 bits used for SD Card
typedef unsigned long long  QWORD;                        // 64 bits

typedef char          SBYTE;                              // 8 bits signed

typedef int           INT;                                // 16 bits used for SD Card
typedef short         SWORD;                              // 16 bits signed           
typedef short         SHORT;                              // 16 bits used for SD Card

typedef long          SDWORD;                             // 32 bits signed                        
typedef long          LONG;                               // 32 bits used for SD Card
typedef long long     SQWORD;                             // 64 bits signed

#ifndef NULL
  #define NULL    ((void*)0)
#endif

//========================================================= boolean constants
typedef enum { FALSE = 0, TRUE } BOOL;
//==================================================== input/output constants
#define INPUT   0x00                             // set ports as input
#define OUTPUT  0xFF                             // set ports as output

#endif /*_LIBDEFINES */

Und in den Files LibLcd.h/ff.h und fat.h nichts eingebunden.

>Wenn ich mir nicht sicher bin, ob ein Header File überhaupt eingebunden
>wird, dann mach ich ganz gerne mal folgenden Test:
>Ich provoziere im Header File einen Fehler.
>Einfach am Anfang irgendeinen Text "hsdf8uzcinerwb" einfügen.

Das habe ich auch gemacht, er hat bei jeder Headerdatei, die ich 
modifiziert habe, eine Fehlermeldung gebracht.

>es eine kluge Strategie, dass jedes File selbst das included,
>was es braucht und nicht in irgendwelchen Implementationsfiles
>Headerfiles includet werden

Da geb ich Dir Recht, das macht eigentlich mehr Sinn.

Ich würde einfach gerne wissen, wo der Unterschied liegt, wenn ich das 
File wie oben einbinde oder halt einzeln bei jedem der drei Libraries.
Wenn der Compiler die Files überstetzt, dann kommt er ja im oberen Fall 
ziemlich schnell einmal zum LibDefines.h. Er sieht die typedefs und 
speichert diese (irgendwo?) ab. Warum sind dann diese den anderen 
h-Files so nicht bekannt. Wenn ich LibDefines.h jedoch in jedem File 
einzeln einbinde, dann geht der Compiler ja auch nur einmal hindurch 
(wegen dem Include-Guard) im Gegensatz zum ersten Fall funktioniert es 
jedoch.

[Rufus Τ. F. (rufus)]

> Es ist so, dass ich ein Hauptprogramm habe (nennen wir es main.c) und
> darin binde ich meine Hauptlibrary (lib.h) ein.

Du solltest dringendst Deine Terminologie ändern. Es geht hier nicht 
um Libraries, sondern um Headerdateien oder meinetwegen 
"Includedateien".

Der Begriff "Library" aber ist ein feststehender Begriff mit einer 
feststehenden Bedeutung, wenn Du den falsch verwendest, kommt es zu 
Irritationen.


</pedanterie, wichtige>

[Karl H. (kbuchegg)]

Lief Erickson schrieb:

> Ich würde einfach gerne wissen, wo der Unterschied liegt, wenn ich das
> File wie oben einbinde oder halt einzeln bei jedem der drei Libraries.

Keinen.
Da muss es noch irgendeine Zusatzbedingung geben, die du übersiehst und 
auf die hier keiner kommt.

Kann es sein, dass du deinen Include-Guard zb beim Compiler Aufruf 
vorbelegt hast?

[Lief E. (kallisti)]

>Kann es sein, dass du deinen Include-Guard zb beim Compiler Aufruf
>vorbelegt hast?

Ich weiss nicht genau, was Du damit meinst.

Mein Makefile sieht so aus:

#################################################################### 
# Platform..: TI-MSP430
# Date......: 07.07.2009
# Input.....: The following commandline parameters are required for the
#             compile and build jobs. The examples use variables (%var%) as
#             they are provided by PsPad programming editor. This
#             commandline must be provided for build operations:
#
#             make JOB=%Ext% SOURCE=%Name%%Ext% TOOLS="D:\Program Files\MspGcc"
#
#             make.exe JOB=%Ext% SOURCE=%Name%%Ext% TOOLS=<MspGccPath>
#                      [DLAUTO=yes]
#
#             EXT=%Ext%           Is used for build operations. It is the
#                                 file extension of the active file in the
#                                 editor.
#
#             SOURCE=%Name%%Ext%  Is the name and extension of the active
#                                 file in the editor. It is used for single
#                                 file compilations.
#
#             TOOLS=<MspGccPath>  Root directory of MspGcc installation.
#                                 Must be enclosed in quotes if the path
#                                 contains spaces.
#
#             DLAUTO=yes          Tells the make job if the object file
#                                 shall be downloaded immediately after a
#                                 a successful build.
#
#             For non-compile or build jobs (makehex, makelst, download,
#             debug and clean) the syntax is
#
#             make.exe [makehex | makelst | download | debug | clean]
#
#             Note that these jobs can also perform a build operation,
#             depending on the job settings.            
#             
# Remarks...: The current path when executing this makefile has to be in
#             the folder, where the objects go (e.g. ./Obj). In PsPad, it
#             can be set in the compiler dialog, e.g. %ProjectDir%\Obj.
#############################################################################

#===================================================== customizable section
#-------------------project name, will also be the name of the output file
PROJECT = 13_stoppuhr_Dev3

#--------------------------- paths relative to object path (%ProjectDir%\Obj)
SRCPATH = ../Src/
BINPATH = ../Bin/
LSTPATH = ../Lst/
LIBPATH = ../../Library/                       
#---------------------------------- list of all main and library source files
MAINSOURCES = 13_Stoppuhr.c
LIBSOURCES  =  Lib_v2.c fat.c ff.c diskio.c LibLcd.c 

#---------------------------------- paths for executables and system includes
MSPINST = $(TOOLS)/
MSPINC  = "$(MSPINST)msp430/include"
MSPEXE  = $(MSPINST)Bin/
CC      = "$(MSPEXE)msp430-gcc"
RM      = rm.exe

#------------------------------------ COM port for iProg FTDI chip (COMx - 1)
BSLPORT = 4

#------------------------------------- automatic download on successful build
DLAUTO  = no

#================================================ end of customizable section

#------------------------------------------------------- environment settings
SOURCES  = $(MAINSOURCES) $(LIBSOURCES)

DEPSSRC  = $(addprefix $(SRCPATH), $(MAINSOURCES)) \
           $(addprefix $(LIBPATH), $(LIBSOURCES))

INCLUDES = -I $(SRCPATH) -I $(LIBPATH) -I $(MSPINC) 

VPATH    = $(SRCPATH) $(LIBPATH)

#---------------------------------------------------------- compiler settings
MCU     = msp430x1611
LDFLAGS = -mmcu=$(MCU)
CFLAGS  = -mmcu=$(MCU) $(INCLUDES) -g -O0 -Wall 

#======================================================== command line parser
# Call job depending on filename on commandline
#============================================================================
ifeq "$(suffix $(JOB))" ".c"
  EXEC = compile

endif

ifeq "$(basename $(JOB))" "makefile"

  ifeq "$(DLAUTO)" "yes"
    EXEC = download
  else
    EXEC = build
  endif    

endif
  
job: $(EXEC)
# Debug     @echo $(SOURCE): successJOB
#============================================================================

#============================================================== job 'compile'
# A single file gets compiled. The file is the active file in the editor.
#============================================================================
OBJECT = $(SOURCE:.c=.o)

compile: $(SOURCE)
  $(CC) $(CFLAGS) -c -o $(OBJECT) $<
  @echo $(SOURCE): success1 compile
#============================================================================

#================================================================ job 'build'
# The whole project gets compiled and linked
# Syntax: Either 'make.exe build' or 'make.exe job=%Ext%' with 'makefile'
#         as active file in the editor
#============================================================================
OBJECTS = $(SOURCES:.c=.o)
  
$(PROJECT): $(OBJECTS) 
  $(CC) $(LDFLAGS) $(OBJECTS) -o $(BINPATH)$(PROJECT).elf
  "$(MSPEXE)msp430-size" $(BINPATH)$(PROJECT).elf
  
$(SOURCES): 
  $(CC) $(CFLAGS) $< -o $@

build: $(SOURCES) $(PROJECT)
  @echo $(PROJECT): success2 Build
#============================================================================

#============================================================= job 'download'
# Download .elf file onto target. A successful build has to be done before.
# To check for this automatically, add 'build' to download: line.         
# Syntax: make.exe download
#============================================================================
download: build
  "$(MSPEXE)msp430-bsl" -c $(BSLPORT) -e --invert-test --invert-reset \
  $(BINPATH)$(PROJECT).elf
# Debug: rma wenn an dieser Stelle = Fehler.  @echo $(PROJECT): success3 Download build
#============================================================================

#============================================================== job 'makehex'
# Create .HEX file out of .ELF
# Syntax: make.exe makehex
#============================================================================
makehex: build
  "$(MSPEXE)msp430-objcopy" -O ihex $(BINPATH)$(PROJECT).elf \
  $(BINPATH)$(PROJECT).hex
  @echo $(PROJECT).hex created success6
#============================================================================

#============================================================== job 'makelst'
# Create .LST file out of .ELF
# Syntax: make.exe makelst
#============================================================================
LSTOBJ = $(SOURCES:.c=.o)

makelst: build
  "$(MSPEXE)msp430-objdump" -dSt $(LSTOBJ) >$(LSTPATH)$(PROJECT).lst
    @echo $(PROJECT).lst created
#============================================================================

#================================================================ job 'debug'
# Start Insight debugger
# Syntax: make.exe debug
#============================================================================
debug: build
  @echo loading...
  @cmd.exe /C start "gdbproxy" /MIN $(MSPEXE)Msp430-gdbproxy msp430 TIUSB
  @echo target remote localhost:2000 >gdb.ini
  @echo erase all >>gdb.ini
  @echo file $(BINPATH)$(PROJECT).elf  >>gdb.ini 
  @echo load $(BINPATH)$(PROJECT).elf  >>gdb.ini
  @echo break main >>gdb.ini
  @echo continue >>gdb.ini
  "$(MSPEXE)Msp430-insight" --command=gdb.ini  
  @del gdb.ini
  @taskkill /F /IM msp430-gdbproxy.exe
  
#================================================================ job 'clean'
# Delete all auto-generated files
# Syntax: make.exe clean
#============================================================================
clean:
  $(RM) *.o *.a43 dependencies.in \
  $(BINPATH)*.elf \
  $(BINPATH)*.hex \
  $(LSTPATH)*.lst
  @echo clean success4
#============================================================================

#=============================================================== dependencies
-include dependencies.in
dependencies.in:
  $(CC) -MM $(CFLAGS) $(DEPSSRC) >$@
  @echo dependencies update complete
#============================================================================
   
############################################################ EOF makefile

Ich habe schon das Gefuehl, dass es am Kompiliervorgang selber liegt. 
Ich weiss nur nicht genau, wie ich heraus finden kann, welches File er 
als erstes kompiliert und wie die Objectfiles dann linkt.

[Lief E. (kallisti)]

Ich habe den Fehler gefunden, danke für die Hilfe und die Tips :)

[Karl H. (kbuchegg)]

Lief Erickson schrieb:
> Ich habe den Fehler gefunden, danke für die Hilfe und die Tips :)

Und, was wars?
(Jetzt hast du mich neugierig gemacht)

[Jörg W. (dl8dtl) (Moderator)]

Lief Erickson schrieb:
> Ich habe den Fehler gefunden, danke für die Hilfe und die Tips :)

Nun schmeiß deine altertümlichen Datentypen noch weg und ersetz
sie durch die C99-Pendants aus <stdint.h>.  Schließlich wurde gerade
der C11-Standard verabschiedet, da wäre es Zeit, sich zumindest an
den vorherigen mal zu gewöhnen ...