Baudraten - #define xxx und einige Auswirkungen

Ohhhh ohhhh, da habe ich also mit sehr wenig Sätzen gezeigt, wieviel ich von einer gar nicht sooo komplizierten Sache verstehe. Im Wesentlichen ist es die ganzzahlige Division - deren Eigenheiten ich übersehen hatte, weil ich bei meinen Überlegungen irgendwie nur Gleitkomma-Zahlen im Kopf hatte. Danke robert für die Tabelle - die mir die Augen schnell und recht weit geöffnet hatte. Danke Volker für den Hinweis auf und den Link zu Bresenham´s Algorithmus.

Ansonsten danke ich für Eure Nachsicht. Ich werde die UBRR-Rechnerei durcharbeiten ( unter anderem schon deswegen, um zu verstehen, wieso mein Beispiel mit den 115k2 am Terminal und den 113k6 in der #define funktioniert). Von der Beschäftigung mit der UBRR-Rechnerei hatte mich mein unbesorgter und unbekümmerter Umgang mit der Lib von PFleury bisher abgehalten. Das soll nicht heißen, dass ich die Schuld an meinem Unwissen jemand anderem in die Schuhe schieben will.

Hallo,

ein bisschen bin ich weiter gekommen. Einmal mit meinem Verständnis zum Baudraten-Generator in ATMEL-Controllern. Und ein bisschen in meiner ursprünglichen Behauptung, dass man Baudraten doch optimieren kann (bitte versteht das nicht als Versuch nach dem Motto "ich will doch Recht behalten"). Danke jedenfalls für eure konstruktiven Hinweise zu meiner ursprünglich falschen Auffassung.

Zum besseren Verständnis des Ganzen habe ich mir zwei Rechnungen gemacht: die analytische und die synthetische. Die zugrundeliegenden Formeln stammen aus dem ATMEL-Doc, siehe Tabelle. Zuerst wurde auf der Basis von 20 MHz und der ganzzahligen Vorgabe des UBRR-Wertes eine theoretische Baudrate (mit Nachkommastellen, also RZ = reeller Zahlenwert) errechnet, wie dies PicNick schon getan hatte; Robert, nochmal danke dafür. Zur Zielbaudrate wurde der theoretische Fehler - Zielwert = 100 % - errechnet. Die Kombinationen mit den geringsten Fehlern im entsprechenden Baudratenbereich sind farbig unterlegt.

Danach wurde zu einer vorgegebenen Baudrate als #define xxx ein UBRR-Wert (RZ) errechnet. (Anmerkung: Bei der Berechnung fällt im vorliegenden Fall der Nachkommaanteil erst "zum Schluss" des Rechenganges an, es wird also kein Anteil unkontrolliert mitgeschleppt). Der als #def BD (#define Baudrate) vorgegebene Wert wird etwa so gewählt, dass er rund 0,5 (Nachkommaanteil wird bei der Rechnung im Praeprozessor abgeschnitten) über dem UBRR-Wert mit dem minimalen Fehler im entsprechenden Bereich liegt. So bekomme ich teilweise durch eine "falsche" Vorgabe (farbig unterlegt und farbige Schrift) einen minimalen Fehler.

Wieso? In der Zeile mit dem roten Marker sieht man, was unter den zugrunde gelegten Umständen bei 115k2 passiert: der Praeprozessor berechnet mit dem #define 115200 ein UBRR von 9 - die 0,85 fallen ja weg - und damit einen Fehler von 8,5 % über der Zielrate. Wenn ich im #define nun den Wert 111 000 schreibe, bekomme ich die theoretische Baudrate 113636 und damit einen Fehler von -1,36 %. Auch mein im Eingangsposting genannter #define 113600 ergibt noch ein UBRR von 10 - und damit -1,36 % - die Abweichung, mit der meine Controller-PC-Verbindung noch zurecht kommt. Auch ein #define 56k bringt bei einer Verbindung mit 56k 1,46 %, bei einer Verbindung mit 57k6 nur -1,36 % - - und so weiter. Ich hoffe, dass diese Rechnung dem einen oder anderen hilft - und dass meine Erläuterungen und Rechnungen verständlich (und diesmal richtig) sind.

............Bild hier  

Volker: Dumm wirds natürlich bei den internen Oszillatoren. Dann kommen die Schwankungen oder ein Offset des internen Oszillators noch zu den hier genannten Abweichungen. Nach Murphy eben immmer (oder zumindest dann, wenns besonders stört) nach der falschen Seite. Also ist die genaue Kenntnis der Frequenz des internen Oszillators schon wünschenswert - ich weiß allerdings nicht, wie ich das 1. messen sollte und 2. wie ich das korrigieren könnte (zur Korrektur gibts doch irgendeine Speicherzelle - damit kenne ich mich leider nicht aus).

Viel Erfolg

Man könnte den UART-Partner mitspielen lassen, der z.B permanent ein 0xC0 sendet.
durch Veränderung des UBRR wird man
ein 0x80 empfangen, ==> Rate/Osc zu schnell, UBRR zu klein
ein 0xE0 empfangen, ==> Rate/Osc zu langsam, UBRR zu gross.

Vielleicht nicht ganz ohne Interesse zur Baudratentoleranz des FTDI.

Gute Toleranz des FTDI hatte ich schon hier vermutet und behauptet, "... dass der FT232 ziemlich fehlertolerant ist ..."

Mit meiner selbstgefertigten USB-UART-Platine (klick für Boarddesign) mit dem FT232 habe ich nun in den letzten Tagen wiederholt festgestellt, dass ich mit nem mega328/8MHz (interner !! Oszillator) bei 38,4 kBD rechnerisch zwar einen Fehler von -7% bzw. +8% (evtl. 12%) erhalte - WENN die 8 MHz stimmen. Da dieser Oszillator bekanntlich z.T deutlich abweicht, kanns mehr oder weniger sein. Trotzdem ist die Verbindung stabil und fehlerfrei. Bei 56k gibts dann erste Fehler.

Auf meinem aktuellen Steckbrettaufbau hatte ich die Frequenz des Quarzes nicht kontrolliert aber die UART mit 38400 Baud betrieben - und sie läuft zuverlässig. WinXP, Terminal von br @ y , meine oben genannte U S B-UART-Platine, 1,5 m Kabel Unitronic (LAPP) 4x0,14, ungeschirmt.

Dass ich mit der gleichen Platine und nem bequarzten m168/m328/20MHz problemlos 256 kBD fahre, hatte ich schon andernorts geschrieben.

Zitat:

---

Zitat von oberallgeier (23.04.2009)

Also ist die genaue Kenntnis der Frequenz des internen Oszillators schon wünschenswert - ich weiß allerdings nicht, wie ich das 1. messen sollte und 2. wie ich das korrigieren könnte (zur Korrektur gibts doch irgendeine Speicherzelle - damit kenne ich mich leider nicht aus).

---

Hatte ich mal beim ATtiny24 (Datenblatt) gemacht. Einen Timer auf PWM konfiguriert und mit Oszi an entsprechenden Pin gemessen. Im einem Programm das OSCCAL Register (Kapitel 6.5) sicherheitshalber zuerst ausgeben lassen. In anderer Programmversion dann in kleinen Schritten verändert. Vorsicht (denk ich) Datenblatt beachten. Im Anwendungsprogramm dann die Registerzuweisung mit dem guten gefundenen Wert als erste ausführbare Anweisung eingefügt. Das PWM Signal ist natürlich nur ein Teil des tatsächlichen Taktes und man muß zurückrechnen.

Man könnte zum Finden eines guten Registerwertes auch per Fuse den CKOUT Pin aktivieren (Kapitel 6.4) und dort den tatsächlichen Systemtakt messen.

Hab nicht gecheckt, ob das beim Mega168 auch so ist.

Gruß
Searcher