Hallo, eigentlich wollte ich vom ATtiny841 den internen Oszillator verwenden. Nun habe ich im Wiki gelesen, dass man einen externen Quarz nehmen soll, wenn man die UART verwendet. Wegen Baudratenfehlern. Nur hat doch der 841er einen stabilisierten internen Taktgeber laut Datenblatt. Also, Quarz unbedingt notwendig oder nicht? Ich bin derzeit verunsichert was ich machen soll. Die UART soll mit 115kB/s betrieben werden oder noch schneller, soweit möglich. Auf der anderen Seite hängt ein µC mit 16MHz Resonator. Wenn ja, macht es Sinn einen Baudratenquarz zu nehmen, wenn das Gegenüber keinen hat. Wie läuft die Taktsyncronisierung überhaupt ab, wenn alle µC die später am Bus hängen immer leichte Taktabweichungen untereinander haben? Da muß doch die UART Funktionseinheit sich auf das gegenüber einstellen können. Los gelöst vom eigenen internen Takt.
:
Bearbeitet durch User
du kannst den Tiny ja auch Kalibrieren. z.b. anhand vom dem externen UART Daten. Die Oszillator sind zwar stabil aber nicht zwingend genau. > Wie läuft die Taktsyncronisierung überhaupt ab, wenn alle µC die später > am Bus hängen immer leichte Taktabweichungen untereinander haben? Da muß > doch die UART Funktionseinheit sich auf das gegenüber einstellen können. > Los gelöst vom eigenen internen Takt. beide Teinehmer müssen das gleiche Wissen darüber haben wie lange ein bit ist. Welcher Geschwindigkeit das "wirklich" entspricht spielt keine rolle. Du kannst also auch mit 9600baud (nach Datenblatt) und einen falschen Quarz stabil Daten übertragen, wenn die gegenstelle denn gleichen falschen Quarz hat.
Veit D. schrieb: > Da muß doch die UART Funktionseinheit sich auf das gegenüber einstellen > können. Das macht sie über die Erkennung der Flanke des Startbits. Der maximale Fehler ist folglich auch dadurch limitiert, wie weit sich beide über die 10 Bits (bis zum Stopbit) voneinander zeitlich entfernt haben. Summa summarum, normalerweise genügt der interne RC-Oszillator der AVRs für UART, aber es ist eben nicht über den Temperaturbereich und über Exemplarstreuungen garantiert.
Datenblatt Table 25-2. Calibration Accuracy of Internal 8MHz Oscillator: Factory Calibration 2.7 - 4.0 V, 0 °C - 85 °C: 2 % Das sollte doch reichen, oder?
S. Landolt schrieb: > Das sollte doch reichen, oder? oder auch nicht http://www.mikrocontroller.net/articles/AVR-Tutorial:_UART [...] Außerdem muss bei der Berechnung von UBRR geprüft werden, ob mit der verwendeten Taktfrequenz die gewünschte Baudrate mit einem Fehler von <1% generiert werden kann. Das Datenblatt bietet hier sowohl die Formel als auch Tabellen unter der Überschrift des U(S)ART an. [...]
S. Landolt schrieb: > Das sollte doch reichen, oder? Ja, 2 % sollten genügen. Das ist die übliche Toleranz, die man für RS-232 als akzeptabel nimmt. Allerdings muss man natürlich den systematischen Fehler dabei mit einbeziehen, sofern man den nicht durch Kalibrierung des RC-Oszillators auf eine „baudratenfreundliche“ Frequenz eliminiert.
> ...systematischen Fehler...
Das stimmt, die 8 MHz lassen sich mit den oben genannten 115.2 kBd
schlecht vereinbaren. Da aber nur mit einem anderen uC kommuniziert
werden soll, ist man ja relativ unabhängig.
S. Landolt schrieb: > Das sollte doch reichen, oder? Um es mit Radio Eriwan zu sagen: Es kommt darauf an. <dicker-daumen> Ein Byte dauert 10 Bit. Am Ende des Bytes darf der zeitliche Versatz maximal ein halbes Byte betragen, weil unser UART nur einmal, nämlich in der Mitte des Bits, abtastet. Macht nach Adam Riese 5% zulässigen Fehler. <dicker-daumen/> Den Fehler müssen wir verteilen auf die Taktfrequenz und den nicht optimalen Teilerfaktor. Wenn es uns gelingt, eine Baudrate zu finden, bei der der Teilerfaktor ganzzahlig ist, können wir alles für den Fehler des Oszillators einsetzen. Und noch etwas müssen wir bedenken: Auch der Partner ist unter Umständen nicht optimal im Takt. Wenn das auch nur ein RC-Oszillator ist, wird es etwas enger. Zurück nach Kölln: Et it noch immer jot jejange.
Georg G. schrieb: > Ein Byte dauert 10 Bit. Am Ende des Bytes darf der zeitliche Versatz > maximal ein halbes Byte betragen Bit, nicht Byte. ;)
Veit D. schrieb: > eigentlich wollte ich vom ATtiny841 den internen Oszillator verwenden. > Nun habe ich im Wiki gelesen, dass man einen externen Quarz nehmen soll, > wenn man die UART verwendet. Wegen Baudratenfehlern. Nur hat doch der > 841er einen stabilisierten internen Taktgeber laut Datenblatt. > Also, Quarz unbedingt notwendig oder nicht? Das kommt d'rauf an. Hauptsächlich darauf, mit welchen Schwankungen der Umgebungstemperatur du in deiner Anwendung rechnen musst, aber auch (in weit geringerem Maße) darauf, mit welchen Schwankungen der Versorgungsspannung. Die entsprechenden Diagramme stehen, wer hätte es vermutet, natürlich im Datenblatt... > Ich bin derzeit verunsichert was ich machen soll. > Die UART soll mit 115kB/s betrieben werden oder noch schneller, soweit > möglich. Auf der anderen Seite hängt ein µC mit 16MHz Resonator. Nimm einen Quarz. Das spart dir einen Haufen Probleme, die du mit deinem Kenntnisstand nicht lösen kannst. > Wenn ja, macht es Sinn einen Baudratenquarz zu nehmen, wenn das > Gegenüber keinen hat. Gerade dann. Jedenfalls wenn du keine Kenntnisse über das Innenleben des Peers hast oder gar Kontrolle darüber ausüben kannst. > Wie läuft die Taktsyncronisierung überhaupt ab, wenn alle µC die später > am Bus hängen immer leichte Taktabweichungen untereinander haben? Garnicht. Es gibt bei einer UART keine Taktsynchronisation, genau das ist ihr Trick (z.B. gegenüber SPI), deswegen braucht sie keine Taktleitung. Alles, was es gibt, ist eine einmalige (pro Datenwort) Synchronisation auf eine Flanke des Taktes. Das passiert an der Grenze zwischen IDLE-Zustand und Startbit. Und dafür, dass es immer einen IDLE-Zustand vor einem Startbit gibt, dafür sorgt das oder die Stopbit(s). Das ist nix anderes als die Definition einer Mindestdauer für den IDLE-Zustand.
Hallo, Danke für die Nachhilfe. Wie beim SPI wäre es doch eigentlich für alle einfacher. Da hier der Takt mitgeschickt wird. Es gäbe keine Abweichungen. Man müßte auf nichts achten. Ich fasse zusammen. Man kann es mit dem internen probieren. Vermutlich klappt es nicht stabil genug auf Dauer. Zum nachkalibrieren fehlen mir die Mittel. Besser wäre ein externer Quarz. Hier könnte ich gleich einen Baudraten-Quarz verwenden um den Fehler so klein wie möglich zu halten. Der andere µC kann sein 16MHz Resonator behalten?
Wenn sonst nichts dagegen spricht, würde ich die Kommunikation auf z.B. 250 kBd einstellen und den internen Oszillator des ATtiny841 verwenden, dieser ist ab Werk hinreichend genau und stabil.
Hallo, gibt es auch Baudraten Resonatoren? Dann könnte ich den einen austauschen. Habe bisher nur Quarze gesehen.
:
Bearbeitet durch User
Veit D. schrieb: > Zum nachkalibrieren fehlen mir die Mittel. was meinst du damit? Ist doch nur eine Software frage.
S. Landolt schrieb: > Wenn sonst nichts dagegen spricht, würde ich die Kommunikation auf z.B. > 250 kBd einstellen und den internen Oszillator des ATtiny841 verwenden, > dieser ist ab Werk hinreichend genau und stabil. Aber nur, wenn sonst nichts, auch nicht das bisher diskutierte, dagegen spricht. Wenn es dann nicht geht, muß man doch etwas anderes machen, weil das Werk vielleicht doch nicht hinreichend genau war oder/und es mit dem 16MHz des anderen µC nicht paßt.
Veit D. schrieb: > Wie beim SPI wäre es doch eigentlich für alle einfacher. Da hier der > Takt mitgeschickt wird. Nur nicht für den "Strippenzieher", denn der muss eine Leitung mehr ziehen. Aber d'rauf geschissen. Das Ding beim AVR heisst ja nicht UART, sondern USART. D.h.: wenn deine Anwendung sagt, es wäre cleverer zusätzlich den Takt zu übertragen, dann kannst du auch das machen, weil die USART auch einen synchronen Modus unterstützt. Bloß muss dann halt auch der Peer dazu in der Lage sein... > Ich fasse zusammen. Man kann es mit dem internen probieren. > Vermutlich klappt es nicht stabil genug auf Dauer. > Zum nachkalibrieren fehlen mir die Mittel. > Besser wäre ein externer Quarz. Hier könnte ich gleich einen > Baudraten-Quarz verwenden um den Fehler so klein wie möglich zu halten. Ja. Wobei vor "Fehler" das Wörtchen "systematisch" zu ergänzen wäre... Und was das Kalibrieren angeht: Da fehlen dir wohl nicht die Mittel (AVR und Quarz hast du ja offensichtlich bzw. kannst du leicht beschaffen), sondern eher nur die Fähigkeiten... > Der andere µC kann sein 16MHz Resonator behalten? Wen du das Glück hast, dass der sich an die Standards hält (wie auch immer er das intern realisiert): Natürlich! Ja! Das genau ist der Sinn von Standards... Und wenn er das nicht kann, kannst du wenigstens nachweisen, dass der Peer Schuld ist. Auch das ist der Sinn von Standards. Bei Inkompatibilitäten möglichst klären zu können, wer Schuld ist.
Hallo, reine Software zum kalibrieren? Ich dachte jetzt man benötigt einen Referenztakt zum Abgleich. Hast du einen Link zur einer solchen Software, falls Freeware? Wegen Takt und Abweichung zur UART. Hab mal ins Datenblatt geschaut. http://www.atmel.com/Images/Atmel-8495-8-bit-AVR-Microcontrollers-ATtiny441-ATtiny841_Datasheet.pdf Seite 179. Der interne Oszillator läuft ja mit 8MHz. Falls meine Verbindung mit 250kBaud läuft, wäre der Fehler doch 0%. Würde wunderbar passen. Oder nicht? Das nächst kleinere wäre 38,4kBaud
Veit D. schrieb: > Ich dachte jetzt man benötigt einen Referenztakt zum Abgleich. hast du ja, die Gegenstelle. Die kannst die Bit-zeit der Gegenstelle messen und den Teiler so einstellen, das die gleich bist. Schon kannst du mit der gegenstelle Daten austauschen. Recht einfach geht das, wenn die Gegenstelle etwas sendet ohne das du vorher etwas hinschicken musst.
> Das nächst kleinere wäre 38,4kBaud Wenn Sie auf Standard angewiesen sind, ja. Ansonsten steht es Ihnen doch frei, auch z.B. 125 kBd zu verwenden. > gibt es auch Baudraten Resonatoren? Wenn es schon etwas Externes sein soll, weshalb kein Quarz?
Veit D. schrieb: > reine Software zum kalibrieren? > Ich dachte jetzt man benötigt einen Referenztakt zum Abgleich. Genau. Und den kann man mit einem AVR mit Quarz wirklich spielend leicht erzeugen, jedenfalls mit einer für den Zweck der Kalibrierung eines AVR mit RC-Oszillator völlig hinreichenden Genauigkeit der Referenz. Man kann aber natürlich auch völlig andere Taktquellen als Referenz benutzen, z.B. USB-Frames eines PC o.ä. Der Vorteil der selbst produzierten Referenz ist, dass man sie sehr leicht an die verfügbare Rechenleistung des zu kalibrierenden Ziels anpassen kann. > Der interne Oszillator läuft ja mit 8MHz. > Falls meine Verbindung mit 250kBaud läuft, wäre der Fehler doch 0%. Ja. Der systematische Fehler wäre dann 0. Und natürlich würde man, wenn diese Daten gelten, auf der anderen Seite keinen "Baudratenquarz" verwenden, sondern ebenfalls einen, dessen Nominalfrequenz ein ganzzahliges Vielfaches von 250000 ist, wobei das Vielfache mindestens 8, besser 16 sein sollte. Also minimal entweder 2MHz oder 4MHz. Oder eben Vielfache davon, wenn die höhere Rechenleistung benötigt wird.
Hallo, hab weitergelesen. Wenn man den ATtiny, in meinem Fall, mit 5V betreibt, dann triftet der interne Takt deutlich ab. Man kann nur sinnvoll kalibrieren wenn man max. 3,3V Ub anlegt. Richtig verstanden? Resonator, finde nur welche mit 7,37MHz. Wenn laut Datenblatt mit 250kBaud der Fehler 0% beträgt mit 16MHz, dann wäre das doch ideal. Oder? Kalibrierung. Wenn ich das richtig verstehe, läßt man ein Pin toggeln und misst mit Oszi die Frequenz und ändert das OSCCAL Register solange bis man einen Baudraten taugliche Frequenz hat. Zum Bsp. nahe der 7,37MHz. Oder man vergleicht mit der PC Frequenz. Die Frage wäre wie genau ist diese. Nur wie oben schon gelesen, nur bis 3,3V Ub sinnvoll.
:
Bearbeitet durch User
Veit D. schrieb: > hab weitergelesen. Wenn man den ATtiny, in meinem Fall, mit 5V betreibt, > dann triftet der interne Takt deutlich ab. Man kann nur sinnvoll > kalibrieren wenn man max. 3,3V Ub anlegt. Richtig verstanden? Nein. Die Kalibrierung erfolgt sinnvollerweise mit genau der Spannung und Temperatur, die im Mittel bei der Zielanwendung vorliegt. Wobei das "Mittel" hier nicht unbedingt das arithmetische Mittel sein muss. Welches Mittel am sinnvollsten ist, kann man wiederum den weiter oben bereits erwähnten Diagrammen im DB entnehmen und dem eigenen Verständnis für die Bildung der verschiedenen denkbaren Mittelwerte... > Kalibrierung. Wenn ich das richtig verstehe, läßt man ein Pin toggeln > und misst mit Oszi die Frequenz und ändert das OSCCAL Register solange > bis man einen Baudraten taugliche Frequenz hat. Zum Bsp. nahe der > 7,37MHz. So in etwa darauf läuft es hinaus. Man nimmt einfach den OSCAL-Wert, bei dem der Messwert der Kalibrierung die minimale absolute Abweichung vom Erwartungswert aufweist.
Hallo, okay, ich glaube jetzt habe das gerafft. Ansonsten frage ich nochmal nach. Ach'so. Letzte Frage für heute. Die Kalibrierwerte im OSCCAL Register gelten nur für den internen Oszillator. Sobald ein externes Quarz/Resonator angeschlossen wäre und benutzt, spielt das keine Rolle mehr und man könnte damit auch nicht fein tunen?
>Die Kalibrierwerte im OSCCAL Register >gelten nur für den internen Oszillator. Nur dafür.
Hallo, okay, vielen vielen Dank an alle. Soweit ist es jetzt für mich verständlich gewurden.
holger schrieb: >>Die Kalibrierwerte im OSCCAL Register >>gelten nur für den internen Oszillator. > > Nur dafür. Leider ist das nicht ganz wahr. Bei den allermeisten AVR wird das interne Timing für die Programmierung von Flash und EEPROM aus eben diesem Takt des internen RC-Oszillators abgeleitet. Und die zuverlässige Funktion dieser Sachen ist leider recht eng daran gebunden, dass der Nominaltakt des RC-Oszillators nicht nennenswert überschritten wird. D.h.: sobald man in der Anwendung Schreibzugriffe auf Flash oder EEPROM hat, muss man sich einen Kopp machen, zumindest wenn man den RC-Oszillator deutlich nach oben tuned. Das ist besonders dann bedenkenswert, wenn man das Ergebnis einer Kalibrierung sinnvollerweise in's interne EEPROM schreiben will, um es beim nächsten PowerUp ohne Kalibrier-Referenz daraus lesen zu können. Alles nicht so einfach...
Die Kalibrierung des R/C Oszillator ist ganz leicht mit avrdude zu erledigen. Auszug aus der Manual Page: -O Perform a RC oscillator run-time calibration according to Atmel application note AVR053. This is only supported on the STK500v2, AVRISP mkII, and JTAG ICE mkII hardware. Note that the result will be stored in the EEPROM cell at address 0. Danach muss dein Programm lediglich den Wert von dieser Eeprom Zelle in das OSCCAL Register kopieren.
Ich würde es nicht mit der internen Tick-Tack versuchen. Schon gar nicht mit 115200 Baud. Das Handbuch behauptet: 8,5% Fehler bei 8MHz. Wenn dann noch eine Ungenauigkeit von 2% durch "schlechtes Wetter" hinzukommt... Anders ausgedrückt: 8MHz reichen nicht für diese Baudrate.
Sebastian S. schrieb: > Das Handbuch behauptet: 8,5% Fehler bei 8MHz. und was ist mit der spalte daneben? U2Xn = 1 -3.5%
> Die UART soll mit 115kB/s betrieben werden oder noch schneller Vergiss das ohne Quarz. Ich hab das damals probiert, als ich mit den AVRs angefangen habe. Keine Chance eine stabile Kommunikation hinzukriegen. Selbst mit einem ungeeigneten Quarz sind solche hohen Baudraten schwierig. Irgendwo stand drin, daß 2% Fehler akzeptabel wären, bei meinem Aufbau damals war bei errechneten 2% Fehler schon keine sinnvolle Kommunikation mit dem PC mehr möglich. Mit einem Baudratenquarz lief das Ganze auf Anhieb stabil.
Ben B. schrieb: > Vergiss das ohne Quarz. Ich hab das damals probiert, als ich mit den > AVRs angefangen habe. Keine Chance eine stabile Kommunikation > hinzukriegen. Selbst mit einem ungeeigneten Quarz sind solche hohen > Baudraten schwierig. 2% Fehler bleibt 2% sowohl bei 9600B als auch bei 115KB. Problem liegt bei grösseren Geschwindigkeiten in internen 8MHz die einfach zu langsam sind für alles über 38,4KB. Das führt bei 115KB zu prozentuell grösseren Fehlern als bei 9600B. Nicht nur die Fehler aus der Tabelle, auch die Abtastfehler verursacht durch Temperaturschwankungen werden grösser. Jedes bit muss 16 mal abgetastet werden, 3 hintereinander folgende Samples (8,9 und 10) müssen derselben Wert aufweisen. Ergibt 4,86% max. Fehler bei 9 bits (Stoppbit nicht mitgerechnet). Geteilt durch 2 (Sender und Empfänger) ist das 2,43% Fehler bei jedem. Und diese Genauigkeit wird bei neueren AVRs ohne jeglichen Abgleich erreicht. > Irgendwo stand drin, daß 2% Fehler akzeptabel > wären, bei meinem Aufbau damals war bei errechneten 2% Fehler schon > keine sinnvolle Kommunikation mit dem PC mehr möglich. Mit einem > Baudratenquarz lief das Ganze auf Anhieb stabil. Das kann nicht sein, dann hast du wohl irgendetwas falsch gerechnet. Sogar mit doppeltem Fehler hätte es ohne Probleme klappen sollen.
Marc V. schrieb: > Und diese Genauigkeit wird bei neueren AVRs ohne jeglichen > Abgleich erreicht. Aber nur bei "Zimmertemperatur" (25°C). Die Temperaturabhängigkeit ist leider auch bei den neueren Teilen immer noch so hoch, dass sich ein Einsatz in Umgebungen mit stärker davon abweichender Temperatur verbietet. Problematisch ist dabei insbesondere Leistungselektronik auf der gleichen Platine bzw. im gleichen Gehäuse. Die braucht den µC bloss um 20° aufheizen, dann kann schon Ende Gelände mit der UART-Kommunikation sein. Zum Glück bieten viele neuere Teile auch einen internen Temperatursensor. Damit kann man den Effekt immerhin per Software hinreichend kompensieren.
Marc V. schrieb: > Problem liegt bei grösseren Geschwindigkeiten in internen 8MHz die > einfach zu langsam sind für alles über 38,4KB. So ist es. Aber man kann die 8 MHz auch auf 7,37 MHz runterstellen (per OSCCAL), dann gehen auch höhere „krumme“ Datenraten. 1 Mbit/s wiederum gehen auch mit 8 MHz (FTDI kann das bspw. als Gegenseite).
Georg G. schrieb: > <dicker-daumen> > Ein Byte dauert 10 Bit. Am Ende des Bytes darf der zeitliche Versatz > maximal ein halbes Byte betragen, weil unser UART nur einmal, nämlich in > der Mitte des Bits, abtastet. Macht nach Adam Riese 5% zulässigen > Fehler. > <dicker-daumen/> Das ist falsch, es ist viel kritischer. Schau mal ins Datenblatt: Figure 19-7. Stop Bit Sampling and Next Start Bit Sampling "A new high to low transition indicating the start bit of a new frame can come right after the last of the bits used for majority voting." D.h. erst ab Takt 11 kann wieder ein neues Starbit erkannt werden. Wir haben also nur 5 Takte Spielraum. Und das macht: 5/160 = 3% maximal erlaubter Fehler. Wenn wir dann noch den Worst-case annehmen, d.h. beide MCs weichen in entgegengesetzte Richtung ab, ist der maximal zulässige Fehler: 3% / 2 = 1,5% Vergiß ganz schnell die 5%, da kommt nur noch Müll an.
Peter D. schrieb: > Vergiß ganz schnell die 5%, da kommt nur noch Müll an. Sehe ich auch so. Aber mal ganz ehrlich: Ein Quarz samt Anschwingkondensator oder Resonator kostet nicht mal 50 Cent wenn mans einzeln kauft. Hätte ich erstmal keine Probleme damit und dafür ist die Kommunikation sicher gewährleistet.
M. K. schrieb: > Ein Quarz samt Anschwingkondensator oder Resonator kostet nicht mal 50 > Cent wenn mans einzeln kauft. Kostet aber zwei zusätzliche Pins am Controller.
Bei konstanter Temperatur und konstanter Versorgungsspannung und einer Baudrate, die der Takt-Teiler mit maximal 2% Abweichung erzeugen kann, funktioniert die serielle Schnittstelle zuverlässig. Jedoch scheitert die Sache in der Praxis schon an der nicht konstanten Temperatur. Zum Ausgeben von Debug Meldungen mag der R/C Oszillator gut genug sein, für eine reale Anwendung empfehle ich jedoch, ihn nicht zu verwenden. Bedenkt bei eurer Rechnerei auch, dass die Gegenstelle oft kein AVR ist, also ggf. andere Anforderungen an die Genauigkeit der Bitrate stellt. Außerdem verzerren die Leitungen und Pegelwandler das Signal.
Jörg W. schrieb: > Kostet aber zwei zusätzliche Pins am Controller. Das könnte ein Argument sein. ;) Aber bzgl. Zuverlässigkeit: Einmal richtig machen oder sich immer wieder solchen Problemen, wie hier angesprochen, stellen…mir ist ersteres lieber.
:
Bearbeitet durch User
Hallo, vielleicht ging das unter. Ich verwende aktuell 250kBaudrate. Derzeit unterhalten sich bei mir zwei Mega2560 mit 16MHz Resonator mit 250k Baudrate ohne Probleme. Der Fehler liegt damit theoretisch bei 0%. Eine Adapterplatine zum testen für die attiny841 muß ich noch bauen. Darum die Frage ob besser mit oder ohne externen Quarz. Was mir nun bewußt wurde durch den Thread hier ist folgendes. Den Taktgeber vom Mega werde ich nun nicht wechseln. Dafür kann ich den Oscillator vom ATtiny auf den Mega per Software abstimmen. Gebe ich dem ATtiny ein Quarz zur Seite muß ich mit einen unkorrigierbaren Fehler leben. Richtig? Falsch? Oder nun doch lieber externen Quarz? 8MHz wegen 250kBaudrate. Am Geld liegt das nicht. Nur ob sinnvoll oder nicht. Ich habe allerdings keinerlei Erfahrung wie sehr ein Resonator bei Temperaturänderungen driftet oder der interne vom ATtiny. Außer das was im Datenblatt steht, die Diagramme. Die µC werden in der Bude betrieben. Sind also nur den üblichen Temp.schwankungen ausgesetzt die man so zu Hause hat. c-hater schrieb: > Leider ist das nicht ganz wahr. Bei den allermeisten AVR wird das > interne Timing für die Programmierung von Flash und EEPROM aus eben > diesem Takt des internen RC-Oszillators abgeleitet. Und die zuverlässige > Funktion dieser Sachen ist leider recht eng daran gebunden, dass der > Nominaltakt des RC-Oszillators nicht nennenswert überschritten wird. > > D.h.: sobald man in der Anwendung Schreibzugriffe auf Flash oder EEPROM > hat, muss man sich einen Kopp machen, zumindest wenn man den > RC-Oszillator deutlich nach oben tuned. Wenn man den internen sauber auf 8MHz fein tuned, dann sollte es keine Probleme geben? Weil das hier teilweise widersprüchlich geschrieben wird. Ich verstehe die Datenblattbeschreibung so, dass der Korrekturwert, wenn einmal im EEProm, immer automatisch verwendet wird. Man sich dann im Programmcode nicht mehr darum kümmern. Außer man möchte mittels Temp.messung den Takt ständig fein korrigieren. Was ich aber nicht gerafft habe ist. Warum gibt es ein Korrektur-Register für den Takt und Temperatur getrennt? Das hängt doch sowieso alles zusammen und beeinflusst sich gegenseitig.
Die Gegenseite mit dem Quarz sendet z.B. ein 'U' = 0x55 = 0b01010101 in RS232 mit Start und Stopbit ist das dann 1010101010. jetzt mist du die periode von dem Signal mit tiny am RX pin und mußt halt wisssen mit welcher baudrate der andere µC gesendet hat. Und schon kannst du dir ausrechnen mit welcher Frequenz der interne Oszillator deines tiny läuft. damit kannst du dann entweder deie Baudraten teiler berechnen. Oder der mit dem Quarz einen Strom von 'U' und hört erst auf wenn eine Antwort vom tiny kommt. Der tiny mißt die Peride oder Flakenabstände und krrigiert die das OSCAL Register je nachdem nach oben oder unten merkt sich das OSCAL Register wenn ein 'U' empfangen wird korrigiert weiter in die gleiche richtung bis kein 'U' mehr empfangen wird merkt sich OSCAL und nimmt die mitte zwischen beiden OSCAL werten.
> Wenn man den internen sauber auf 8MHz fein tuned, dann sollte > es keine Probleme geben? Du musst auch für eine konstante Chip-Temperatur sorgen, dann kann das ohne Probleme funktionieren.
Veit D. schrieb: > Gebe ich dem > ATtiny ein Quarz zur Seite muß ich mit einen unkorrigierbaren Fehler > leben. > Richtig? Falsch? Wie kommst du denn auf das schmale Brett? Nimmst du den richtige Quarz hast du immer 0% Fehler.
Veit D. schrieb: > Ich verstehe die Datenblattbeschreibung so, dass der Korrekturwert, wenn > einmal im EEProm, immer automatisch verwendet wird. Nein, der Korrekturwert wird von der Hardware beim Starten aus einer Fuse-Zelle geladen, also ein EEPROM-Teil, der in der Fertigung des ICs eingestellt ist. Wenn du eigene Korrekturwerte benutzen und im EEPROM hinterlegen willst, musst du dich schon selbst kümmern. Stefan U. schrieb: > Du musst auch für eine konstante Chip-Temperatur sorgen, dann kann das > ohne Probleme funktionieren. Wobei der ATtiny841 hier offenbar deutlich besser ist als frühere AVRs.
Hallo, ja, okay okay. Nur wozu dient das extra Temperatur-Register zum kalibrieren?
Veit D. schrieb: > ja, okay okay. Nur wozu dient das extra Temperatur-Register zum > kalibrieren? Offensichtlich haben sie jetzt noch eine Temperaturkompensation eingebaut. Dadurch können sie auch ±2 % über den gesamten Temperatur- und Spannungsbereich zusichern. Über die Details lassen sie sich nicht aus; ich würde vermuten, dass die beiden Temperaturkompensationsregister ebenfalls beim Start aus internen Fuses gelesen werden, wo sie während der Fertigung hinein geschrieben werden.
uwe schrieb: > Die Gegenseite mit dem Quarz sendet z.B. ein 'U' = 0x55 = 0b01010101 in > RS232 mit Start und Stopbit ist das dann 1010101010. jetzt mist du die > periode von dem Signal mit tiny am RX pin und mußt halt wisssen mit > welcher baudrate der andere µC gesendet hat. Das ist eine schöne Idee. So habe ich das auch schon mit dem Logik-Anneliesator ausprobiert. Da sieht man ja schön, wie "lange ein Byte dauert" und kann sich danach richten. MfG Paul
Jörg W. schrieb: > Veit D. schrieb: >> Ich verstehe die Datenblattbeschreibung so, dass der Korrekturwert, wenn >> einmal im EEProm, immer automatisch verwendet wird. > > Nein, der Korrekturwert wird von der Hardware beim Starten aus einer > Fuse-Zelle geladen, also ein EEPROM-Teil, der in der Fertigung des > ICs eingestellt ist. > > Wenn du eigene Korrekturwerte benutzen und im EEPROM hinterlegen willst, > musst du dich schon selbst kümmern. > > Stefan U. schrieb: >> Du musst auch für eine konstante Chip-Temperatur sorgen, dann kann das >> ohne Probleme funktionieren. > > Wobei der ATtiny841 hier offenbar deutlich besser ist als frühere > AVRs. ich meinte doch ... Wenn ich selbst kalibriere und einen eigenen Wert ins EEProm schreibe, dann nimmt er diesen immer automatisch ... So verstehe ich das jedenfalls. M. K. schrieb: > Veit D. schrieb: >> Gebe ich dem >> ATtiny ein Quarz zur Seite muß ich mit einen unkorrigierbaren Fehler >> leben. >> Richtig? Falsch? > > Wie kommst du denn auf das schmale Brett? Nimmst du den richtige Quarz > hast du immer 0% Fehler. Weil der Mega einen Resonator hat und kein Quarz. Dann würde sich ein 16MHz Resonator und ein 8MHz Quarz gegenüberstehen. Wie sind denn die Toleranzunterschiede zwischen Resonator und Quarz überhaupt? Oder spielt das hier gar keine Rolle? Dann würde ich doch ein Quarz nehmen für den ATTiny.
:
Bearbeitet durch User
[gelöscht, war Mist :)] Veit D. schrieb: > Wenn ich selbst kalibriere und einen eigenen Wert ins EEProm schreibe, > dann nimmt er diesen immer automatisch ... An welcher Stelle willst du den im EEPROM genau hinterlegen? > So verstehe ich das jedenfalls. Ich nicht. Von „EEPROM“ sehe ich da nur, dass der RC-Oszillator das Timing von Flash- und EEPROM-Schreibzugriffen beeinflusst, weshalb man ihn nicht schneller als 8,8 MHz drehen soll, falls man auf Flash oder EEPROM in der Applikation schreiben möchte (interessanterweise lässt sich dieser neue Oszillator ja ansonsten offenbar bis 16 MHz ziehen, wird allerdings nicht garantiert).
:
Bearbeitet durch Moderator
Veit D. schrieb: > Wie sind denn die Toleranzunterschiede zwischen Resonator und Quarz > überhaupt? 10 : 1 bis 100 : 1 > Oder spielt das hier gar keine Rolle? Ja, spielt bei RS-232 keine Rolle, dafür sind beide mehr als genau genug.
Hallo, also wenn die Resonator vs. Quarz Differenzen keine Rolle spielen, dann nehm ich für den ATtiny nun doch einen 8MHz Quarz und gut ist. Das kalibrieren interessiert mich dennoch. Forscherdrang. Werde wenigstens mal probieren. Ich würden den neuen Wert einfach ins OSCCAL Register schreiben. Mehr nicht.
Veit D. schrieb: > Ich würden den neuen Wert einfach ins OSCCAL Register schreiben. Das kannst du tun. Aber nach dem nächsten Reset steht dann an dieser Stelle trotzdem wieder der Wert, der aus der zugehörigen Fuse gelesen wird (die du nicht ändern kannst).
Hallo, ja, stimmt, dann habe ich das zu flüchtig überflogen. Ich dachte das Register liegt im EEprom und verwendet. Aber nö, muß man per Software neu laden. Okay, ist auch kein Problem. Danke für die Korrektur. "The oscillator calibration register is used to trim the internal 8MHz oscillator and to remove process variations from the oscillator frequency. A pre-programmed calibration value is automatically written to this register during chip reset, giving the factory calibrated frequency specified in Table 25-2 on page 239. The application software can write this register to change the oscillator frequency. The oscillator can be calibrated to frequencies specified in Table 25-2 on page 239. Calibration outside that range is not guaranteed."
Veit D. schrieb: > Aber nö, muß man per Software neu laden. Oder sich eben auf die ±2-%-Kalibrierung des Herstellers verlassen. Deren Wert(e) wird/werden in der Tat automatisch geladen.
:
Bearbeitet durch Moderator
Einige hier im Forum haben relativ große Probleme mit dem Rechnen. >Wie kommst du denn auf das schmale Brett? Nimmst du den richtige Quarz >hast du immer 0% Fehler. Wie kommt der Poster auf die Idee, dass sogenannte Baudratenquarze 0% Fehler haben... Fast Gebetsmühlenartig – sogar mit Zwischenrechnung in Takten - wird hier behauptet: 2 bis 3 % sollten erreichbar sein und dann Fehler unterdrücken. Schön, wenn die Gegenstelle dann auch auf 0% genau ist.
>Auf der anderen Seite hängt ein µC mit 16MHz Resonator. >Schön, wenn die Gegenstelle dann auch auf 0% genau ist. Ist sie nicht. Resonatoren kommen auch nur mit bis zu 0.5% daher.
Sebastian S. schrieb: > Wie kommt der Poster auf die Idee, dass sogenannte Baudratenquarze 0% > Fehler haben... Lass ihn 50 ppm Fehler haben (dann ist er schon eher schlecht), das ist doch völlig schnuppe, das sind dann stolze 0,005 %. (Außerdem ging's hier überhaupt nicht um Baudratenquarze, sondern um solche mit „glatten“ Frequenzen, denn gewünscht sind 250 kbit/s.)
Hallo, man sollte sich jetzt vielleicht nicht zu sehr in Details verzetteln. Nicht wegen mir. :-) Für mich reicht aus, dass der µC Takt und 250k Baudrate passen muß und paßt. Die nächstmögliche Baudrate wäre erst wieder 38,4k. Deutlich zu wenig. Danke erstmal an alle.
Moin, ich habe mir die letzten 10-20 Beiträge nicht mehr reingezogen aber für sowas gibt es eine einfache Möglichkeit: Sobald die Partner gestartet sind, sendet einer von Beiden (darf auch mit internem Oszi sein) ein Requestbyte, und zwar in einem festen Takt. Z.B. alle 100ms oder wie es günstig mit Timern passt. Der andere misst die Zeit zwischen den Bytes (Startinterrupt der Uart) und justiert danach selbst den internen Oszi (OSCCAL verstellen). Ob dieses Startbyte heil ankommt ist egal, es geht nur darum, wann es startet. Wenn es passt antwortet er mit einem OK-Byte und dann kann die normale Kommunikation starten. Dann kann man mit der Kommunikation laufend das OSCCAL nachführen. Damit kann man den 8MHz Oszi auch auf die 7,XY Baudratenfrequenz verbiegen. Gruß, Norbert
:
Bearbeitet durch User
Marc V. schrieb im Beitrag #4616598: > Nö, da bist du ja dauernd am Toleranzlimit. > Das macht man mit unterem und oberem Wert wo es gerade noch geht, > danach mit Mittelwert arbeiten. Selber Nö ;-) Ich meinte, wenn der verabredete Takt (z.B. 100ms) passt, nicht wenn der Inhalt vom Startbyte passt. Das hast Du vermutlich nur falsch verstanden. Die Grenze wie genau man das hinbekommt ist eigentlich nur die Auflösung des OSCCAL. (Achtung, das ist nicht immer stetig, Datenblatt lesen!) Marc V. schrieb im Beitrag #4616598: > Braucht man normalerweise nicht, so schlimm sind die Abweichungen > auch nicht. Wenn der eine Partner einen Quarz hat und der andere den internen Ozsi und die Temperatur von -35 bis 60°C geht dann schon. Lustigerweise haben auch einige interne Oszis gegensätzliches Temperaturverhalten. Sogar innerhalb einer Kleinfamile wie ATTiny 261, 461, 861. -> Datenblatt GENAU lesen. Das ist wirklich ein fieses Detail, daß die drei sich dabei nicht gleich verhalten. Ich habe sowas Ähnliches umgesetzt, allerdings mit anderen Bedingungen: Der Master läuft mit Quarz, Kommunikation über I2C. Der Slave, ein Tiny861, kann die Pins für den Quarz nicht entbehren, also interner Oszi. Für ein anderes Timing brauche ich aber wenigstens 1-2% Genauigkeit, was über den obigen Temperaturbereich nicht drin ist. Also wird jede Sekunde beim Telegramm vom Master das OSCCAL nachjustiert. Funzt prima. Gruß, Norbert
Veit D. schrieb: > Weil der Mega einen Resonator hat und kein Quarz. Dann würde sich ein > 16MHz Resonator und ein 8MHz Quarz gegenüberstehen. > Wie sind denn die Toleranzunterschiede zwischen Resonator und Quarz > überhaupt? Oder spielt das hier gar keine Rolle? Dann würde ich doch ein > Quarz nehmen für den ATTiny. Spielt hier keine Rolle. Zum anderen: Das ist ja ein systematischer Fehler und solche Fehler kann man immer korrigieren, das ist wie beim ADC der Offset-/ Gain-Error und INL/DNL ;)
Hallo, habe mir erstmal mit 2 Megas einen Frequenzgenerator und einen Frequenzmesser programmiert. Funktioniert. Fürs Grundverständnis. Jetzt gehts an die Testadapterplatine für den ATtiny841. Wenn ich im Layout den Quarz vorsehe mit den 22pF Keramik und verbaue, dann kann ich mit dem mkII Programmer jederzeit zwischen intern und extern umschalten und muß den Quarz nicht auslöten? Edit: übrigens gibts sogar von Atmel selbst eine Beschreibung zum Thema AVR054: Run-time calibration of the internal RC oscillator http://www.atmel.com/Images/doc2563.pdf
:
Bearbeitet durch User
Veit D. schrieb: > Wenn ich im Layout > den Quarz vorsehe mit den 22pF Keramik und verbaue, dann kann ich mit > dem mkII Programmer jederzeit zwischen intern und extern umschalten und > muß den Quarz nicht auslöten? Jepp, kein Problem. Gruß, Norbert
Norbert S. schrieb: > Jepp, kein Problem. Genau das ist das Problem :-) Er wäre nicht der erste, der einen Quarz verbaut und vergisst, auf ihn um zu schalten und sich dann wundert, dass die Frequenz daneben liegt.
Hallo, jetzt wird es ernster. Habe mir den rausgesucht. https://www.conrad.de/de/quarz-hc494h-serie-crystal-euroquartz-8000mhz-hc494h-30504018pfatf-frequenz-8000000-mhz-b-x-h-x-t-1026-x-35-x-368-mm-156453.html Jetzt noch eine Frage zu den beiden Kondensatoren. Rein rechnerisch kann ich frei wählen zwischen 11pF und 59pF. Praktisch werden immer 22pF verbaut. Müssen die immer SMD sein oder kann ich auch "normale" Keramikkondensatoren verbauen? Wegen zusätzlichen störenden Kapazitäten o.ä. ? https://www.conrad.de/de/keramik-kondensator-radial-bedrahtet-22-pf-100-vdc-5-holystone-rdcn220j101dka-1-st-531975.html
Veit D. schrieb: > Müssen die immer SMD sein oder kann ich auch "normale" > Keramikkondensatoren verbauen? Nein, müssen nicht SMD sein.
Veit D. schrieb: > Müssen die immer SMD sein oder kann ich auch "normale" > Keramikkondensatoren verbauen? Auch normale gehen. Habe ich bisher fast immer benutzt.
Veit D. schrieb: > Rein rechnerisch kann ich frei wählen zwischen 11pF und 59pF. Nein, du kannst da nichts „wählen“. Die Lastkapazität wird durch den Quarzhersteller vorgegeben (bzw. beim Bestellen beim Hersteller). Dieser Quarz braucht 18 pF Lastkapazität. Dabei ist zu beachten, dass die beiden Cs in Reihe geschaltet sind, ihnen aber jeweils noch die Pinkapazität (und andere Schaltungskapazitäten) parallel liegt. Die ist nicht genau beziffert, wenn du 8 … 10 pF ausgehst, liegst du sicher nicht total daneben. Für 18 pF Last brauchst du folglich insgesamt 2 x 36 pF an den Anschlüssen. 2 Kondensatoren je 27 pF dürften diesen Wert einigermaßen plausibel bringen.
Hallo, wie kommst du jetzt darauf? Im Datenblatt zum Quarz ist eine Angabe von bis. "Load Capacitance: 8pF to 32pF or Series (Specify)" gelesen habe ich unter anderem hier wie man das rechnet: https://www.mikrocontroller.net/articles/Quarze_und_AVR und jeder scheint dennoch 2x 22pF zu verbauen.
Veit D. schrieb: > Im Datenblatt zum Quarz ist eine Angabe von bis. Markiert mit “specify” (man muss sie also bei der Bestellung beim Hersteller angeben). In der Typennummer steht aber die Lastkapazität eindeutig beschrieben. Allerdings gebe ich zu, die Beschreibung im Datenblatt, wie die Typennummer aufgebaut ist, ist unter aller Sau. Da fehlen einfach Angaben, man muss daher raten, dass die "18PF" tatsächlich auch die Lastkapazität sind. Aber ansonsten passen die anderen Angaben der Typennummer schon darauf. > und jeder scheint dennoch 2x 22pF zu verbauen. Nur, weil jeder bei Rot über die Straße läuft, wird es davon nicht korrekt. Sehr wahrscheinlich wird das Ding auch mit einer etwas geringeren Lastkapazität wohl noch anschwingen, wie sie sich aus 2 x 22 pF ergibt, aber das ist kein Grund, warum man es nicht korrekt machen könnte, wenn man schon weiß, wofür der Quarz spezifiziert ist.
:
Bearbeitet durch Moderator
Hallo, ich dachte der hat eine Produktionsstreuung von bis. Okay, er hat ein CL von 18pF laut Bezeichnungsnummer. Danke. Dann ergibt sich laut Formel: 2x 18pF - 5pf = 31pF. Also brauche ich 2x 31pF? Also müßte ich 33pF nehmen, ist näher dran wie 27pF. Oder weist du auch wie genau die 5pF als zusätzliche Rechenkapazität angenommen wurden? Ginge nicht auch 1x 33pF und 1x 27pF? Oder müssen beide Werte gleich sein?
Veit D. schrieb: > Also brauche ich 2x 31pF? > Also müßte ich 33pF nehmen, ist näher dran wie 27pF. Das wird einigermaßen egal sein, so genau sch***t kein Hund. > Oder weist du auch wie genau die 5pF als zusätzliche Rechenkapazität > angenommen wurden? „Hausnummer“ :) > Ginge nicht auch 1x 33pF und 1x 27pF? > Oder müssen beide Werte gleich sein? Das Datenblatt des AVRs empfiehlt, beide möglichst gleich zu machen. Wenn es wirklich extrem drauf ankommt (für eine Uhr also), dann hat man auch schon mal einen als Trimmer ausgeführt, aber für deine Anwendung dürfte es ziemlich egal sein. Wie ich schon schrieb: sehr wahrscheinlich würden's auch die „Allerwelts“-2x22pF tun, aber wenn man es genauer weiß, kann man ja ruhig versuchen, das zu wählen, was auch tatsächlich zum Quarz passt.
Wichtig ist ja nicht der Fehler zur idealisierten Datenrate, sondern der Fehler der Kommunikationspartner relativ zueinander. Wenn der Fehler zur idealisierten Datenrate in der gleichen Richtung liegt, hebt er sich (teilweise) auf. Sind die Abweichungen vom Idealwert mit unterschiedlichem Vorzeichen, so addieren sie sich. Pro und Contra des synchronen Modus: Der synchrone Modus kostet zwar einen Pin und eine Datenleitung, das sind aber nicht unbedingt Mehrkosten. Man hat oft Standardkabel, z.B. 8-Adrig, und auch die MCUs haben Standardgehäuse. Das deckt sich nicht immer 100 % mit den Mindestanforderungen der Anwendung. Folglich sind oft die nötigen Ressourcen ohnehin vorhanden.
Hallo, muß nochwas nachfragen. In vielen Schaltplänen sieht man noch einen 1MOhm Widerstand parallel zum Quarz. Wird aber auch weggelassen. Wofür dient dieser? Läuft der Schwingkreis damit noch sicherer an oder so?
Veit D. schrieb: > muß nochwas nachfragen. In vielen Schaltplänen sieht man noch einen > 1MOhm Widerstand parallel zum Quarz. Wird aber auch weggelassen. Wofür > dient dieser? Läuft der Schwingkreis damit noch sicherer an oder so? Siehe https://de.wikipedia.org/wiki/Pierce-Schaltung Bei µCs ist der Widerstand (vermutlich) eingebaut.
Dietrich L. schrieb: > Bei µCs ist der Widerstand (vermutlich) eingebaut. eher weniger. Bei den meisten Quarzen genügt aber deren eigener, parasitärer, Widerstand.
M. K. schrieb: > Dietrich L. schrieb: >> Bei µCs ist der Widerstand (vermutlich) eingebaut. > > eher weniger. Bei den meisten Quarzen genügt aber deren eigener, > parasitärer, Widerstand. Ich habe mal einige Quarze durchgemessen: der (parallele) Ohmsche Widerstand war >20MOhm (Bereichsgrenze des Messgerätes). Da würde ich als µC-Hersteller einen internen Widerstand spendieren, damit der Inverter der Oszillatorschaltung auch wirklich im Analogbereich arbeitet. Allerdings habe ich auf die Schnelle nichts dazu bei den µC-Herstellern gefunden...
Dietrich L. schrieb: > Allerdings habe ich auf die Schnelle nichts dazu bei den µC-Herstellern > gefunden... Wahrscheinlich weil es diesen internen Widerstand gar nicht gibt in den µCs die du so kennst ;) Dietrich L. schrieb: > Ich habe mal einige Quarze durchgemessen: der (parallele) Ohmsche > Widerstand war >20MOhm (Bereichsgrenze des Messgerätes). Kann man den so ohne weiteres mit nem Multimeter messen? Ich hab grade mal versucht zu schaun, mein Fluke legt grad mal 1 V Prüfspannung an bei 1 MΩ. Reicht sowas denn um den parasitären Widerstand am Quarz richtig zu messen?
M. K. schrieb: > Kann man den so ohne weiteres mit nem Multimeter messen? Ich hab grade > mal versucht zu schaun, mein Fluke legt grad mal 1 V Prüfspannung an bei > 1 MΩ. Reicht sowas denn um den parasitären Widerstand am Quarz richtig > zu messen? Warum nicht? Immerhin wird der Quarz auch nur mit wenig Spannung betrieben. Wenn da kein Strom fließt, kann der Oszillator-Inverter auch passend "vorgespannt" werden.
Hallo, im Datenblatt zum ATtiny ist keiner drin. Also weglassen?
Dietrich L. schrieb: > Bei µCs ist der Widerstand (vermutlich) eingebaut. Nein: man braucht ihn dort einfach nicht. Der Widerstand wird bei Digitalgattern benutzt, um sie in den Analogbetrieb zu ziehen. Bei einer expliziten Oszillatorschaltung baut man diese gleich so auf, dass sie analog arbeitet. Sowas ist dann in den Controllern verbaut.
Die Tinys441 und 841 sind intern temperaturkompensiert. Hält man die Betriebsspannung konstant, ist der R/C sehr genau und stabil über einen weiten Temperaturbereich zu betreiben. OSCCAL stellt man passend für die gewünschte Baudrate ein, hierbei ist ein OSZI hilfreich oder eine genaue, temporäre externe Taktquelle zum Kalibrieren. BTDT. Einmal eingestellt ist bei einem Test mit Eisspray von Zimmertemperatur auf -40°C am OSZI bei der USART Bitbreite kaum eine Abweichung sichtbar gewesen. Probiert es aus. Quarz adé.
:
Bearbeitet durch User
Knut B. schrieb: > bei einem Test mit Eisspray von Zimmertemperatur auf > -40°C am OSZI bei der USART Bitbreite kaum eine Abweichung sichtbar Naja, 2% Abweichung ist jetz auch nicht die Welt, bei einem 10 cm breiten Display sind das grad mal 0.2 cm Unterschied. Hast du die Bitbreite auch übers komplette Display gemessen oder "nur" über 2 divs? Bei 2 divs oder weniger wird man den Unterschied auch kaum wahrnehmen können. Aber es stimmt schon, die AVRs im allgemeinen sind sehr temperaturstabil, meiner Erfahrung nach. Die allgemein angegebenen 10% Factoryset sind IMO sehr pessimistisch angegebenen.
M. K. schrieb: > Aber es stimmt schon, die AVRs im allgemeinen sind sehr > temperaturstabil, meiner Erfahrung nach. Die allgemein angegebenen 10% > Factoryset sind IMO sehr pessimistisch angegebenen. Was meinst du mit 10% Factoryset? Abweichúng von der Nennfrequenz? Frequenzdrift über einen Temperaturbereich? Frequenzdrift über einen Betriebsspannungsbereich?
Abweichung von der Nennfrequenz (von RC-Oszilator und Watchdog).
Entgegen den bisherigen Ausfuehrungen ist die Abweichung bei einem byte voellig unkritisch. Die Baudratenabweichung kommt bei laengeren Meldungen in den Fokus. Nehmen wir an, ich sende 50 (oder N) Byte am Stueck, ohne Abstand, was mit Windows Zufall ist, mit einem Controller aber machbar ist. Von diesen 50 (oder N) moechte man, dass alle richtig ankommen. und nicht die letzten falsch. Billigst UARTs, machen vielleicht 2 fach Oversampling, die besseren machen 16 fach Oversampling. Das ist alles Gut, erlaubt aber nicht in der Zeit zurueck zu gehen. Dh zu kurze Bytes sind weniger ein Problem, wie zu lange. Denn wenn das Stupbit frueher durch ist wie erwartet, wartet er auf das naechste. Eine Frage des Oversampling. Daher. Zum Anpassen der Baudrate einen Block von vordefinierten Bytes senden und waehrend dem Frequenzveraendern schauen, wann Lesefehler auftreten. Bisher nicht erwaehnt, die Baudratenquarze : man erkennt sie an der fast willkuerlich krummen Frequenzen. zB 1.8342 MHz, 3.6864MHz, 7.3728MHz, 11.095MHz, 14.31818MHz. Einfach mal die Teilverhaeltnisse rechnen. Und lasst das Gezeter wegen einem Quarz, ich bekomm die fuer 21Euro pro Hundert. SPI ist keine Alternative. Abgesehen vom zusaetzlichen Faden. Und einem zusaetzlichen Kanal wenn ich ueber einen Treiber muss. Nein, das Problem ist der SPI Slave. Schon mal einen gemacht ? Wenn der Clock nicht passt ... auch hier kommt das Versagen erst bei groesseren Blocklaengen. Und dann haben Controller mit SPI keinen Buffer. Entweder, das Byte wird abgeholt, oder es wird ueberschrieben. Wenn ich den SPI mit controllerclock laufen lasse, reichts nicht mal fuer einen Interrupt. Denn der Interrupt, auch ein SPI Interrupt, muss mindestens den PC und das status register push/pop-en und dann noch einen Sprung hin und zurueck ausfuehren. Dann kann man gleich auf das SPI Ready warten. SPI Slaves machen eigentlich nur sinn in Hardware, dh als Schieberegister, alleine, oder in einem Chip mit zusaetzlich anderer Funktionalitaet, einem ADC oder so.
:
Bearbeitet durch User
Oh D. schrieb: > Nehmen wir an, ich sende 50 (oder N) Byte am > Stueck, ohne Abstand, In dem Fall ist es ausreichend, wenn man mit zwei Stop-Bits sendet. Die Jungs, die sich das ausgedacht haben, waren ja nicht blöd.
Konrad S. schrieb: > In dem Fall ist es ausreichend, wenn man mit zwei Stop-Bits sendet. Die > Jungs, die sich das ausgedacht haben, waren ja nicht blöd. Das solltest du dir nochmal in Ruhe überlegen...
M. K. schrieb: > Konrad S. schrieb: >> In dem Fall ist es ausreichend, wenn man mit zwei Stop-Bits sendet. Die >> Jungs, die sich das ausgedacht haben, waren ja nicht blöd. > > Das solltest du dir nochmal in Ruhe überlegen... Die Fernschreiber funktionierten sogar mit 1,5 Stopbits zuverlässig. Ist ja nur wichtig, dass die Stopbit-Zeiten so lange sind, dass auch bei Drehzahlunterschieden beider Seiten die Welle im Empfänger wirklich wieder anhält und dann auf das nächste Startbit warten muss, statt einfach weiterzulaufen, was der Analogie der oben genannten Byte-an-Byte-Sequenz entsprechen würde.
Jörg W. schrieb: > Die Fernschreiber funktionierten sogar mit 1,5 Stopbits zuverlässig. Ja, ich schrieb schon bewusst, dass man sich das nochmal "überlegen" sollte. Wenn man RTS/CTS benutzt ist das kein Problem, heutezutage, das ist meine Erfahrung, wird aber die serielle Schnittstelle meist nur noch mit RX/TX ausgeführt und das wars dann. Da ist es dem Sender dann egal, ob der Empfänger sagt, dass er Ready ist und dann werden die Zeiten doch etwas wichtiger werden.
M. K. schrieb: > Wenn man RTS/CTS benutzt ist das kein Problem Hatten die Fernschreiber auch nicht. Wenn der Sender (infolge von 1,5 oder 2 Stopbits) langsamer sendet, kann das doch für den Empfänger nie ein Problem sein. Natürlich geht die Netto-Datenrate um ein paar Prozent zurück.
M. K. schrieb: > Wenn man RTS/CTS Das ist eine der größten Stolperfallen bei serieller Übertragung. Da gibt es n+1 Definitionen zum Timing. Dagegen sind 2% Baudraten Fehler harmlos.
Wir stellen uns vor: Der Sender sei 2% schneller als der Empfänger. Nach dem 50. gesendeten Bit hat man dann schon einen Versatz von einem ganzen Bit. Und wie genau sollen dem langsamen Empfänger nun 1.5 oder 2 Stoppbits helfen um keine Datenfehler zu bekommen? Dem schnellen Sender kommt er ja nicht hinterher, er kann sich nicht mit jedem neuen Startbit auf den Sender, der ohne Rücksicht auf Verluste sendet (Byte-an-Byte), synchronisieren eben weil er nicht schnell genug ist. Datenfehler sind hierbei, ohne weitere Maßnahmen, quasi vorprogrammiert. Dein Beispiel mit dem Fernschreiber mag recht gut klingen, man muss aber bedenken, dass beim Fernschreiber das "Stoppbit" ein echter Stopp war/ist: Die Antriebe beider Fernschreiber wurden/werden gestoppt/angehalten, d.h. die Fernschreiber wurden/werden nach jedem Zeichen quasi synchronisiert sodass beim nächsten Startbit beide zur selben Zeit loslaufen. Bei der RS232 wie hier beschrieben haben wir diesen Vorteil jedoch nicht, der Clock beider RS232 läuft einfach für sich weiter, unabhängig von der Gegenseite. Du hast natürlich recht, wenn der Sender langsamer ist, ist das kein Problem aber wie stellst du sicher, dass der Sender der Langsame ist bei RS232? ;)
:
Bearbeitet durch User
M. K. schrieb: > Wir stellen uns vor: Der Sender sei 2% schneller als der Empfänger. Nach > dem 50. gesendeten Bit hat man dann schon einen Versatz von einem ganzen > Bit. Und wie genau sollen dem langsamen Empfänger nun 1.5 oder 2 > Stoppbits helfen um keine Datenfehler zu bekommen? Und jetzt überlegst du nochmal, wann genau synchronisiert wird. Nicht einmal, nicht zweimal, sondern bei jedem Startbit. Es ist völlig egal wie viele Bits man sendet. Vor jedem Byte wird frisch synchronisiert.
M. K. schrieb: > Die Antriebe beider Fernschreiber wurden/werden gestoppt/angehalten Nur der Empfänger. Der Sender konnte, wenn man das nächste Zeichen bereits tippte, durchlaufen. Aus den Anekdoten der Urväter von Unix kann man erfahren, dass normal geübte Schreiber durchaus für die damaligen 110-Bd-TTYs schnell genug waren, als dass der Finger bereits auf der nächsten zu drückenden Taste lag und drauf wartete, bis die Mechanik diese freigab (daher sind Unix-Kommandos so kurz gehalten worden ;-). Genau dieses Resynchronisieren mit jedem Startbit macht eine UART auch. O.D.s Einwand war ja nur, dass sie, wenn der Sender etwas langsamer als der Empfänger ist und nur ein Stopbit gesendet wird, zwischendurch ja nicht anhalten muss. Wenn der Empfänger Oversampling macht und den verspäteten Übergang zwischen vorigem Stop- und neuem Startbit sauber erkennt (und von da aus dann eine halbe Bitzeit weiter geht für den Abtastpunkt), dann ist alles OK, aber wenn er nur einfach feststellt, dass der Pegel des nächsten Startbits bereits anliegt und im gleichen Takt weitermacht, dann verschiebt sich das allmählich. Ist der Sender schneller, muss der Empfänger ja immer erst anhalten.
M. K. schrieb: > Wir stellen uns vor: Der Sender sei 2% schneller als der Empfänger. Nach > dem 50. gesendeten Bit hat man dann schon einen Versatz von einem ganzen > Bit. Und wie genau sollen dem langsamen Empfänger nun 1.5 oder 2 > Stoppbits helfen um keine Datenfehler zu bekommen? Ganz einfach, weil der Empfänger sich dann alle 10,5 oder 11 Bits erneut auf den Anfang des nächsten Datenworts synchronisieren kann. > Dem schnellen Sender > kommt er ja nicht hinterher, er kann sich nicht mit jedem neuen Startbit > auf den Sender, der ohne Rücksicht auf Verluste sendet (Byte-an-Byte), > synchronisieren Doch, genau das kann er und das tut er auch. Weil bei "Byte an Byte" des Senders jedes Byte halt nicht genau 10 Bit dauert, sondern länger, eben 10,5 bzw. 11. Der Empfänger ist aber nach spätestens nach 10,02 Bit mit dem Empfang des Bytes fertig. Er hat dann also noch 0,48 bzw. 0,98 Bits Zeit, sich auf den Empfang des nächsten Bytes vorzubereiten. Das kann doch nicht so schwer zu begreifen sein?!
c-hater schrieb: > Weil bei "Byte an Byte" des > Senders jedes Byte halt nicht genau 10 Bit dauert, sondern länger Dann wäre der Sender aber der Langsamere von beiden und da sagte ich schon, dass es hier kein Problem ist zu Synchronisieren. Aber wenn der Sender der schnellere ist braucht der, aus Empfängersicht, vielleicht nur 9 Bit bis er mit dem nächsten Byte beginnt, dann wartet mein Empfänger noch auf das Stoppbit obwohl der Sender schon mit dem nächsten Byte begonnen hat. Jörg W. schrieb: > Ist der Sender schneller, muss der Empfänger ja immer erst anhalten. Genau das meinte ich. Dass hier aber der Sender der langsamere sein sollte hab ich überlesen, sorry. Ich habe Oh D. schrieb: > Denn > wenn das Stupbit frueher durch ist wie erwartet so interpretiert, dass der Sender der schnellere ist.
M. K. schrieb: > Aber wenn der > Sender der schnellere ist braucht der, aus Empfängersicht, vielleicht > nur 9 Bit bis er mit dem nächsten Byte beginnt, dann wartet mein > Empfänger noch auf das Stoppbit obwohl der Sender schon mit dem nächsten > Byte begonnen hat. Wenn man Start und Stoppbit als Bits betrachtet mag das stimmen, ich würde sie eher als zwei Flanken bezeichnen, die den UART-Rahmen bestimmen. Und wenn nach dem letzten Datenbit die "Stoppflanke" früher kommt, dann ist der Empfänger auch früher bereit den nächsten Rahmen zu empfangen.
avr schrieb: > Wenn man Start und Stoppbit als Bits betrachtet mag das stimmen, ich > würde sie eher als zwei Flanken bezeichnen, die den UART-Rahmen > bestimmen. Und wenn nach dem letzten Datenbit die "Stoppflanke" früher > kommt, dann ist der Empfänger auch früher bereit den nächsten Rahmen zu > empfangen. Kannst du das genauer erklären? Ich dachte, UART schaut nach den Pegeln, nicht nach Flanken. Und ich verstehe auch noch nicht so ganz wie der Empfänger früher bereit sein kann wenn z.B. das Stoppbit aus Empfängersicht schon bei Bitposition 8.7 beginnt schaut der Empfänger ja trotzdem erst ab Bitposition 9.0 ob das Stoppbit da ist und nicht früher, oder anders gesagt: Wenn das Stoppbit früher kommt als erwartet, woher weis dann der Empfänger, dass das ein Stoppbit ist und kein Datenbit?
M. K. schrieb: > Und ich verstehe auch noch nicht so ganz wie der > Empfänger früher bereit sein kann wenn z.B. das Stoppbit aus > Empfängersicht schon bei Bitposition 8.7 beginnt schaut der Empfänger ja > trotzdem erst ab Bitposition 9.0 ob das Stoppbit da ist und nicht > früher Nein, er schaut nicht auf einer festen Bitposition, sondern üblicherweise mehrmals während der Dauer eines jeden Bits und fällt auf der Grundlage dieser Samples eine Entscheidung, welcher Pegel wohl gemeint war. Das letzte dieser Samples gewinnt er typischerweise kurz vor dem nominellen Ende des Bits, das Ergebnis des Entscheidungsprozesses steht üblicherweise genau zum nominellen Bitende bereit. Der Rhythmus der Abtastung ist grundsätzlich fest und starr an die Bitrate gekoppelt, also ein ganzzahliges Vielfaches selbiger. Die Lage der Abtastzeitpunkte während des Empfangs eines Datenworts ist ebenfalls starr und entspricht eben diesem Abtastrhythmus. Der Trick bei der Synchronisation besteht nun darin, dass in dieser Phase (typischerweise "Idle" genannt, es wird also gerade nix empfangen) Abtastungen hinzugefügt oder verworfen werden können und damit praktisch das gesamte Abtastraster um Teile der Länge eines Bits verschoben werden kann. Und das funktioniert so: Der Ausgangspunkt ist der H-Pegel, der dem Pegel eines Stopbits entspricht. Nun werden immer weiter Samples eingelesen, so lange, bis deren Auswertung ergibt, dass ein L-Bit auf der Leitung war. In dieser Phase spielt also die Zahl der gelesenen Samples keine Rolle, es müssen nur mindestens so viele sein, wie normalerweise in einem Bit gelesen werden, es dürfen aber beliebig viel mehr sein. Wurde nun endlich ein L-Bit erkannt, tritt die Synchronisation ein. Das gelesene L-Bit wird als Startbit betrachtet und von nun an wird für jedes Bit immer die gleiche Zahl Samples verwendet und zwar bis einschliesslich des ersten Stopbits. Der eigentliche Witz ist: für einen Empfänger gibt es immer nur genau ein Stopbit, hat er das im Sack, wird er wieder Idle und er tritt damit in die Synchronisationsphase für das nächste Datenwort ein. D.h.: Wenn der Sender mehr als ein Stopbit sendet, verlängert das effektiv nur die Idle-Phase des Empfängers. Genau das gibt dem Empfänger die Chance, sich auch mit einem Sender zu synchronisieren, der schneller sendet, als er empfängt.
c-hater schrieb: > Und das funktioniert so: Der Ausgangspunkt ist der H-Pegel, der dem > Pegel eines Stopbits entspricht. Nun werden immer weiter Samples > eingelesen, so lange, bis deren Auswertung ergibt, dass ein L-Bit auf > der Leitung war. In dieser Phase spielt also die Zahl der gelesenen > Samples keine Rolle, es müssen nur mindestens so viele sein, wie > normalerweise in einem Bit gelesen werden, es dürfen aber beliebig > viel mehr sein. Also wäre die 2-Stoppbit-Variante eigentlich keine Byte-an-Byte-Übertragung sondern einen Byte-Pause-Byte-Übertragung und dem Empfänger ist es egal ob die Einstellung 1 oder 2 Stoppbits vorgibt? Das ist natürlich tricky. c-hater schrieb: > Der Rhythmus der Abtastung ist grundsätzlich fest und starr an die > Bitrate gekoppelt, also ein ganzzahliges Vielfaches selbiger. Die Lage > der Abtastzeitpunkte während des Empfangs eines Datenworts ist > ebenfalls starr und entspricht eben diesem Abtastrhythmus. Klingt nett, aber wenn es so funktioniert, warum soll dann beim UART die Einstellung maximal 1 bzw. 2% Abweichung nur haben (vgl. Artikel zum UART). Es müssten doch auch 5% dann funktionieren. Aus leidlicher Erfahrung weiß ich aber, dass schon ~2% problematisch werden können wenn viele Bytes hintereinander gesendet werden.
M. K. schrieb: > Also wäre die 2-Stoppbit-Variante eigentlich keine > Byte-an-Byte-Übertragung sondern einen Byte-Pause-Byte-Übertragung und > dem Empfänger ist es egal ob die Einstellung 1 oder 2 Stoppbits vorgibt? So ist es. Der Empfänger kann nicht zwischen Pause oder einem zusätzlichen Stoppbit unterscheiden.
Angehängte Dateien:
-
STM32F072.png
11 KB
Das kann man so pauschal gar nicht sagen. Das hängt nämlich von den Teilnehmern, der übertragenenen Menge an Bits pro Startbit und den Eigenschaften der UART ab. Der "Versatz" summiert sich über die Bits auf, bei 2% sind das bei 8 Datenbits schon 18% beim 9.Bit. Dazu kommt ein gewisser Fehler bei der Erkennung der Flanke, der abhängig ist vom Oversampling - z.B. 1/16 (bei dem üblichen 16-fach Oversampling. Dazu kommt der Fehler bei der Baudratengenerierung, zusätzlcih der des Empfängers. Für den STM32 hab ich das mal angehängt (jaja, kein Tiny, aber das Bild war grad greifbar). Nimmt man 2 STM32 mit je 2% Fehler, wird es bei 8 Bit schon fallweise eng. Aber: Oft hat ein Teilnehmer einen Quarz zur Verfügung - das entspannt die Sache natürlich. Daher: Pauschale Aussagen sind hier gefährlich.
Gästchen schrieb: > Dazu kommt der Fehler bei der Baudratengenerierung Einen statischen Fehler (durch nicht ideales Teilerverhältnis) musst du natürlich in die 2 % mit einbeziehen, nicht nur die Schwankungen der Frequenz.
Jörg W. schrieb: > Gästchen schrieb: >> Dazu kommt der Fehler bei der Baudratengenerierung > > Einen statischen Fehler (durch nicht ideales Teilerverhältnis) musst > du natürlich in die 2 % mit einbeziehen, nicht nur die Schwankungen > der Frequenz. Ja, nur hier ist das halt grenzwertig: Und wenn man jetzt hat: 2% Fehler am Clock Start 2% Fehler am Clock Ziel 1% Fehler in der Baudrate --> 5% - natürlich nur worst case (also selten) Über die 8 Datenbits sind das schon 45%. Da wird die UART schon aussteigen. Das fiese ist: Baut man das so, funktionieren die Geräte dann bei Inbetriebnahme und Produktion natürlich einwandfrei - weil Kleinmengen (=Typisch passts ja!) oder 25° und so. Der Ärger geht draußen im Feld los, wenn es kalt oder warm wird. Dann steht man da, draußen im Schnee, den Kunden im Genick, mit dem Oszi in der Hand. Mir ist das schon passiert. Nein, Daumenregeln sollte man hier wirklich nicht anwenden. Da kann ich nur abraten. @Topic Die 2% gelten nur für 0-70°, das ist schon klar? Bei diesem Tiny gäbs die "user calibration" (Siehe Datenblatt) möglicherweise könnte man hier ansetzen?
Gästchen schrieb: > Dann steht man da, draußen im Schnee, den Kunden im Genick, mit dem Oszi > in der Hand. Da waere es schoen noch einen Roehrenoszi zu haben zum aufwaermen:=)
Gästchen schrieb: > Über die 8 Datenbits sind das schon 45%. Da wird die UART schon > aussteigen. Eben nicht. Ein guter UART tastet in der Mitte ab und damit dürfen sich die Bits um bis zu einer halben Bitzeit verschieben. Praktisch sollte noch ein bisschen Reserve da sein, aber 2% Toleranz/UART kann man schon machen. > Das fiese ist: Baut man das so, funktionieren die Geräte dann bei > Inbetriebnahme und Produktion natürlich einwandfrei - weil Kleinmengen > (=Typisch passts ja!) oder 25° und so. Der Ärger geht draußen im Feld > los, wenn es kalt oder warm wird. Dafür gibt es Temperaturtests, Berechnungen oder beides.
c-hater schrieb:
[...]
Eine Sache habe ich noch vergessen zu erwähnen:
Richtig gute Empfänger trennen sogar die Stopbit-Prüfung vom Mechanismus
zur Resynchronisation, die sind also in Bezug auf das nächste zu
empfangende Datenwort "idle" ab Ende des letzten Datenbits (oder ggf.
Paritätsbits) des aktuellen Datenworts und nicht erst ab Ende von dessen
obligatorischen StopBit.
Solche Empfänger können sich also auch auf schnellerere Sender
resynchronisieren, wenn diese keine zusätzlichen Stopbits senden.
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.