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 :-(
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)
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 #include-Anweisung hat nichts in der Headerdatei verloren, in usart.c darfst Du sie gerne wieder einfügen.
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.
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.
@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
>> @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.
> #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.
@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
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.