mikrocontroller.net

Forum: Compiler & IDEs Verständnis - C - includes und Prototypen


Autor: Thomas (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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 :-(

Autor: Die meisten Elche (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Die meisten Elche (Gast)
Datum:

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

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum?

Autor: MasterFX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hugo Bossard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Karl heinz Buchegger (kbucheg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> @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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> #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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.