Hi, ich arbeite mich gerade ein bisschen in den ATMega16M1 ein und habe hier [1] einen code für den uart gefunden. Der Code funktioniert auch problemlos, allerdings wird dort die baudrate für 19200 baud durch setzen von LINBRR=12 erreicht. LINBTR ist Standartmäßig 32 damit komme ich durch die formel im Datenblatt [2] BAUD = fclk / LBT[5..0] x (LDIV[11..0] + 1) auf 20779 Baud, was immerhin fast 8% daneben liegt. Ich habe mir ein kleines tool geschrieben und komme damit darauf, dass mit BRR=13 schon 19184 baud erreicht werden(0,08% daneben), hab ich einen denkfehler, oder warum nimmt man nicht BRR=13 oder eine der 8 weiteren BTR/BRR kombinationen mit dieser geringen abweichung? Gruß, Marc [1] http://www.avrfreaks.net/forum/atmega16m1-full-duplex-uart [2] http://www.atmel.com/images/doc8209.pdf
Marc S. schrieb: > hab ich > einen denkfehler Ich glaube eher nicht, aber ich arbeite nicht mit Atmega und habe daher nicht nachgerechnet, aber grundsätzlich: 1. Es ist ok, Code zu kopieren, aber dann muss man ihn verstehen, da hast du nichts falsch gemacht (Lob!). 2. Es gibt keine Garantie, dass Code aus dem Internet gut oder korrekt ist. 3. Im vorliegenden Fall, mit 8% Fehler, wird der Code wohl i.A. funktionieren, es ist bloss nicht so gut wie er sein könnte. Daran ist nichts Erstaunliches, damit ist er schon besser als viele andere Code-Snippets. 4. Am besten: Messen. Mit einem guten Oszi sollte man 8% Abweichung schon feststellen können. Georg
Georg schrieb: > 3. Im vorliegenden Fall, mit 8% Fehler, wird der Code wohl i.A. > funktionieren, Bei 8% Fehler würde es mich wundern. Da liegt man bei den letzten Bits im Byte weit neben dem Zeitpunkt, zu dem gesampelt wird. Immerhin kumulieren diese 8% für jedes Bit im Byte, Startbit inklusive.
Obacht: LINBRR=12 entspricht einem Teiler von 13. Was bei LINBTR=32 und 19200bd zu ziemlich auf 8MHz passt.
:
Bearbeitet durch User
Marc S. schrieb: > BAUD = fclk / LBT[5..0] x (LDIV[11..0] + 1) auf 20779 Baud, was immerhin > fast 8% daneben liegt. Um das nachrechnen zu können, müßte man die µC-Taktfrequenz kennen oder übersehe ich da irgendetwas. 8% Frequenzfehler summieren sich im letzten Bit auf eine Verschiebung der Abtastungen von 80% der Bitbreite, d.h. eine Abtastung, die normalerweise in der Bit-Mitte (50%) liegen soll, landet weit im folgenden/vorhergegenden Bit. A. K. schrieb: > Nicht ungewöhnlich ist jedoch für solche Timer, dass ein > Registerwert 12 einem Teilerfaktor von 13 entspricht. In der Formelschreibweise würde das dann wohl eine Addition von 1 bedeuten, also z.B. "(LDIV[11..0] + 1)" ;-)
W.A. schrieb: > Marc S. schrieb: >> BAUD = fclk / LBT[5..0] x (LDIV[11..0] + 1) auf 20779 Baud, was immerhin >> fast 8% daneben liegt. > > Um das nachrechnen zu können, müßte man die µC-Taktfrequenz kennen oder > übersehe ich da irgendetwas. Stimmt! Im Moment läuft er noch mit dem internen 8MHz Also baud=8000000/(32*12+1)=20779 Georg schrieb: > 1. Es ist ok, Code zu kopieren, aber dann muss man ihn verstehen, da > hast du nichts falsch gemacht (Lob!). > > 2. Es gibt keine Garantie, dass Code aus dem Internet gut oder korrekt > ist. Meist benutze ich sowas um zu testen ob eine neu aufgebaute Schaltung funktioniert, dann brauche ich nicht zu suchen obs an meinem code oder am Aufbau liegt! Wenn dann alles klappt wird selber programmiert :) wenn ich den UART im griff hab kommt ein UART bootloader, dann ein can bootloader ;) > 3. Im vorliegenden Fall, mit 8% Fehler, wird der Code wohl i.A. > funktionieren, es ist bloss nicht so gut wie er sein könnte. Daran ist > nichts Erstaunliches, damit ist er schon besser als viele andere > Code-Snippets. Ja es läuft ja grundsätzlich, aber beim lesen des Datenblatts wurde ich dann stutzig ;) > 4. Am besten: Messen. Mit einem guten Oszi sollte man 8% Abweichung > schon feststellen können. Steht morgen an :)
Marc S. schrieb: > Also baud=8000000/(32*12+1)=20779 Versuchs mal mit 8000000/(32*(12+1))=19231. Die Klammern sind nicht nur zur Dekoration da.
:
Bearbeitet durch User
A. K. schrieb: > Marc S. schrieb: >> Also baud=8000000/(32*12+1)=20779 > > Versuchs mal mit 8000000/(32*(12+1)). Die Klammern sind nicht nur zur > Dekoration da. Tatsache, irgendwie hab ich mir die ganze Zeit eingebildet die Klammer ginge weiter vorne auf. Dann hat man ja genau die 13 die ich auch als optimal ausgerechnet hab :)
Marc S. schrieb: > atsache, irgendwie hab ich mir die ganze Zeit eingebildet die Klammer > ginge weiter vorne auf. In der Formel im Datenblatt wird extra nur ein einziges rundes Klammernpaar verwendet, damit man sich nicht so leicht vertun kann ;-) Bei der Angabe 8000000 für die Taktfrequenz entspringen fünf Nullen der reinen Phantasie. Den Wert soll man, insbesondere bei wechselnder Chip-Temperatur nicht überbewerten.
Angehängte Dateien:
-
Bild01.PNG
15 KB -
Bild02.PNG
41 KB
Marc S. schrieb: > Im Moment läuft er noch mit dem internen 8MHz > Also baud=8000000/... W.A. schrieb: > Bei der Angabe 8000000 für die Taktfrequenz entspringen fünf Nullen der > reinen Phantasie. Beim internen Oszillator darf man sich schon um die 0 gleich bei der 8 berechtigte Sorgen machen. Denn die gilt schon knapp nur bei 3,3V Versorgung und 25°C. Und bei den gern verwendeten 5V geht es schon auf die 8,1MHz zu. Dazu noch die im Datenblatt spezifizierten +1% und schon ist die 0 hinter der 8 Geschichte...
:
Bearbeitet durch Moderator
ich habe mein studium des datenblatts mal in ein kleines tool gegossen: Beitrag "ATMegaXXM1 Tool für Can und Uart" Danke nochmal für eure hilfe!
Hach ja, heute braucht man für ein wenig Schmierzettel-Rechnung ein "KLEINES" WIN-Tool, für das man LEIDER noch dieses und jenes Modul und vielleicht noch ein PlugIn braucht, um solche Trivialitäten herauszubekommen, die mit internen RC-Oszillator (7,3 bis 8,1 MHz) sowieso nur ZUFÄLLIG von Nutzen sein könnten, wenn man nicht auch noch das OSCCAL register mit einbezieht und die Sache im Winter und im Sommer funktionieren soll... Das bissel Optimierungsrechnung F-clk_io / LDIV[11..0] / LBT[5..0] kann man "zu Fuß" auf dem Papier, oder mit einer Excel-, oder Open-Office-Calc-Tabelle auch erreichen. Und wenn man mehr, als 1200 Baud haben will, ist nun mal eine quarzgenaue f_clk_io notwendig.
Jakob schrieb: > Hach ja, heute braucht man für ein wenig Schmierzettel-Rechnung > ein "KLEINES" WIN-Tool, für das man LEIDER noch dieses und > jenes Modul und vielleicht noch ein PlugIn braucht, es läuft sogar unter Linux unter theoretisch auch unter osx :) >um solche > Trivialitäten herauszubekommen, die mit internen > RC-Oszillator (7,3 bis 8,1 MHz) sowieso nur ZUFÄLLIG von > Nutzen sein könnten, wenn man nicht auch noch das OSCCAL register > mit einbezieht und die Sache im Winter und im Sommer funktionieren > soll... Zum Glück habe ich keine Nutzungsbedingungen zu dem tool geschrieben die die Verwendung eines externen quares o.ä. verbieten :) > Das bissel Optimierungsrechnung > F-clk_io / LDIV[11..0] / LBT[5..0] > kann man "zu Fuß" auf dem Papier, oder mit einer Excel-, oder > Open-Office-Calc-Tabelle auch erreichen. Stimmt aber das muss sich ja nicht jeder an tun. Vorallendinden wenn man mal die baudrate oder den Takt mal eben anpassen will. > Und wenn man mehr, als 1200 Baud haben will, ist nun mal eine > quarzgenaue f_clk_io notwendig. Das Thema hättest du schon.
Jakob schrieb: > Und wenn man mehr, als 1200 Baud haben will, ist nun mal eine > quarzgenaue f_clk_io notwendig. Seit wann sind relative Fehler frequenzabhängig? Es ist doch völlig schnuppe, ob ein 1200 Bd Zeichen 3% zu lang ist, oder eines bei 19200 Bd.
Bitte die Begriffe richtig verwenden! Auch wenn viele andere es falsch machen, wird es dadurch nicht richtig! Baud bezeichnet die Anzahl der ZEICHEN pro Sekunde, wobei nichtmal festgelegt ist, aus wievielen Bits diese Zeichen bestehen (auch wenn es meistens 8 sind). Baud/s gibts nicht, da ist die Sekunde schon drin! Bit/Sekunde ist nicht Baud, sondern tatsächlich Bits pro Sekunde und das ist es, womit seielle Schnittstellen konfiguriert werden. Ich weiss, dass selbst Chiphersteller den Begriff Baud oder Baudrate in ihren Unterlagen falsch verwenden, ist aber deshalb trotzdem nicht richtig.
:
Bearbeitet durch User
Frank E. schrieb: > Baud bezeichnet die Anzahl der ZEICHEN pro Sekunde Du meinst also ernsthaft, ein 1200-Baud-Modem überträgt 1200 Byte pro Sekunde? Da hast du wohl in der Ausbildung nicht richtig aufgepasst. Aber den Rest der Welt korrigieren wollen. Georg
Frank E. schrieb: > Bitte die Begriffe richtig verwenden! Auch wenn viele andere es falsch > machen, wird es dadurch nicht richtig! Ack > Baud bezeichnet die Anzahl der ZEICHEN pro Sekunde Baud bezeichnet die Anzahl der Symbole pro Sekunden. Je nach Übertragungsverfahren können pro Symbol mehrere Bits übertragen werden (Beispiel: 16-QAM übeträgt 4 Bit pro Symbol, i.e. Zeitschritt)
Georg schrieb: > Du meinst also ernsthaft, ein 1200-Baud-Modem überträgt 1200 Byte pro > Sekunde? Da hast du wohl in der Ausbildung nicht richtig aufgepasst. > Aber den Rest der Welt korrigieren wollen. > Ne, du (oder dein Lehrer) hat die Maßeinheit falsch verwendet.
Ich fand diesen Rechner zur Bestätigung meiner Thesen immer recht nett. http://wormfood.net/avrbaudcalc.php
A. K. schrieb: > Bei 8% Fehler würde es mich wundern Genau. Ich habe die exakten Werte der Specs nicht mehr im Kopf, aber ab 2,5% bis 3% wird es in der Praxis kritisch und je nach Exemplarstreuung funktioniert es dann oder eben nicht. Michael
Also bezüglich eines Modems liegen die Dinge etwas anders als bei einer einfachen seriellen Schnittstelle. Ein modernes Modem kann an der Extern-Schnittstelle mit einem Schritt (aufgrund spez. Modulationsverfahren) durchaus mehr als nur ein Bit übertragen, deshalb ist hier die Verwendung von "Baud" durchaus sinnvoll. An der seriellen Schnittstelle wird aber Bitweise übertragen, deshalb passt das hier mit Baud nur bedingt, da ist Bit/s üblich.
Frank E. schrieb: > Ne, du (oder dein Lehrer) hat die Maßeinheit falsch verwendet. Da geht der Ball aber sofort an dich zurück. Das ist völlig richtig: Wolfgang schrieb: > Baud bezeichnet die Anzahl der Symbole pro Sekunden. Je nach > Übertragungsverfahren können pro Symbol mehrere Bits übertragen werden > (Beispiel: 16-QAM übeträgt 4 Bit pro Symbol, i.e. Zeitschritt)
Frank E. schrieb: > An der seriellen Schnittstelle wird aber Bitweise übertragen, deshalb > passt das hier mit Baud nur bedingt, da ist Bit/s üblich. Es ist bei RS-232 praktisch ziemlich egal ob man von Bitrate oder von Baudrate redet, solange pro Schritt genau ein Bit übertragen wird ist beides äquivalent. Die Semantik der beiden Begriffe hebt allerdings einmal darauf ab, wie hoch die Frequenz der Übertragung ist (Baudrate) und einmal wie viele Daten man pro Zeitrate man übertragen kann (Bitrate), es sind also unterschiedlich Aspekte die damit gemeint sind. Für einen baudrate calculator spielt nur die Frequenz eine Rolle, nicht wie viele Bits auf einmal übertragen werden, daher würde ich diesen nicht als bitrate calculator bezeichnen. Da bei der Übertragungsgeschwindigkeit eigentlich eher der Durchsatz interessiert ist eher die cps rate (chars/second) interessant. Wie viele Bit/s übertragen werden bringt nur dann was, wenn man die Wortlänge und die Anzahl der Start-/Stopbits kennt. Michael
Thread beobachten
Seitenaufteilung abschaltenBitte 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.