Hallo Alle,
möglicherweise habe ich eine Abhilfe gegen einige Baudratenfehler.
Ein immer wiederkehrendes Thema im Forum (hier nur EIN Beispiel) sind Probleme bei der Datenübertragung vom Controller über die RS232. Grund ist, dass das enge Zeitraster der seriellen Übertragung von manchen Quarzen nicht einzuhalten ist.
... nicht einzuhalten ist? Sogar ATMEL mit seinen Formeln für die korrekte Einstellung der Oszillatorfrequenz und ein so kompetenter Ratgeber wie MikrocontrollerNet sind ähnlicher Meinung.
Frage: wozu haben wir einen Präprozessor - und eine einstellbare Oszillatorfrequenz für den USART?
Ich habe bei meinem Mega168 mit 20 MHz mit der "korrekten" Einstellung der Schnittstelle auf 115k2 Baud keine Chance, Daten über die RS232 an meinen PC bzw. an das Terminal von Br@y zu senden. Der Fehler ist einfach zu groß - wohl etwa bei -1,4 %. Was also tun? (Bitte fragt nicht, warum ich so aufs Tempo drücke - ich tendiere manchmal ein bisschen zu der Bleifußfraktion - sorry).
Klar - es dämmert schon jedem: einfach die "falsche" Bitrate einstellen. Ein kurzer Test am Controller ergibt folgendes:
//#define UART_BAUD_RATE 113600 // läuft ok
//#define UART_BAUD_RATE 115200 // läuft nicht
//#define UART_BAUD_RATE 116800 // läuft nicht
Frage: Ist diese simple Korrektur wirklich ein kleiner Fortschritt in unserem Bemühen um korrekte Einstellung der Baudrate bei "ungeeigneten" Quarzen?
Ciao sagt der JoeamBerg
Moin!
Du meinst, quasi den Fehler von der ursprünglichen Baudrate abziehen? Oder hast Du das per Trial and Error ermittelt? Das Ganze käme mir sehr gelegen, da ich meistens alle IO's brauche und dann keinen Quarz dran habe.
MfG
Volker
P.S.:
Irgendwo habe ich letztens zufällig was gelesen, das jemand auf einem Pic mit Hilfe des Bresenhamalgorythmus einen genauen Timer verwirklicht hat, da sich der Fehler ja über die Zeit immer mehr gegen null bewegt, evtl. kann man damit ja auch was machen.
Meine kleine Seite
http://home.arcor.de/volker.klaffehn
http://vklaffehn.funpic.de/cms
neuer Avatar, meine geheime Identität
vklaffehn:
Rechne doch mal nach: 113600 ist 1.38% weniger von 115200, also hat ers ausgerechnet^^
Genau! Da leider die meisten Fehlerrechnungen nicht angeben, was der Grundwert ist (na ja, man kann sich bei "-1,4%" schon etwas denken) habe ich die 1,4 % mal auf die 115k2 drauf- und mal runtergerechnet. Nix Trial- und Error, das wäre doch etwas gegen mein Selbstbewusstsein.Zitat von vklaffehn
Wieweit das mit den relativ instabilen internen Oszillatoren geht, weiß ich nicht - dazu habe ich (noch) keine Tests gemacht. Die internen Takte bringen doch meist ihre Fehler durch ihre relativ starke Schwankungsbreite ein - und die kann ja durch eine konstante Korrektur nicht ausgeglichen werden. Aber DU darfst natürlich meinen Trick ohne Lizenzgebühren nutzen.
... und bitte schreibe, wenn Du meinen Trick anwendest, immer dazu ©oberallgeier bzw: oberallgeieralgorithmus *ggggg* - aber nur wenn Du Zeit und Platz dazu hast.
Ciao sagt der JoeamBerg
Ich hab mal eine liste für 20MHZ gemacht, welche Baudraten mit den möglichen UBRR-Werten (im relevanten bereich) möglich sind
Code:UBRR Baudrate 12 96153,85 11 104166,67 10 113636,36 9 125000,00 8 138888,89 7 156250,00 6 178571,43 5 208333,33 4 250000,00 3 312500,00 2 416666,67 1 625000,00
mfg robert
Wer glaubt zu wissen, muß wissen, er glaubt.
Das funktioniert aber nur solange du keine temeraturdrift wie beispielsweise bei den internen R/C Oszillatoren hast. oder man müsste über OSCAL mit Sync ytes in der Kommunikation und Checksummen ständig nachregeln.
Das funktioniert genausolang, wie es mit einem Baudratenquarz und der korrekten Baudrate funktionieren würde.
Moin!
@thewulf00: Ist ja gut, jetzt sehe ich es auch, war doch grad erst aufgestanden....
@oberallgeier:
Den meinte ich :http://www.romanblack.com/one_sec.htm
Und für oberallgeieralgorithmus leg ich mir dann ein Tastaturmakro an
Einen Versuch ist es auf alle Fälle Wert!
MfG
Volker
Meine kleine Seite
http://home.arcor.de/volker.klaffehn
http://vklaffehn.funpic.de/cms
neuer Avatar, meine geheime Identität
Bei einer im Vergleich zum Systemtakt hohen Baudrate hat man das Problem, das man bei der USART nur ganzzahlige Werte für den Teiler einstellen kann. Man hat da also dann die Wahl zwichen ein paar Prozent zu hoch oder ein paar Prozent zu niedrieg. Da hilft dann auch keine andere Baudrate im Header, es sein denn die Gegenseite simmte auch nicht so ganz.
Das 2 te Problem ist, dass die Frequenz des internen Oszillators, nicht so genau ist. Da kann es dann helfen durch einen andere nominale Baudrate den richtigen Wert zu erreichen. Da hat man auch noch die alternative, elegantere Methode, den internen RC Oszillator mit dem OSCAL wert auf die richtige Frequenz zu bringen. Die kleine Verstimmung via OSCAL könnte man zumindestens ausnutzen, um die Rundungsproblem oben zu umgehen. Wenn ein 1 MHz Takt halt nicht geht für 19200 Baud, dann könnten 1.05 MHz eventuell gehen.
Der internen Takt ist aber leider abhängig von der Temperatur und Versorgungsspannung. Wenn die also stärker schwanken, kann man Probleme kriegen.
Der interne Oszillator bei den alten (z.B. At90S...) Chip war von der Tendenz her genauer als bei den neuen. Einige Sachen die früher mit dem internen Takt gingen gehen bei den neuen Chips eventuell nicht mehr zuverlässig.
Moin moin allerseits.
Ich habe vor langer Zeit einmal auf einen Pic eine veriable Baudrate
realisiert. Dazu mußte die Gegenstelle z.B. PC aber als erstes Byte
ein Hex F0 senden.
Ich habe dann einfach das Startbit abgewartet und dann auf die
Steigende Flanke von 1111_0000 gewartet und die Zeit gezählt.
Die Zeit / 4 /2 dann als Verzögerung fürs Einlesen/Senden damit
immer in der Mitte eines Bits gelesen wird. Das hat gut geklappt.
War natürlich in Assembler und hier nicht wirklich Pracktisch.
Aber man könnte auf diese Art einmal ein Byte + Start +Stop,
z.B. FF einlesen und die Zeit ermitteln. Dann kann man die
"echte" Baudrate/Abweichung errechnen.
Obwohl, solange ich mit einen externen Quarz arbeite klappt
das bei mir bisher. Intern ist echt Sch......
Grüße Richard
Berechtigungen
Zitieren
Lesezeichen