Hi, ich denke der Betreff sagt schon alles. Danke für alle Antworten schonmal!
http://www.hanneslux.de/avr/tipps/baudratenquarz.html nur damit er seine Links nicht immer nur selbst werfen muss :-)) bye Frank
Um einen Takt von 14.7456 Mhz zu erzeugen! (deine eigentliche Frage dürfte sein: warum so was krummes und nicht einfach 15Mhz? Das liegt daran, dass sich z.B bei einem AVR-Mikrocontroller aus 14.7456Mhz ein guter Takt für die Baudrate der seriellen Schnittstelle erzeugen lässt, während bei 15MHz einige Prozent Abweichung entstehen können, sodass die Kommunikation nicht klappt.)
>>> sodass die Kommunikation nicht klappt
Die Kommunikation über ne serielle Schnittstelle klappt sehr wohl, auch
wenn man 15MHz statt 14.7456MHz nimmt. Rechenbeispiel 115200Baud: Faktor
128 zu 14.7456MHz, d.h. man hat 128 Quartzticks pro Bit. 10Bit
(Startbit, 8 Datenbit, Paritybit) entspricht also 1280 Quartzticks,
wenn die Quartzclock auf 15Mhz läuft hat man in der gleichen Zeit
1302ticks bekommen. Die Differenz ist gerade mal 22ticks, um nen Bit
fehlzuinterpretieren benötigt man einen Unterschied von 64 ticks. Das
klappt mit 'falschen' Quartzen auch bei hohe Baudraten ohne Probleme,
so ist das Protokoll ausgelegt.
Cheers
Detlef
schlaumeier.mit einem NICHT baudratenquarz hast du nicht alle üblichen Baudraten zur Auswahl.Hast wohl nur mit 9600 gearbeitet als du deine Modelleisenbahn getuned hast, wa? Träumer.
14.7456MHz zu 15MHz sind eine Abweichung von ca. 1.7% in der Clockfrequenz. Detlef_A liegt da sehr wohl richtig, dass die Kommunikation klappen KANN, die Reserven sind einfach nicht mehr allzu gut. Störungen bringen die Kommunikation so schneller aus dem Tritt, besonders bei den hohen Bitraten. @Pete Nerlinger: Du könntest dein Image hier mit fundierten Kommentaren besser aufpolieren. Was arbeitest du denn so dass du die Thematik so genau kennst?
I.d.R. nimmt man an, dass eine Abweichung in der Baudrate von unter 2% noch eine sichere Übertragung gewährleistet. In den AVR-Datenblättern steht für alle gebräuchlichen Baudraten und Quarzfrequenzen die Abweichung drin. BTW: Es wäre schön, wenn jemand diesem unverschämten Dummschwätzer-Troll Pete Nerlinger endlich mal das Maul stopfen könnte! So einen Ton muss sich auch in einem weitgehend anonymen Forum keiner bieten lassen...
Also, solange der Fehler unter 2% bleibt, habe ich noch nie Probleme gehabt 115200 kBaud zu verwenden. Ich meine mal irgendwo gelesen zu haben, dass sogar noch drei Prozent OK sind. In den PIC18 Dokumentationen werden z.B. für verschiedenen Quarze die zu erreichenden Übertragungsraten angegeben. In der Tabelle wird auch immer der Fehler mit angegeben. Ich verwende derzeit auch einen 15MHz Quarz für meinen LPC2103. Ich kann zwar nicht mit einem 14,7456MHz Quarz vergleichen, aber zumindest lässt sich die Programmiergeschwindigkeit bis 115200 steigern, und der Programmiervorgang wird mit jeder höheren Rate auch tatsächlich schneller. Da der LPC sich selber die richtige Geschwindigkeit sucht, glaube ich.
@johnny.m Gerade wegen der Anonymität wird das Maul-stopfen eben schwierig. Da hilft wohl nur: (aus der Wikipedia): -------------------------- /| /| | | ||__|| | Trolle bitte | / O O\__ nicht | / \ füttern! | / \ \ | / _ \ \ ---------------------- / |\____\ \ || / | | | |\____/ || / \|_|_|/ | __|| \ |____| || / | | /| | --| | | |// |____ --| * _ | |_|_|_| | \-/ *-- _--\ _ \ // | / _ \\ _ // | / * / \_ /- | - | | * _ c_c_c_C/ \C_c_c_c____________
@Klopapier Das beziet sich auf das Posting von Pete Nerlinger und die Bemerkung von johnny.m dazu. Ich meinte mich klar ausgedrückt zu haben, lasse mich aber gern korrigieren.
@Martin: Ist schon richtig, das ist das Problem. Aber bei manchen platzt einem halt irgendwann der Kragen, v.a. dann, wenn solche "Experten" Anfänger verunsichern... Werde auch net mehr füttern, versprochen;-)
TriTraTrollalla... > Ist schon richtig, das ist das Problem. Eigentlich nicht, wenn Niemand dazu Stellung nehmen würde. Beiträge wie: > nur damit er seine Links nicht immer nur selbst werfen muss :-)) provozieren Gedanken, ob es nicht besser wäre, still zu sein und sich zu freuen, dass man die Antwort kennt. Das ist zwar nicht meine Art, aber der Umgang formt den Menschen. ...
Zum Thema akzeptable Fehlerrate. Die hängt auch immer mit der Bitanzahl zusammen. 1 Start + 4 Datenbit sind halt erheblich toleranter als 1 Start + 9 Datenbit + 1 Paritybit Weil mir die Liste jetzt zu aufwendig ist verweise ich einfach mal auf das ATMega16 Datenblatt http://www.atmel.com/dyn/resources/prod_documents/doc2466.pdf Schaut dort mal auf Seite 161 in die Tabellen 61 und 62. Und dann sollte man noch beachten, das es durchaus unterschiedlich gute Taktgeber gibt (Stichwort Resonatoren usw.) cu Hauke
>1 Start + 4 Datenbit sind halt erheblich toleranter als >1 Start + 9 Datenbit + 1 Paritybit Wieso?
> Wieso?
Weil das Startbit das RX-Timing auf das TX-Timing synchronisiert und
diese Synchronisation bis zum nächsten Startbit reichen muss. Je
weniger Bits zum Rahmen gehören, desto schneller ist "man fertig",
ehe die Taktunterschiede Fehler prvozieren.
...
was habt ihr? ich hab recht, nur halt etwas "provozierend" gesagt. aber wie es in wald hinein schallt, so kommt es auch wieder herraus!
Es gibt übrigens noch einen anderen guten Grund für Baudratenquarze, der bisher nicht aufgeführt wurde: Man kann nämlich die Baudratenquarzfrequenzen per fortgesetzter Teilung durch 2 soweit reduzieren, dass man schließlich mit einem einfachen 8Bit-Timer einen glatten Sekundentakt erzeugen kann. Das gilt auch für die Frequenzen, die noch einen Faktor 3 drin haben, z.B. 11,0592MHz, denn die gehören zu der wohl mit Abstand größten Controllerfamilie (8048/8051), die als internen Takt den Quarztakt durch 6 verwendet. Mit einem Quarz mit glatten MHz ist es dagegen braucht man dagegen immer mindestens einen 16Bit-Timer oder einen frei einstellbaren Vorteiler, um einen glatten Sekundentakt zu erzeugen (z.B. 1,0MHz / 64 = 15625). @HanneS In Deiner Aufstellung sind die "klassischen" 2,4576 und 4,9512MHz nicht aufgeführt. Gibt es einen besonderen Grund dafür? Gruß Johannes
> In Deiner Aufstellung sind die "klassischen" 2,4576 und 4,9512MHz > nicht aufgeführt. Gibt es einen besonderen Grund dafür? Nein, es gibt keinen besonderen Grund dafür. Das sagt auch schon die Überschrift der Auflistung: "Einige mögliche und zum Teil übliche Baudratenquarzfrequenzen:" Also einige mögliche und übliche, nicht alle. Diesen Beitrag hatte ich eigentlich nur verfasst, weil ich es satt hatte, mehrmals die Woche dieselben Fragen beantworten zu müssen, warum die UART-Verbindung zum AVR nicht oder nur schlecht klappt. Somit hatte ich die Möglichkeit, einen Link auf die bereits gegebene Antwort zu setzen. Es sollte keinesfalls eine wissenschaftlich-theoretische Abhandlung werden, sondern nur ein gutgemeinter Praxis-Tip, mal über UART, Quarz, Baudrate und deren Zusammenhänge nachzudenken. Da es hier aber immer wieder Leute gibt, die behaupten, dass man für sicheren und zuverlässigen UART-Betrieb keinen Baudratenquarz braucht, werde ich mich mit diesem Hinweis zukünftig auch etwas zurück halten. Bit- & Bytebruch... ...HanneS...
Hi, @Martin Kohler (mkohler) > 14.7456MHz zu 15MHz sind eine Abweichung von ca. 1.7% in der > Clockfrequenz. Diese Abweichung ist aber für den Fehler bei der Baudrate nicht maßgeblich. Durch die möglichen Teilerwerte ist der Fehler nämlich für alle Baudraten unterschiedlich und liegt bis 19200 Baud z. B. unter 0,4 %. Darüber liegt er bei bis zu 2%.
Dieser Quartz wird dann benuetzt wenn der Chip keinen wirklich guten Baudratenegenerator hat. Es gibt allerdings echte Probleme wenn man z.B. USB, CAN und einen Chip ohne vernuenftigen Baudratengenerator hat. USB und CAN haetten gerne sowas wie 12 MHz und 16 MHz und eine kleine PLL, das ist allerdings nur vertraeglich mit 115200 oder hoeher, wenn ein sogenannter Fractional Baudrate Generator zur Verfuegung steht. Der generiert dann unterschiedliche Bitlaengen aber bleibt locker in der Spezifikation von weniger als 2% Abweichung. Also solange nur der UART gebraucht wird ist 14.756 ein wunderschoener Quartz, mit CAN allerdings schiesst man sich in den Fuss damit. Robert
@Thomas Sorry, aber das ist nur bedingt richtig, weil von der Größe des jeweils ohne weitere Pause gesendeten Datenblocks und des jeweiligen Controllers abhängig. So "klaut" der U(S)ART eines AVR dadurch, dass er zur Startbiterkennung drei Low-Samples um die Startbitmitte herum braucht, stets 1/16 (oder 1/8 bei Double-Speed) Bitzeit nach vorne. Weiterhin spielt die absolute Genauigkeit des Quarzes eine Rolle sowie seine Temperaturdrift (typische Computerquarze sind da nicht so genau). Und wenn tatsächlich gar kein Quarz, sondern ein Keramikresonator den Clock macht, sind gleich lockere 0,5% Grundabweichung und +-0,2 bis 0,3% Temperaturdrift drin. Und schließlich ist noch eine wichtige Frage, ob eine RS232-Verbindung (Punkt-zu-Punkt) oder ein halbduplex RS485-Bus vorliegt. Von oben nach unten werden immer größere Anforderungen an die Synchronisierung gestellt, die praktisch nur durch eine angemessene Verlängerung des Stopbits aufgefangen werden können. Es hat schon seinen Sinn, dass sich das gute alte Telex nie mit nur einem einzigen Stopbit zufrieden gegeben hat, sondern mindestens 1,5 Bitzeiten dafür verlangt. Und auf einem RS485-Bus soll sogar jeder Sender erstmal mehr als eine Bytezeit Dauerhigh ver(sch)wenden, um den/die jeweiligen Empfänger aus dem möglichen Dauerlow (=Break) aufwachen zu lassen... @HanneS Ich hab den Eindruck, dass ich Dir irgendwie (zu?) nahe getreten bin. Tut mir leid, das war nicht meine Absicht. Gruß Johannes
Vielleicht noch ein nützlicher Hinweis?!? Mit dem Codevision Code Wizard kann man die Frequenz und die Baudrate angeben und man kriegt den Fehler in Prozent angezeigt. Dann muß man nicht selber rechnen oder in Tabellen schauen. Sollte auch mit der kostenlosen Eval Version funktionieren?!?
> Ich hab den Eindruck, dass ich Dir irgendwie (zu?) nahe getreten > bin. > Tut mir leid, das war nicht meine Absicht. Nein, bist Du nicht. Das die von Dir genannten Quarze "Klassiker" sind, ist/war mir auch nicht bewusst. Und da mir diese Frequenzen in Verbindung mit AVRs noch nicht begegnet sind, werde ich sie vorerst auch nicht in die Liste aufnehmen. Die Bemerkung, dass ich mich bei UART-Fragen etwas zurückhalten werde, hat auch nichts mit Dir zun tun, sondern mit den UART-Threads der vergangenen Monate. Denn immer wieder findet sich Jemand, der behauptet, dass es bei ihm auch ohne Baudratenquarz funktioniert. Aber auch einige sehr kompetente Leute nehmen zu diesem Thema keine Stellung mehr. Bit- & Bytebruch... ...HanneS...
Ist doch auch kein Wunder. Warum sollte man auch dasselbe immer und immer wieder schreiben? Der Sachverhalt ist doch auch recht einfach. Wenn man möglichst genaue Taktraten haben will, dann nutzt man eben die krummen Quarze. Klar geht es auch mit fast beliebigen anderen Quarzen aber da verlässt man sich dann wohl sehr darauf dass das Gegengerät eben fehlertolerant genug ist, was es ja in vielen Fällen auch ist. Im Zusammenspiel mit nem PC gibts ja auch selten Schwierigkeiten aber wenn man z.B. an irgendwelche Industriemaschinen ran muss, sieht das manchmal schon ganz anders aus. Soll das doch Jeder machen wie er will, Er wird schon feststellen ob es funktioniert oder eben nicht. bye Frank
>Er wird schon feststellen ob es funktioniert oder eben nicht
Das schon, aber wenn es darum geht, warum es nicht geht, dann ist das
Geheule im Forum groß.
Es wird aber niemand gezwungen, auf irgendwelche Threads zu antworten.
Am besten finde ich in solchen Fällen immer, wenn jemand aus einem
Ingenieurbüro seine Meinung vertritt, dass der interne RC-Oszillator
für solche Sachen genau genug sei...
>>> 14.7456MHz zu 15MHz sind eine Abweichung von ca. 1.7% in der >>> Clockfrequenz. >> Diese Abweichung ist aber für den Fehler bei der Baudrate nicht >> maßgeblich. > Sorry, aber das ist nur bedingt richtig, weil von der Größe des > jeweils ohne weitere Pause gesendeten Datenblocks und des ... Die Abweichung zwischen zwei Quarzen ist nicht allein das entscheidende Kriterium für die Abweichung der Baudrate. Die Abweichung kommt im wesentlichen durch die nur diskret möglichen Teilerwerte der folgenden Teilerkette zustande. Diese Aussage ist richtig und hat mit allen weiteren von dir aufgezählten Fehlerquellen absolut noch gar nichts zu tun. Fakt ist, dass z. B. mit einem AVR und dem darin befindlichen Teiler bei 15 MHz und 19200 Baud ein reiner Baudratenfehler von etwas unter 0,4 % zustande kommt und das dieser Wert offensichtlich unterschiedlich zu den 1,7 % Abweichung der nominalen Quarzfrequenzen ist, muss doch nicht weiter belegt werden. Das hat mit Datenblöcken, Temperaturdrift und Erdstrahlen noch nichts zu tun... Gruß, Thomas
Fakt ist nunmal,das man mit dem internen R/C-Osszillator und etwas Handtuning am UBR mit jedem AVR eine Übertragung mit 9600 Baud zum laufen bekommt.Und wenn sich die Erfahrung auf 1x am STK500 rumspielen beschränkt,erscheint das als eine brauchbare Lösung. Und genau diese Leute fangen dann an wild herum zuraten,wenn sie die selbe Software auf einen anderen AVR flashen und es dann nicht funktioniert.("Ist doch selbe Hardware und selbe Software,ist mein AVR kaputt?") Ich finde Hannes-Seite ist gut gemacht und prima zum lernen geeignet.Wer keine Hilfe annehmen will,ist dann selber schuld wenn er es sich schwerer als nötig macht. Nur bevor man dann anderen derartige Halbwarheiten in einem Forum übermittelt,sollte man vielleicht erstmal einige Erfahrungen mit konkreter Hardware sammeln.
>sollte man vielleicht erstmal einige Erfahrungen mit >konkreter Hardware sammeln. Wann ist das der Zeitpunkt? >1x am STK500 rumspielen Da betrachten sich manche schon als Experten... Es wird immer Leute geben, die es "besser" wissen. Denen muß man dann gelegentlich entgegen wirken (manchmal gehöre ich auch dazu...). Manche begreifen es dann, andere darf man dann als "Troll" betrachten... Prometeus lässt grüssen...
Der butterfly von ATMEL läuft auf internem RC-Generator. Dessen Frequenz läßt sich prima mithilfe des ebenfalls vorhandenen 32.768 kHz Uhrenquarz messsen. Vielleicht bißchen OT. Cheers Detlef
Yep, wenn du einen genauen Takt als Referenz hast, ist der RC-Osz problemlos verwendbar, weil sich der dann im Betrieb automatisch kalibieren lässt.
Ja, klasse, das werd ich mal meinem Chef und dem nächsten Kunden vorschlagen: "Leute, nehmt einfach irgendeinen Keulen-AVR mit zweitem Oszillator und einen Uhrenquarz, dann kriegen wir immer einen sauberen Baudratentakt hin... Zugegeben, die benötigen >8 MHz für die CPU sind dann nicht drin, und mit dem angepeilten Tiny kommen wir auch nicht hin, aber wir haben immerhin eine halbe Lösung zum doppelten Preis!" Ist doch auch was, oder? Ich höre schon den Applaus für diese geniale Idee...
Joahannes, möglicherweise hast Du die Idee nicht begriffen. Gute Nacht. Detlef
Detlef, welche Idee meinst Du? Die, mit der man den internen Calibrated-RC-Clock hinreichend genau für einen sowohl Baudrate- als auch Sekundentakt auf >16MHz zwiebeln kann? Und das nicht nur mit dem Mega169 des Butterfly, sondern auch mit einem, sagen wir, Tiny2313? Die hab ich tatsächlich nicht begriffen. Sag sie mir! Ebenfalls Gute Nacht Johannes
>Re: Wofür braucht man 14.7456 Mhz Quarz?
Mancheiner baut daraus eine Spange oder Brosche für seine Frau/Freundin
(oder beide).
@Johannes: Das könnte was mit dem Stromverbrauch zu tun haben...
James Krüss: Dann entsteht zwar ein Gedicht, aber sinnvoll ist es
nicht...
@Johannes: Ich habe nur erklärt, warum das beim Butterfly funktioniert. Dessen 32KHz-Takt dient ja nicht in erster Linie dem Abgleich der Baudrate, sondern weil darin permanent eine Uhr auf Batterie läuft und der Power-Save Mode der Weg des minimalem Stromverbrauchs ist. Unterhalb vom Mega8 geht das mangels zweiten Osziallators sowieso nicht.
Ich denke, man sollte die 2% Reserven auf die der serielle Bus meist spezifiziert ist nicht daruch aufgeben, daß man die Grundfrequenz einseitig in die Ecke fährt. Gerade in Controllern kommt ja auch noch die dynamische Reaktion auf Interrupts hinzu, sodaß man da einen Abtast-Jitter erhält und schon mal rasch aus dem Fenster rutscht.
@Jürgen: Der Jitter tritt nur bei Software-UART in Erscheinung, und auch nur wenn nicht ein USI oder so dabei mithilft.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.