ATtiny kalibrieren anhand der internen Temperatur

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.

Ah, ich dachte, du willst den Oszillator kalibrieren. Jetzt ist es klar.

?!? 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:
> ?!? 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

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.

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.