www.mikrocontroller.net

Forum: Compiler & IDEs Fehlermeldung bei Benutzung des UART Codes aus GCC-Tutorial


Autor: Gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

gcc gibt mir folgenden Fehler
wakeup.c:93:41: warning: the right operand of "<" changes sign when promoted
wakeup.c:94:5: error: #error Systematischer Fehler der Baudrate grösser 1% und damit zu hoch!
make: *** [wakeup.o] Fehler 1

bei Benutzung des Code-Fragments
#if ((BAUD_ERROR>10) || (BAUD_ERROR<-10))
  #error Systematischer Fehler der Baudrate grösser 1% und damit zu hoch!
#endif

aus dem UART Abschnitt des GCC-Tutorals.

Irgendeine Idee?

Danke
Gerhard

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Irgendeine Idee?

Wie sieht deine Oszillatorfrequenz im Programm aus?

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

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

Autor: Gerhard (Gast)
Datum:

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

Autor: Gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jürg Wunsch:

Danke vielmals!

Sollte man im Tutorial evtl. zumindestens eine Bemerkung einstellen. So 
compiliert der Code jedenfalls nicht.

Gerhard

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

Bewertung
0 lesenswert
nicht lesenswert
Gerhard wrote:

> also deutlich kleiner als 10.

...aber eben auch deutlich kleiner als 65526.

Autor: Gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, meinte natürlich Jörg.

Autor: Thomas L. (tom)
Datum:

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

Autor: Gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Thomas:

nein, hatte

#define F_CPU 12000000L

2 Zeilen davor gesetzt. Das ist nicht der Grund.

Gerhard

Autor: Falk Brunner (falk)
Datum:

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

#warning "F_CPU war noch nicht definiert, wird nun nachgeholt mit 4000000"
#define F_CPU 4000000L    // Systemtakt in Hz, das L am Ende ist wichtig, NICHT UL verwenden! 
#endif
 
#define BAUD 9600L          // Baudrate, das L am Ende ist wichtig, NICHT UL verwenden!
 
// Berechnungen
#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1)   // clever runden
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1)))     // Reale Baudrate
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD-1000) // Fehler in Promille 
 
#if ((BAUD_ERROR>10) || (BAUD_ERROR<-10))
  #error Systematischer Fehler der Baudrate grösser 1% und damit zu hoch! 
#endif

MFG
Falk

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

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

Autor: Falk Brunner (falk)
Datum:

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

Autor: Gerhard (Gast)
Datum:

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

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

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

Autor: Falk Brunner (falk)
Datum:

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

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

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

Autor: Gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alles klar, danke!

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.