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
AVR054 Beschreibt wie man den RC zur Laufzeit mit Hilfe des UART rekalibriert.
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?
Ggf. ist wohl einfacher, die Programmierung des Baudratengenerators vom UART anzupassen, statt den Takt des RC-Oszillators.
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
> Manche Mikrocontroller haben einen eingebauten Temperatursensor, > u.a. manche ATTinys. Das ist ist mir bisher entgangen. Danke für den Hinweis!
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
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.