Verständnis - C - includes und Prototypen

[Thomas (Gast)]

Hallo

Ich habe ein paar Probleme beim Verständnis mit den Include-File unter
Win-AVR.

Zu aller erst - ich habe schon massig im Forum gelesen und gesucht; bin
dann letztendlich auch den Weg über MFile von WinAVR gegangen und habe
mir mein MakeFile so erstellt wie es eigentlich passen sollte.

Kurz zum Programm - ohne große Funktionalität! Es besteht aus:
-main.c
-main.h
-usart.c
-usart.h

Zum Problem:

Also, die C-Files enthalten die Funktionen, die Header-Files enthalten
die Prototypen der Funktionen (so kenne ich es von c++ mit den MFC) und
weitere Std. Header-Files.
Beim build bekomme ich aber immer noch Warnings ala

usart.h:2: warning: function declaration isn't a prototype
usart.c:10: warning: function declaration isn't a prototype

Wenn man nicht weiter weiß, sollte man besser jemanden Fragen, der sich
damit auskennt. Kann sich das bitte mal wer anschauen? Ich weiß ned
weiter :-(

[Die meisten Elche (Gast)]

in usart.h:

die erste Zeile löschen.

Funktionen, die keine Argumente übergeben bekommen, müssen stattdessen
das Argument "void" übergeben bekommen.

Aus

  void usart_init();

muss

  void usart_init(void);

werden.

Entsprechendes gilt auch für das .c-File.

(Leere Klammern sind nur in C++, nicht aber in C zulässig)

[Thomas (Gast)]

Wenn ich die #include "main.h" lösche, dann bekomme ich ettliche
Fehlermeldungen wie z.B.:
usart.c:12: error: `UBRRH' undeclared (first use in this function)
usart.c:12: error: (Each undeclared identifier is reported only once
usart.c:12: error: for each function it appears in.)
usart.c:12: error: `uint8_t' undeclared (first use in this function)
usart.c:13: error: `UBRRL' undeclared (first use in this function)

[Die meisten Elche (Gast)]

Die #include-Anweisung hat nichts in der Headerdatei verloren,
in usart.c darfst Du sie gerne wieder einfügen.

[Thomas (Gast)]

Warum?

[MasterFX (Gast)]

Eigentlich ist es eine unfeine Sache die main.h in usart.c einzubinden.
Denn usart.c soll ja Funktionen bereitstellen und nicht main.c (so
zumindest mein erster eindruck).
Header-Dateien sollten nach Möglichkeit immer in die C-Dateien includet
werden, das beugt Missverständnissen vor und trägt zur übersichtlichkeit
bei.
>>usart.c:12: error: `UBRRH' undeclared (first use in this function)
^^Da gehts schon los. Du hast natürlich in die main.h die avr/io.h
eingebunden. Ich hätte jetzt die io.h jeweils in usart.c und in main.c
eingebunden, oder du machst dir eine header-Datei wie z.B. globaldef.h
wo du alle header einbindest die jede Quelle verwendet.

[Hugo Bossard (Gast)]

Ferner würde ich jedes *.h File zu oberst ergänzen mit:

#ifndef _USART_H
#define _USART_H


und zu unterst mit:

#endif /* _USART_H */

jeweils mit dem Namen des h-Files. Dies erspart Dir Ärger bei
mehrfachen Inlcudes un grösseren Projekten.

[Peter D. (peda)]

@MasterFX

Eigentlich ist es eine unfeine Sache die main.h in usart.c
einzubinden.


Seit wann denn das ?

Ich mache das immer so.
Deshalb sinds ja h-Files, damit man sie in c-Files einbinden kann.
Und wenn dabei was schiefgeht, dann ist was im h-File falsch.


Man sollte auch immer das eigene h-File mit einbinden (z.B. uart.h in
uart.c), damit die Typenkonsistenz gewahrt ist. Der Linker macht
nämlich keine Typüberprüfung mehr !


Peter

[Karl heinz B. (kbucheg)]

>> @MasterFX
>>
>> Eigentlich ist es eine unfeine Sache die main.h in usart.c
>> einzubinden.
>
>
> Seit wann denn das ?

Na ja, Ich denke MasterFX siht das genauso wie ich.
'main' als Name ist normalerweise für die Applikation
reserviert. 'usart' ist in diesem Zusammenhang der Name
einer Komponente, die der Applikation zuspielt. Warum
sollte aber eine Komponente wissen in welcher Applikation
sie eingesetzt wird? Wozu braucht uart.c Wissen von
main.h? uart.c/uart.h sollte in sich selbst konsistent
und vollständig sein.
Wenn uart.c Dinge aus avr/io.h braucht, dann soll es diesen
include gefälligst selbst machen und nicht über den Umweg
einer main.h

Es geht also nicht um den #include an sich (daran ist nichts
auszusetzen), sondern ist ein logistisches/organisatorisches
Problem.

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

> #ifndef _USART_H
> #define _USART_H

Bitte so:

#ifndef USART_H
#define USART_H

Namen, die mit einem Unterstrich beginnen sind (vereinfacht
gesagt) für Compiler und Bibliothek reserviert.

[Peter D. (peda)]

@Karl Heinz

"Wenn uart.c Dinge aus avr/io.h braucht, dann soll es diesen include
gefälligst selbst machen und nicht über den Umweg einer main.h"


So hatte ich auch mal gedacht. Aber dabei kam es regelmäßig zu
Konflikten und Überschneidungen. Besonders, wenn man Programmteile in
neuen Projekten nachnutzen will.

Seitdem mache ich alle Hardwaredefinition (XTAL, Portpins usw.) zentral
in der main.h, kann also dort leicht Änderungen vornehmen, und sehe auch
sofort, ob es zu Konflikten kommt.

Insbesondere wenn man Portpins mehrfach nutzt, ist das Definieren an
einer zentralen Stelle wesentlich übersichtlicher.


Peter

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

Ich nenne das Teil dann eher defines.h oder project.h, ich glaube,
das löst die Konfusion um den Namen ,main' hier einigermaßen auf.