www.mikrocontroller.net

Forum: GCC UL oder L am Ende von F_CPU Frequenz

Autor: Gronach (Gast)
Datum: 07.05.2008 12:45

Hallo allerseits,

eine kleine Frage, warum ist im GCC Tutorial zu den Atmel
Mikrocontrollern bei der Erklärung des Uart Sendens und Empfangens
dringend darauf hingewiesen L(ong) statt UL am Ende von F_CPU zu
verwenden?
Wenn ich im AVR Studio meine 16000000 in der Confi eintrage verwendet
der Compiler automatisch 16000000UL, wenn ich für die uart Funktion mit
#define extra 16000000L anschaffe bekomme ich eine Warnung über die
Redefinierung der Frequenz. Verwende ich aber UL kommen sogar Errors und
es funktioniert gar nicht. In Postings hier im Forum las ich dass man
generell UL verwenden sollte.
Was ist nun also an der Sache dran?
(PS: Verwende einen externen 16MHz Quarz, Fuses dementsprechend gesetzt)
Autor: Fried Vissel (tich)
Datum: 07.05.2008 13:09

Also ich nehme immer UL, verwende den GCC von WinAVR, allerdings mit der
Code Blocks IDE, die ist auch für umme und IMHO sehr zu empfehlen.
Gruß Fried
Autor: Johannes M. (johnny-m)
Datum: 07.05.2008 13:36

Gronach wrote:
> Hallo allerseits,
>
> eine kleine Frage, warum ist im GCC Tutorial zu den Atmel
> Mikrocontrollern bei der Erklärung des Uart Sendens und Empfangens
> dringend darauf hingewiesen L(ong) statt UL am Ende von F_CPU zu
> verwenden?
Weil die Berechnung des Baudratenfehlers, die im Tutorial-Beispiel
enthalten ist, einen vorzeichenbehafteten Wert benötigt. Die Berechnung
muss demzufolge in dem Fall in signed long durchgeführt werden. Wenn
man den Wert für die CPU-Frequenz mit UL angibt, funktioniert die
Berechnung nicht.
Autor: Gronach (Gast)
Datum: 07.05.2008 13:39

Ah, super danke!
Das heißt wenn ich den Fehlerwert händisch für die fixierte Baudrate
nachrechne und die Berechnungsroutine rausschmeiße kann ich getrost UL
für den Rest des Programms verwenden?
Autor: 900ss D. (900ss)
Datum: 07.05.2008 13:44

Gronach wrote:
> Ah, super danke!
> Das heißt wenn ich den Fehlerwert händisch für die fixierte Baudrate
> nachrechne und die Berechnungsroutine rausschmeiße kann ich getrost UL
> für den Rest des Programms verwenden?

Sollte so sein. Es gibt da meines Wissens keine feste Vereinbahrung ob
nun L oder UL. Es kommt eben darauf an, was man mit der Konstante dann
berechnet, wie du schon erfahren hast.
Autor: Simon K. (simon) Benutzerseite
Datum: 07.05.2008 14:51

Du kannst die Berechnung auch abwandeln, dann läuft's auch mit UL
#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)
 
#if ((BAUD_ERROR>1010) || (BAUD_ERROR<990))
  #error Systematischer Fehler der Baudrate grösser 1% und damit zu hoch! 
#endif

Siehe auch die Diskussionsseite dazu:
http://www.mikrocontroller.net/articles/Diskussion...
Autor: Gronach (Gast)
Datum: 07.05.2008 15:02

Wow, genial, danke! Die Diskussionsseite hatte ich bis jetzt nur
überflogen, das ist ja wirklich ein ausgezeichneter Tipp, danke!
Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum: 07.05.2008 16:24

Du kannst auch <avr/setbaud.h> benutzen.

http://www.nongnu.org/avr-libc/user-manual/group__...

Antwort schreiben

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

Wichtige Regeln - erst lesen, dann posten!

  • Suchfunktion und Betreffsuche benutzen - vielleicht gibt es schon einen ähnlichen Beitrag
  • Aussagekräftigen Betreff wählen
  • Im Betreff angeben um welchen Controllertyp es geht (AVR, PIC, ...)
  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
  • JPEG-Dateien (.jpg) nur für Fotos verwenden, Schaltpläne, Screenshots usw. als PNG oder GIF anhängen

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [pre]vorformatierter Text (z.B. Code in anderen Sprachen)[/pre]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel






webmaster@mikrocontroller.netImpressumWerbung auf Mikrocontroller.net