|
|
Forum: Compiler & IDEs Fehlermeldung bei Benutzung des UART Codes aus GCC-TutorialHallo, gcc gibt mir folgenden Fehler
bei Benutzung des Code-Fragments
aus dem UART Abschnitt des GCC-Tutorals. Irgendeine Idee? Danke Gerhard Irgendeine Idee? Wie sieht deine Oszillatorfrequenz im Programm aus? Die Makros sind so, wie sie da stehen, Mist. BAUD_ERROR ist, bedingt durch die anderen Teilausdrücke, aus denen er besteht, vom Typ unsigned int. Offenbar war das aber nicht beabsichtigt, sondern eigentlich wollten den gern jemand als signed int haben -- geht aber nicht, da der Präprozessor keine type casts kann. Was passiert (und weshalb es die Warnung gibt) ist, dass in einem Vergleich ein signed int und ein unsigned int gegenüber stehen. Die integer promotion rules besagen in diesem Falle, dass dann der komplette Vergleich unsigned int wird. Damit wird die -10 umgewandelt in eine 0xfff6 bzw. 65526. Das war vermutlich nicht im Sinne des Erfinders... Ich würde mittlerweile zu dem Makros aus <util/setbaud.h> raten. Die Doku findest du hier: http://www.nongnu.org/avr-libc/user-manual/group__util__setbaud.html Oszillatorfrequenz = 12000000 Baudrate 9600 daraus folgt: UBRR_VAL = 77,625 (wird wohl auf 77 abgeschnitten) BAUD_REAL = 9615 BAUD_ERROR = 1.5625 Promille also deutlich kleiner als 10. Gerhard @Jürg Wunsch: Danke vielmals! Sollte man im Tutorial evtl. zumindestens eine Bemerkung einstellen. So compiliert der Code jedenfalls nicht. Gerhard Gerhard wrote:
> also deutlich kleiner als 10.
...aber eben auch deutlich kleiner als 65526.
Du musst davor noch F_CPU (oder wie heissts doch gleich) setzen, auch wenns schon im Makefile steht - dann klappts mit den Makros .. Hatte die selbe Fehlermeldung. @Thomas: nein, hatte #define F_CPU 12000000L 2 Zeilen davor gesetzt. Das ist nicht der Grund. Gerhard @ Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite >Die Makros sind so, wie sie da stehen, Mist. BAUD_ERROR ist, bedingt Nanana. Vor Öffnung des Mundwerks Hirn einschalten. Sofern vorhanden. >durch die anderen Teilausdrücke, aus denen er besteht, vom Typ >unsigned int. Offenbar war das aber nicht beabsichtigt, sondern >eigentlich wollten den gern jemand als signed int haben -- geht aber >nicht, da der Präprozessor keine type casts kann. Doch, man öffne die Augen und lese.
MFG Falk OK, wenn du alles als signed long machst. Ist aber unüblich, AVR Studio hängt das UL von allein da dran, und schon haste den Salat. Mittlerweile finde ich die Arbeiten in <util/setbaud.h> wirklich besser. @ Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite >OK, wenn du alles als signed long machst. Ist aber unüblich, AVR Studio >hängt das UL von allein da dran, und schon haste den Salat. ??? Ist mit AVR Studio fehlerfrei getestet. >Mittlerweile finde ich die Arbeiten in <util/setbaud.h> wirklich >besser. Muss neu sein. Ich hab nur ne alte WINAVR-Version von anno 2006? MFG Falk Hatte im Makefile CDEFS = -DF_CPU=12000000UL stehen, das hat offensichtlich zu dem Fehler geführt. Nach Änderung im Makefile auf: CDEFS = -DF_CPU=12000000L compiliert der Code anstandslos. So ganz verstehe ich es leider noch nicht. Danke Gerhard Falk Brunner wrote: >>Mittlerweile finde ich die Arbeiten in <util/setbaud.h> wirklich >>besser. > > Muss neu sein. Ja, ist es. Deshalb schrieb ich ja ,,mittlerweile''. @ Gerhard (Gast) >CDEFS = -DF_CPU=12000000L >compiliert der Code anstandslos. So ganz verstehe ich es leider noch >nicht. ist doch sonnenklar. Endung UL = Unsigned long Endung L = signed long Da ein Vergleich mit negativen Zahlen gemacht wird, muss logischerweise ein signed long verwendet werden. MFG Falk Gerhard wrote: > CDEFS = -DF_CPU=12000000UL > > stehen, das hat offensichtlich zu dem Fehler geführt. Ja, und das ist genau das, was mir daran nicht gefällt: die Makros im Tutorial hängen davon ab, dass F_CPU vorzeichenbehaftet ist. Da es keine negativen CPU-Frequenzen gibt, ist das natürlich eher widernatürlich. > So ganz verstehe ich es leider noch > nicht. Nur durch konsequentes Deklarieren aller beteiligten Teilkonstanten bleibt der Typ des Gesamtausdrucks (so wie vom Autor beabsichtigt) selbst vorzeichenbehaftet. Die Vorzeichenhaftigkeit ist wiederum aber Bedingung dafür, dass man am Ende einen Vergleich gegen positive und negative Zahlen durchführen kann. Damit hängen die Makros aber von der Nutzereingabe ab und sind folglich nicht gerade das, was ich als stabil bezeichnen würde. Die bereits genannten Makros aus <util/setbaud.h> dagegen kommen auch mit vorzeichenlosen Zahlen gut klar, da sie intern sowieso vorzeichenlos rechnen. Die Fehlerberechnung wird dort geringfügig anders gemacht. 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
Noch kein Account? Hier anmelden.
|
|
Thread beobachten
Seitenaufteilung abschalten