OSCCAL beim Tiny25/45/85

[Oldie (Gast)]

Ich will mit 64 Samples pro 50-Hz-Periode den Effektivwert der
Netzspannung ermitteln. - Wurzel aus dem Mittelwert der Quadrate.
1% Genauigkeit reicht.

Das ist etwas Mathematik, aber nicht das Problem.
Problem: Ich will es ohne Quarz machen!

Wenn ich es mit dem internen Oszillator (CKDIV8: 1 MHz) machen
will, muss ich in einem Kalibrierlauf die Samplerate auf
64 * 50 Hz = 3200 Hz justieren.
Mein Kalibrierlauf erfasst die Anzahl der Interrupts bis sich
3 positive Nulldurchgänge zeigen. Sollwert = 3 * 64 = 192.

Bei Abweichungen kann an an "2 Schrauben" drehen:

A) Ich gleiche den CTC-Wert ab.
Die Abgleichgenauigkeit ist ähnlich, wie mit OSCCAL, aber bei
928 kHz vom internen Oszillator habe ich nur 290 Takte zwischen
zwei Sample-Interrupts. Mal sehen, ob das zum Quadrieren etc.
reicht...

B) Ich gleiche den RC-Oszillator mit OSCCAL auf ca. 1,024 MHz ab
und erhalte die 3200 Hz mit Prescaler = 1/2 und CTC = 1/160.
Vorteil: Ich kann fest mit 320 Takten pro Interrupt rechnen.

Atmel rät: "that the MCU is kept in Reset during such changes".

Sehr verwirrend!
Ich kann den Wert doch nur im aktiven Lauf ändern!
Hat jemand Erfahrungen mit einem OSCCAL-Abgleich beim Tiny25
im Betrieb???

[Knut B. (Firma: TravelRec.) (travelrec)]

Du kannst OSCCAL naturlich zur Laufzeit ändern. Achte darauf, dass Du 
die Änderung schrittweise durchführst und nicht in einem Ruck um einen 
größeren Betrag.

[c-hater (Gast)]

Oldie schrieb:

> Hat jemand Erfahrungen mit einem OSCCAL-Abgleich beim Tiny25
> im Betrieb???

Ja, ich. Beiliegender Code funktioniert u.a. beim Tiny25. Sollte aber 
auch bei praktisch jedem anderen AVR8 funktionieren.

Er hält sich nicht ganz an die Vorgaben von Atmel, ist aber vielfach 
getestet und läuft sehr zuverlässig.

Achtung: Warnungen bezüglich des Verhältnisses von System- und 
Referenztakt sollte man sehr ernst nehmen, eigentlich sind das Fehler.

[Oldie (Gast)]

@ c-hater

Sieht gut aus, sogar der Versatz zwischen 127 und 128 ist
berücksichtigt! Wenn ich das richtig sehe, gibt's den aber bei
mega-AVRs nicht.

Hat das was mit CAL7 zu tun? Dafür habe ich die Definition
nicht gefunden...

[c-hater (Gast)]

Oldie schrieb:

> Sieht gut aus, sogar der Versatz zwischen 127 und 128 ist
> berücksichtigt! Wenn ich das richtig sehe, gibt's den aber bei
> mega-AVRs nicht.

Bei manchen ja, bei manchen nein.

However, du hast da tatsächlich sozusagen den Finger auf die offene 
Wunde gelegt. Die von mir gepostetete Version des Codes war nicht der 
finale Stand, sondern einer, der kurz nach dem Einpflegen der 
Unterstützung für diese üble "discontinuity" aktuell war, diese zwar 
bereits händeln konnte, aber dabei die Kompatibilität zu den Devices 
brach, die sie eben nicht hatten. Bei Devices mit 8Bit-OSCCAL und einer 
FCLOCK-Vorgabe, die einen OSCCAL-Wert zwischen 96 und 127 erfordern 
würde, wird der Code zu einer Endlosschleife in der Kalibrierung 
führen... Nicht schön...

Beim angefragten Tiny25/45/85 würde der Code allerdings sicher 
funktionieren, denn die haben diese "discontinuity"...

Trotzdem im Anhang die aktuelle Fassung. Weil du ganz offensichtlich 
mitgedacht und somit bezeugt hast, kein C&P-ler zu sein.

> Hat das was mit CAL7 zu tun?

Indirekt. Nur bei Devices mit 8Bit-OSCCAL-Register (es gibt auch welche 
mit einem nur 7 Bit breiten) gibt es diese "discontinuity" überhaupt. 
Dementsprechend ist die Behandlung der Sache nur dort nötig und 
dementsprechend wirkt sich das Problem des unfertigen Codes auch auf 
keines der Devices mit 7Bit-OSCCAL aus.

> Dafür habe ich die Definition
> nicht gefunden...

Steht aber ziemlich unübersehbar in tn25def.inc...

Steht aber z.B. nicht in tn2313def.inc. Genau das ist der Trick...

[Oldie (Gast)]

Danke c-hater,

habe die Definition nicht in der device-def.ini erwartet,
da ich bisher nur mit tiny24, 25 und 261 sowie mega8,
also CAL8-Devices zu tun hatte.

Auf CAL7-er bin ich beim Blick auf die "Frequency vs. Osccal"-
Grafik noch garnicht gestoßen. Schaut man auch nur drauf, wenn
man ohne Quarz zeitlich besser, als 1% sein will.