Es geht um Atmega und Attiny, kein konketer Typ.
Soweit mir bekannt ist, kann man den UART nicht gut mit R/C Oszillator
nutzen, weil dessen Taktfrequenz nicht genau eingehalten wird und von
der Temperatur abhängt.
Ich hatte mal ein Modem, das hat die Übertragungsrate der seriellen
Schnittstelle automatisch eingestellt. Ich glaube, dazu hat es die
Tatsache ausgenutzt, dass jeder Befehl mit AT beginnt.
Wenn ich nun ebenfalls die Möglichkeit habe, eine Sitzung mit einer frei
programmierbaren Sequenz von Buchstaben einzuleiten, kann ich diese
nutzen, um den R/C Oszillator zu kalibrieren?
Hat das schonmal jemand gemacht, wovon ich abgucken darf?
Hallo Stefanus,
bei den ATMega habe ich oft eine serielle Kommunikation mit dem internen
Oszillator realisiert. Insbesondere wenn der Baudratenfehler (s. Tabelle
im Datenblatt) klein bleibt und man sich mit 9600 oder vielleicht 19200
Baud begnügt, ist das meist kein Problem.
Problematisch wird evetuell das Temperaturverhalten.
Grüße, Kurt
> Problematisch wird evetuell das Temperaturverhalten.
Ja eben, und genau diesem problem bin ich bereits mehrmals mit einer
industriell gefertigten Schaltung (mit Xmega) begegnet. Deswegen suche
ich nach einer Lösung.
Es gibt von Atmel eine AppNote, in der die nachträgliche Eichung
beschrieben ist. Allerdings würde ich einfach einen Quarz/Oszillator
verwenden.
Grüße, Kurt
Das geht schon. Du kannst mit OSCCAL den internen RC etwas tunen.
Im Prinzip musst du nur die Breite eines Bits deiner Präambel messen
(die natürlich passend sein muss, d.h. 10 oder 01. Der Vergleich aus
Soll und Ist, sollte dir mitteilen wie du den RC verstellen musst.
Entweder genau rechnen, oder schrittweise Anpassung bis es irgendwie
passt.
gruß cyblord
Stefanus schrieb:> Wenn ich nun ebenfalls die Möglichkeit habe, eine Sitzung mit einer frei> programmierbaren Sequenz von Buchstaben einzuleiten, kann ich diese> nutzen, um den R/C Oszillator zu kalibrieren?
Ist nicht nötig - nutze einfach das A von AT, dann funktioniert das auch
mit anderer Software. Entweder wird ein Modem angesteuert, dann kommt
als erstes AT, oder du gibst von Hand ein, dann tippst du eben selbst
AT.
Gruss Reinhard
Danke für eure Tips. AVR054 beschreibt mehrere Lösungsansätze sehr
detailliert. Das werde ich mir mal durchlesen.
Mir scheint der Ansatz logisch, die Breite eines Bits zu messen.
Wie warscheinlich ist es, dass der Sender, das Kabel oder schlicht die
Schaltschwellen des AVR das Signal unsymmetrisch verzerren, so dass ein
1-Bit länger dauert, als ein 0-Bit (oder umgekehrt)?
Ist es besser (sinnvoll), den Abstand zwischen zwei steigenden Flanken
zu messen?
greg schrieb:> Ggf. ist wohl einfacher, die Programmierung des Baudratengenerators vom> UART anzupassen, statt den Takt des RC-Oszillators.
Warum? Die Methode via OSCCAL ist vom Atmel empfohlen um den RC zu
kalibrieren , und führt gleichzeitig dazu, dass auch der restliche
Controller korrekte Zeiten messen kann.
gruß cyblord
cyblord ---- schrieb:> Warum? Die Methode via OSCCAL ist vom Atmel empfohlen um den RC zu> kalibrieren , und führt gleichzeitig dazu, dass auch der restliche> Controller korrekte Zeiten messen kann.
Naja, es ist eben etwas tricky mit OSCCAL zu hantieren, und abhängig vom
Controller. Die Funktion von OSCCAL hat keine lineare Antwort, und ist
auch nicht unbedingt monoton steigend.
Und wenn man wirklich genaue Zeiten messen will, ist man mit einem
RC-Oszillator immer noch fehl am Platze, glaube ich. Denn die sendende
UART, die man als Zeitbasis für die Kalibrierung nimmt, läuft ja auch
nicht unbedingt supergenau...
greg schrieb:> Die Funktion von OSCCAL hat keine lineare Antwort, und ist> auch nicht unbedingt monoton steigend.
Das ist aber wohl ganz bewusst so von Atmel gewählt. Deswegen wird ja
auch der Wert für OSCAL nicht durch lineare Interpolation ermittelt,
sondern mittels einer binären Suche.
Mit freundlichen Grüßen,
Karol Babioch
@ Stefanus (Gast)
>Ich hatte mal ein Modem, das hat die Übertragungsrate der seriellen>Schnittstelle automatisch eingestellt. Ich glaube, dazu hat es die>Tatsache ausgenutzt, dass jeder Befehl mit AT beginnt.
Hier muss man aber 2 Dinge unterscheiden.
1. Das Modem kennt zwar nicht die Baudrate, hat aber einen genauen
Quarzoszillator. Hier muss "nur" die korrekte Baudrate erkannt werden.
Was einfach dadurch geht, dass man solange diese mit den bekannten
Baudraten verstellt, bis man sauber ein bekanntes Zeichen empfängt. Die
minimale Pulsdauermessung geht hier auch und ist eher einfach, da die
Baudraten sich stark unterscheiden, oft um Faktor 2!
2.) Das Modem/deiun AVR hat KEINEN genauen Oszillator und muss diesen
anhand einer bekannten Baudrate kalibrieren. Hier ist das Problem, dass
die Mess- und Kalibriergenauigkeit deutlich höter sein muss, im Bereich
von 1% und weniger.
Solche Sachen macht man nur, wenn es ABSOLUT nicht anders geht. Aber es
gibt viele Alternative.
1) Quarz verwenden, super einfach und auch nicht wirklich teuer
2) 32kHz Uhrenquarz verwenden und mit diesem den RC-Oszillator dynamisch
kalibieren
3) RC-Oszillator manuell einmal kalibieren und den Temperaturbereich der
Schaltung so wählen, dass die Drift nicht zu groß wird
4) RC-Oszillator manuell einmal kalibieren und durch periodische
Temperaturmessung den RC-Oszillator nachstellen (kompensieren) So machen
es viele moderne uCs, Z.B. C2000 von TI. Dort sind sogar die
Kalibierwerte des Temperatursensors sowie des RC-Oszillators im OTP
EEPROM gespeichert!
So macht es wahrscheinlich auch der FT232, der ohne externen Quarz eine
Taktgenauigkeit von ca. 0,16% über den gesamten Temperaturbereich
erreicht. Ein unkompensierter RC-Oszillator schafft sowas nicht.
Falk Brunner schrieb:> So macht es wahrscheinlich auch der FT232, der ohne externen Quarz eine> Taktgenauigkeit von ca. 0,16% über den gesamten Temperaturbereich> erreicht. Ein unkompensierter RC-Oszillator schafft sowas nicht.
Ist es nicht wahrscheinlicher, dass der USB-Datentakt zur Kalibrierung
verwendet wird?
Die Idee mit der Messung der AT-Sequenz ist gut aber...
Du musst dem System klarmachen, dass es eine ungenutzte oder
unvollständige Sequenz verschickt, da Du diese ja verwendest. Was dem AT
folgt ist dann aber meist nicht zu nutzen. Der Sender geht aber davon
aus, dass dies der Fall ist.
Ach ja, die Temperatur....
Wenn ich den Oszillator kalibrietr habe, und dann die Schaltung in einer
Sitzung wärmer wird, fällt irgendwann die Kommunikation aus. Das ist
natürlich doof.
Der Ansatz, die Temperatur zu messen und die Oszillator dementsprechend
anzupassen klingt verlockend. Aber dann brauche ich eine zusätzlichen
Sensor, da kann ich gleich einen Quarz einsetzen - ist einfacher.
Vermutlich hat Falk Recht, ich sollte beim Quarz bleiben, sofern
möglich. Die 50 Cent zu sparen war wohl eine Schnapsidee.
Stefanus schrieb:> Der Ansatz, die Temperatur zu messen und die Oszillator dementsprechend> anzupassen klingt verlockend. Aber dann brauche ich eine zusätzlichen> Sensor, da kann ich gleich einen Quarz einsetzen - ist einfacher.
Manche Mikrocontroller haben einen eingebauten Temperatursensor, u.a.
manche ATTinys. Der ist nicht unbedingt supergenau, aber für solche
Zwecke wie RC-Kalibrierung sollte der reichen... ich denke dafür wird
sowas auch eingebaut.
Hi
>Der Ansatz, die Temperatur zu messen und die Oszillator dementsprechend>anzupassen klingt verlockend. Aber dann brauche ich eine zusätzlichen>Sensor, da kann ich gleich einen Quarz einsetzen - ist einfacher.
Praktisch alle halbwegs neueren ATTinys mit ADC besitzen einen internen
Temperatursensor. Trotzdem, nimm einen Quarz.
MfG Spess
@ greg (Gast)
>> So macht es wahrscheinlich auch der FT232, der ohne externen Quarz eine>> Taktgenauigkeit von ca. 0,16% über den gesamten Temperaturbereich>> erreicht. Ein unkompensierter RC-Oszillator schafft sowas nicht.>Ist es nicht wahrscheinlicher, dass der USB-Datentakt zur Kalibrierung>verwendet wird?
Kann sein.
Was auf jeden Fall geht, wenn man keinen Vollduplex am UART benötigt:
Nun weiß ich nicht, ob alle UART-Typen es erlauben, aber z.B. der UART
eines 8051 erlaubt einen Mode mit Simplex-Betrieb, wobei das Nutzsignal
mit der Rx-Leitung geclockt wird, beliebig schnell oder langsam,
unabhängig einer Baudratenfrequenz. In so einem Fall müßte die Software
die Datenrichtungen jeweils umschalten, wenn man senden und empfangen
will. Evtl. mit einer dritten Handshake-Leitung.
Amateur schrieb:> Was dem AT> folgt ist dann aber meist nicht zu nutzen. Der Sender geht aber davon> aus, dass dies der Fall ist.
Das trifft nicht zu. Die Kalibrierung kann abgeschlossen sein, wenn das
A empfangen ist, und alles Folgende läuft normal. Es ist daher auch egal
welches AT-Kommando als erstes gesendet wird. Das war schon Stand der
Technik bei den ersten Modems, wahrscheinlich sogar schon bei den
Akustikkopplern, da wird man das doch auch heute noch hinkriegen.
Gruss Reinhard
Dummerweise sind die Tiny-µCs mit Temperatur-Sensor gerade
nicht mit einer UART ausgestattet...
Da kommt zu einer stundenlangen Kalibriertabellen-Erstellung
auch noch der Aufwand einer Soft-UART dazu.
Für die Tabellen-Erstellung reicht ja die Messung einer
Standardfrequenz - trotzdem muss man die Temperaturkurve
langsam genug (< 1 K/Minute) durchfahren, um verlässliche
Ergebnisse zu erhalten. Und das für jedes µC-Individuum!
Lohnt das, wenn noch genug µC-Pins frei sind????
Wenn es irgeneine Moeglichkeit gibt den Oszillator so zu programmieren,
dass er ueber den gewuenschten Temperaturbereich und die erforderlichen
Taktraten weniger als 2,5% von der Zieltaktrate abweicht, dann wird das
auch zuverlaessig funktioneren, sofern man diese Moeglichkeit findet.
Temperaturverhalten und Kalibrierung sind sehr unterschiedlich von den
Herstellern, ein genauerer RC-Oszillator braucht entweder ein besseres
Design oder mehr Chipflaeche -> teurer herzustellen. Meist trifft beides
zu. Dazu kommt noch Testerzeit in der Fertigung. Um einen Oszillator
moeglichst genaue zu kalibrieren braucht es mehrere Iterationen, viele
Millisekunden Testerzeit. Das kostet echtes Geld.
Also nochmals Datenblaetter auf die 2,5% hin lesen und falls die Option
besteht mal R/C Oszillatoren von Silicon Labs oder NXP vergleichen. Da
geht es problemlos, was du machen moechtest.
Robert
