Problem mit #include und Typedefs uint8_t, int16_t, usw.

[Third E. (third-eye)]

Hallo.

Ich will einen PID-Regler bauen. Habe dafür Atmels Application Note 221 
runtergeladen. Der Code ist ja für den IAR-Compiler. Habe ihn deshalb 
für GCC angepasst. Ich verwende Atmel Studio 6. Soweit, so gut.
Ich bin folgendermaßen vorgegangen: Ich habe eine neues Projekt 
erstellt, die Dateien main.c und pid.c im Solution Explorer hinzugefügt.

Die main.c beginnt mit folgenden Zeilen:

#define F_CPU 16000000

#include <avr/io.h>
#include <stdint.h>
#include <avr/interrupt.h>
#include <util/delay.h>

#include "pid.h"

In der main.c kennt der Compiler die Type-defs, so wie es sein soll. 
Alles gut.

In der pid.h steht auch noch

#include "stdint.h"

Wenn ich die Zeile so drin lasse, kommen beim Kompilieren einige 
Fehlermeldungen vom Typ
"INT16_MAX" redefined [enabled by default].

Macht für mich auch Sinn. Woher soll er auch wissen, wenn ein Typ 
mehrmals definiert wird, welche Typedef die richtige ist. Blöd ist bloß, 
dass er ohne dieses include in der pid.h die Typen, z.B. int16_t, gar 
nicht kennt.

Ich finde diese Int-Types grundsätzlich nicht schlecht, wenn man damit 
definiert, wieviel Bit die Variable hat. Das würde ich gern so 
verwenden. Wenn man z.B. mal ein paar Codefetzen auf einem größeren 
Controller verwenden will und man bewusst Variablenüberläufe ausnutzt, 
sollte es dann keine Probleme geben.

Was kann ich machen, dass er in der pid.h die Typedefs kennt?

Im Solution Explorer ist das Verzeichnis Dependencies leer. Habe ich da 
was falsch gemacht?

Danke!
Third-Eye

[Johann L. (gjlayde)]

Dane S. schrieb:

> #include "stdint.h"

Das ist ein Systemheader.  Nimm

#include <stdint.h>

[Third E. (third-eye)]

Danke!
Das wars :-)
Jetzt kompiliert er ohne zu meckern.
Im Projektverzeichnis war die Datei stdint.h (aus der App Note, also 
IAR), die er dann wohl zu verwenden versuchte.

Jetzt steht auch was in Dependencies drin. Wird offensichtlich erst nach 
dem Kompilieren aktualisiert.