Hallo, den internen Oszilator kann man, z.B. beim ATtiny 45, über einen externen Quarz kalibrieren. IMHO ist auch der ADC-Wert des internen Temperatursensors von dem kalibrierten Wert abhängig. Kann man, im Umkehrschluss, eine Kalibrierung dann auch über die Temperatur machen?
?!? schrieb: > den internen Oszilator kann man, z.B. beim ATtiny 45, über einen > externen Quarz kalibrieren. Wie stellst du dir den Ablauf vor? ?!? schrieb: > IMHO ist auch der ADC-Wert des internen Temperatursensors von dem > kalibrierten Wert abhängig. Vom kalibrierten Wert des internen Oszillators? Wie kommst du darauf? ?!? schrieb: > Kann man, im Umkehrschluss, eine Kalibrierung dann auch über die > Temperatur machen? Nicht IMHO
clock schrieb: > ?!? schrieb: >> den internen Oszilator kann man, z.B. beim ATtiny 45, über einen >> externen Quarz kalibrieren. > > Wie stellst du dir den Ablauf vor? Ungefähr so wie in der Applicationnote von Atmel (AVR055: Using a 32kHz XTAL for run-time calibration of the internal RC) beschrieben. > ?!? schrieb: >> IMHO ist auch der ADC-Wert des internen Temperatursensors von dem >> kalibrierten Wert abhängig. > > Vom kalibrierten Wert des internen Oszillators? Wie kommst du darauf? > Tja, wie komme ich darauf? Das war dann wohl wieder eine Mischung aus: Mein "perfektes" Englisch (aus dem Datenblatt übersetzt) und meinem Wunschdenken die Welt kann so einfach sein. > ?!? schrieb: >> Kann man, im Umkehrschluss, eine Kalibrierung dann auch über die >> Temperatur machen? > > > Nicht IMHO Schade, Schade.
Du legst von außen ein frequenzstabiles Signal an und misst per Timer die Periodendauer. Je nach Abweichung des Messwerts vom Sollwert manipulierst du OSCCAL. Den besten OSCCAL-Wert speicherst du zum Messwert des internen Temperatursensors. Diese Prozedur lässt du laufen, während du den µC aus dem Gefrierfach nimmst, während er langsam auftaut und auch noch während du ihn langsam mit dem Föhn aufwärmst. Du musst dir nur überlegen, wieviel (EEPROM-)Platz du hast und welchen Temperaturbereich du in welchen Schritten abdecken willst.
?!? schrieb: >> Wie stellst du dir den Ablauf vor? > > Ungefähr so wie in der Applicationnote von Atmel (AVR055: Using a 32kHz > XTAL for run-time calibration of the internal RC) beschrieben. Die AVR055 kannte ich noch nicht. Geht beim Tiny45 aber leider nicht da die Application Note einen asynchronen Timer/Counter voraussetzt.
Sodele jetzt habe ich es (glaube ich) auch verstanden. Der interne Oszilator ist zwar (auch) Temperaturabhängig. Aber der ADC-Wert des internen Temperatursensors hat nichts mit dem OSCCALC-Wert zu tun. Ich hatte im Datenblatt nur gelesen, dass man den internen Temperatursensor kalibrieren kann. (Kalibrieren => Internen Oszilator kalibrieren) Wenn man die AVR122 von Atmel überflogen hätte (Ja, hätte ich vorher tun sollen) begreift man (ich!) auch was hier gemeint ist. Der ADC-Wert ist ein Wert mit dem man dann rechnen kann um auf die reale Temperatur zu kommen. Hierzu muss man den "offset" und den "gain" -Fehler ermitteln bzw. heraus rechnen.
Ah, ich dachte, du willst den Oszillator kalibrieren. Jetzt ist es klar.
Wollte ich ja auch. Nur mit einem Quarz ist mir das zu aufwendig?!? Ich dachte: Ich messe die Umgebungstemperatur und korrigiere die Werte im ATTiny. Oder so. Da haben mich auch die Werte im Datenblatt wohl ein wenig verwirrt. Zurzeit läuft es ja auch im Testlauf ohne Kalibrierung. Das sollen mal mehrere (3-10) kleine ATTinys am RS485-Bus werden. Das Ganze soll dann mal im Keller, eventuell draußen, hängen. Ich habe nur die Befürchtung, dass die Teile bei gewissen Temperaturen nicht mehr kommunizieren können, da das Timing der Soft-UART nicht mehr passt. Bei 9600 Baud soll wohl nicht so viel passieren ... Temperatur auslesen ist nur eine Übung um mehr "Gefühl" für MC zu bekommen und um es zu verstehen. Nebenbei auch ein lustiges Feature, nur muss ich das bei jedem Controller neu berechnen.
?!? schrieb: > Bei 9600 Baud soll wohl nicht so viel passieren ... Der Fehler in der Baudrate ist in Prozent. Es spielt deshalb überhaupt keine Rolle, ob du ein Bit pro Sekunde überträgst oder eine Million Bits pro Sekunde. Nach einer gewissen Menge ohne Pause übertragener Bits sind die UARTs so weit auseinandergedriftet, dass Fehler auftreten. Dem kannst du entgegenwirken, indem du nach einer bestimmten Anzahl Bytes eine Pause einlegst oder eben dafür sorgst, dass die µCs mit möglichst gleichem Takt laufen, also Quarz (sehr genau) oder über einen temperaturkompensierten internen Oszillator, z.B. wie oben skizziert. Noch eine Möglichkeit wäre, mit adaptiver Baudrate zu arbeiten.
Konrad S. schrieb: > Nach einer gewissen Menge ohne Pause übertragener Bits sind > die UARTs so weit auseinandergedriftet, dass Fehler auftreten. Bei jedem Startbit wird der UART neu synchronisiert. MfG Klaus
Konrad S. schrieb: > ?!? schrieb: >> Bei 9600 Baud soll wohl nicht so viel passieren ... > > Der Fehler in der Baudrate ist in Prozent. Es spielt deshalb überhaupt > keine Rolle, ob du ein Bit pro Sekunde überträgst oder eine Million Bits > pro Sekunde. Nach einer gewissen Menge ohne Pause übertragener Bits sind > die UARTs so weit auseinandergedriftet, dass Fehler auftreten. Dem > kannst du entgegenwirken, indem du nach einer bestimmten Anzahl Bytes > eine Pause einlegst oder eben dafür sorgst, dass die µCs mit möglichst > gleichem Takt laufen, also Quarz (sehr genau) oder über einen > temperaturkompensierten internen Oszillator, z.B. wie oben skizziert. > Noch eine Möglichkeit wäre, mit adaptiver Baudrate zu arbeiten. Mannomann du laberst vielleicht einen Quatsch daher: 1.) Natürlich spielt die Baudrate dabei eine Rolle. Da die Angaben (wie du ja schreibst, nur nicht kapierst) in Prozent sind. Bei 9600 Baud beträgt die Bitdauer 104 µS. Bei einem 5% Fehler darf man um 5,2 µS davon abweichen. Bei 115200 Baud beträgt die Bitdauer nur 8,68µS. 5% Fehler bedeutet hier 0,434µS also 434nS. Der Spielraum ist unendlich viel kleiner. Ein ungenauer Taktgeber spielt also weniger eine Rolle je niedriger die Baudrate ist. 2.) Wie Klaus schon schreibt, syncronisiert man beim Startbit, vor JEDEM Byte auf die Mitte des Impulses und somit können UARTS nicht auseinanderlaufen. gruß cyblord
Hallo erstmal... cyblord ---- schrieb: > 1.) Natürlich spielt die Baudrate dabei eine Rolle. Nein. > Ein ungenauer Taktgeber spielt also weniger eine Rolle je > niedriger die Baudrate ist. Ebenfalls nein. Es geht rein um das Verhältnis. Je länger ein Bit "dauert", desto größer wird auch der absolute Fehler einer Zeitbasis. Die Bitrate ist also unerheblich, es kommt rein auf den relativen Fehler an, den man beispielsweise in Prozent angeben kann. > 2.) Wie Klaus schon schreibt, syncronisiert man beim Startbit, vor JEDEM > Byte auf die Mitte des Impulses und somit können UARTS nicht > auseinanderlaufen. Das ist bei asynchroner Übertragung richtig, wenn es um das jeweils folgende Byte geht. Innerhalb eines jeden Bytes besteht das Problem aber weiterhin. Trotzdem kann man natürlich mit einem unkalibrierten ATtiny seriell Daten übertragen. Man verlässt sich einfach nur auf die ersten 4 Bits eines jeden Bytes (das sind die niederwertigen 4 Bits). Dann müssten sogar bis zu 15% Fehler bei der Zeitbasis geschluckt werden können. Eine zweite Möglichkeit ist, die empfangene Baudrate automatisch zu erkennen und diese dann auch beim Senden zu verwenden. Das hat Konrad S. ja schon vorgeschlagen ("adaptive Baudrate"). Schöne Grüße Markus
?!? schrieb: > Zurzeit läuft es ja auch im Testlauf ohne Kalibrierung. > Das sollen mal mehrere (3-10) kleine ATTinys am RS485-Bus werden. Das > Ganze soll dann mal im Keller, eventuell draußen, hängen. Alles, was mir zum Kalibrieren des Oszillators beim Tiny45 einfällt, ist einen Pin per Timer toggeln zu lassen und mit einem Frequenzzähler nachmessen. Mit OSCCAL Register korrigieren. Temperaturabhängigkeit der Drift kann man über die Diagramme im Datenblatt abschätzen.
clock schrieb: > Alles, was mir zum Kalibrieren des Oszillators beim Tiny45 einfällt, ist > einen Pin per Timer toggeln zu lassen und mit einem Frequenzzähler > nachmessen. Mit OSCCAL Register korrigieren. Das doch aber der selbe Takt! So funktioniert es, wenn man einen externen Takt einen Pin toggeln lässt oder durch einen Uhrenquarz wie in der Appnote... Aber interne Temperatur messen bei gleichbleibender Spannung und dann nach Datenblatt kalibrieren klingt für mich auch ganz Sinnvoll... Kommt drauf an wie schlimm es wäre, wenn der UART mal nicht geht.
ach falscher Beitrag... jedenfalls das letzt ;)
Bassti schrieb: > Das doch aber der selbe Takt! So funktioniert es, wenn man einen > externen Takt einen Pin toggeln lässt oder durch einen Uhrenquarz wie in > der Appnote... Der selbe Takt wie welcher Takt? Der interne Oszillator des Tiny45 taktet einen internen Timer, der einen Pin toggeln läßt. Das wird mit einem Meßgerät nachgemessen und auf die interne Oszillatorfrequenz des Tiny zurückgeschlossen. Die Appnote ist beim Tiny nicht anwendbar, da dieser keinen asynchronen Timer besitzt wie oben schon mal erwähnt.
Hm, tja, also ... Der Baudratengenerator des UARTs teilt den Takt auf (typischerweise) das 16-fache der Baudrate. Mit dieser Frequenz wird der RX-Pin gesamplet. Beim ersten erkannten 0-Pegel wird ein Startbit angenommen und ein 4-Bit-Zähler läuft los. Typischerweise wird bei drei aufeinanderfolgenden Zählerständen in der Mitte des Zählbereichs - also etwa bei 7, 8 und 9 - der RX-Pin abgetastet. Sind die Pegel gleich, wird das als ein Bit gewertet, andernfalls ist es ein Fehler. Wenn nun der Sender einen etwas schnelleren Takt als der Empfänger hat, dann verschiebt sich der vom Empfänger abgetastete Bereich langsam immer weiter zum Ende der (Sender-)Bits und irgendwann kommt die Abtastung in das nächste Bit rein. Das liegt einfach daran, dass der 4-Bit-Zähler immer bis zum Ende zählt. Erst dann wird wieder nach einem Startbit Ausschau gehalten. Die Situation für den Empfänger lässt sich verbessern, wenn der Sender dafür sorgt, dass ein Startbit sicher als Startbit erkennt werden kann. Dafür muss zwischen dem Ende des Stoppbits und dem Beginn des nachfolgenden Startbits soviel Zeit liegen, dass das Auseinanderdriften von schnellerem Sender und langsamerem Empfänger über den Zeitraum der ohne Pause übertragenen Bits (Start- und Stoppbits zählen mit) mindestens kompensiert wird. Eine Möglichkeit (bei z.B. ATmega) ist, beim Senden mit zwei Stoppbits zu arbeiten (auf Kosten der Nutzdatenrate). Eine andere Möglichkeit ist, nach einer gewissen Anzahl gesendeter Bytes eine kleine Pause einzulegen (Dauer: ein Byte incl. Start- und Stoppbit). Je höher die Baudrate ist, desto schwieriger wird es für den Baudratengenerator das 16-fache der Baudrate genau zu erzeugen. Deshalb nimmt man gerade für hohe Baudraten gern einen Quarz mit scheinbar "krummer" Frequenz. Aber mit ein paar Vorkehrungen gehen auch 115200 Baud mit internen Oszillator ganz gut. Unterm Strich: Die Mikrosekunden pro Bit spielen keine Rolle, es geht um die 16 Takte, die der Baudratengenerator pro Bit liefert. @cyblord Wenn du UART-Beschreibungen hast, die etwas anders sagen, dann lass es mich wissen. (Ja, mir ist bekannt, dass der UART im ATxmega noch etwas mehr draufhat.)
clock schrieb: > Alles, was mir zum Kalibrieren des Oszillators beim Tiny45 einfällt, ist > einen Pin per Timer toggeln zu lassen und mit einem Frequenzzähler > nachmessen. Mit OSCCAL Register korrigieren. Im Prinzip: ja. Nur würde ich die Sache umdrehen und - wie oben beschrieben - ein möglichst präzises Referenzsignal an den µC anlegen. Sagen wir mal mit 1Hz. Dann sollten bei ungeteiltem internem Oszillator für jede Periode des Referenzsignals 8000000 Takte vergehen, die per Timer plus Overflow-Interrupt gezählt werden. Jetzt kann man den OSCCAL-Wert ändern, bis die Abweichung vom Sollwert minimal wird. Diesen OSCCAL-Wert speichert man für die Temperatur, die der interne Temperatursensor misst. Macht man das über den vorgesehenen Einsatztemperaturbereich, dann bekommt man einen temperaturkompensierten internen Oszillator: Gelegentlich die Temperatur messen und ggf. den dazugehörigen OSCCAL-Wert setzen.
Konrad S. schrieb: > Nur würde ich die Sache umdrehen und - wie oben beschrieben - ein > möglichst präzises Referenzsignal an den µC anlegen. Sagen wir mal mit > 1Hz. Dann sollten bei ungeteiltem internem Oszillator für jede Periode > des Referenzsignals 8000000 Takte vergehen, die per Timer plus > Overflow-Interrupt gezählt werden. OK, verstanden. Danke.
Es ist nicht nur die Temperatur, die den Oszillator beeinflusst, auch die Spannung. Wenn die Leute sich keinen Quarz fuer 15 cents leisten koennen, werden sie auch nicht einen so stabilen Spannungsregler vermoegen... NB. Die Appnote von atmel ist verbesserungswuerdig. http://www.ibrtses.com/embedded/avrosccal.html
Delta Oschi schrieb: > Es ist nicht nur die Temperatur, die den Oszillator beeinflusst, auch > die Spannung. Wenn die Leute sich keinen Quarz fuer 15 cents leisten > koennen, werden sie auch nicht einen so stabilen Spannungsregler > vermoegen... Es sind nicht die "sündteuren" Quarze, sondern die zwei benötigten Pins für das Anschließen des Quarzes bei einem ATtiny25/45/85. "Verdrahtungsaufwand" und Platinenfläche wären noch Argumente. > NB. Die Appnote von atmel ist verbesserungswuerdig. Ja, davon gibt es einige. Aber als Anregung sind die Appnotes gut zu gebrauchen. > http://www.ibrtses.com/embedded/avrosccal.html Danke für den Link.
Also mit dem Source von Atmel (aus der Appnote) hab ich mal folgendes getan: Beitrag "GPS Wanze - Tiny GPS" Kann ?!? sich ja mal anschauen, ist nicht wirklich schwierig mit dem Uhrenquarz.
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.