Baudraten - #define xxx und einige Auswirkungen

[PicNick]

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.

[oberallgeier]

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.

[Searcher]

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