Guten Tag,
gegeben ist ein 32,768 kHz Quarz mit einer Genauigkeit von +/- 20ppm. Um
ein zu starkes davonlaufen einer Echtzeituhr auf Grund der Ungenauigkeit
zu verhindern, kann beispielsweise die Frequenz vom Quarz mit Hilfe von
einem einstellbaren Kondensator auf möglichst genau 32,768 kHz
korrigiert werden.
Eine weitere Möglichkeit wäre das integrierte RTC Modul von einem
LPC1778 zu verwenden. Ist dem Controller die genaue Frequenz der Quarze
bekannt, kann je nach Abweichung zu bestimmten Zeitpunkten entweder eine
Sekunde zur Echtzeituhr addiert oder subtrahiert werden. Durch diesen
Korrekturfaktor sollten die Uhren in der Theorie sehr genau laufen.
Da das benötigte Register vom LPC1778 für die Kalibrierung der Uhrzeit
nur 17 Bits groß ist, kann die Frequenz von Quarz leider nicht lückenlos
korrigiert werden. Dies ist erst ab einer Abweichung des Quarzes von 32
768,000 Hz um mindestens 0,250 Hz möglich. Das heißt, liegt die
Frequenz vom Quarz zwischen 32 768,750 Hz und 32 768,250 Hz kann der
Controller die Abweichung nicht exakt korrigieren. Für eine exakte
Korrektur muss die Abweichung vom Quarz daher größer sein.
Ein Quarze mit +/- 20 ppm soll nun durch die Lastkondensatoren so stark
zu verzogen werden, dass er mit Sicherheit außerhalb der genannten
Grenzfrequenzen von 32 768,750 Hz oder 32 768,250 Hz liegt.
Wisst Ihr, ob es eine geläufige Methode ist 32,768 kHz Quarze mit
Absicht zu verstellen, um sie beispielsweise durch RTC Module von
Controllern genauer korrigieren zu können ? Spricht generell etwas
dagegen diese Methode anzuwenden ? Kennt ihr eine bessere Möglichkeit ?
Vielen Dank.
Ich würde gerne das RTC Modul vom LPC verwenden und mich auch darauf
beschränken.
Hat jemand Erfahrung zu oben beschriebenem Vorgehen ? Der
Temperatureinfluss lässt sich natürlich nicht so leicht korrigieren. Das
ist klar. Die +/- 20 ppm schon.
Trotzdem Danke für die Vorschläge.
ETC schrieb:> Ein Quarze mit +/- 20 ppm soll nun durch die Lastkondensatoren so stark> zu verzogen werden, dass er mit Sicherheit außerhalb der genannten> Grenzfrequenzen von 32 768,750 Hz oder 32 768,250 Hz liegt.
Blöde Idee: wenn du schon den Aufwand treibst, den Quarz zu ziehen,
dann kannst du ihn auch gleich auf Sollfrequenz ziehen.
Ansonsten suche mal hier im Forum nach „Die genaue Sekunde“. Die
Korrektur kann man, wenn man den Korrekturfaktor kennt, auch komplett
in Software vornehmen.
Allerdings ist das Feature dieses Controllers auch sehr fraglich,
wenn man eine Abweichung von immerhin 7E-6 damit nicht mehr korrigieren
kann. Das ist ja mehr als eine halbe Sekunde pro Tag.
Wenn du den Quarz damit verziehst, kannst du ihn in Software immer noch
nur in 0,25 Hz Schritten verstellen. Also würdest du mit den
Kondensatoren um 0,25+x verstellen und in Software minus 0,25. Dann
kannst du aber auch gleich mit den Kondensatoren nur die +x korrigieren.
Ansonsten das bisher gesagte, Zeit gelegentlich von extern
(GPS/DCF77/NTP/...) holen, reicht ja einmal täglich (wenn die Frequenz
innerhalb deiner Schranken liegt geht der pro 36h max. eine Sekunde
falsch).
@ETC (Gast)
>gegeben ist ein 32,768 kHz Quarz mit einer Genauigkeit von +/- 20ppm. Um>768,000 Hz um mindestens 0,250 Hz möglich. Das heißt,
Eine Auflösung von 7,6ppm. Naja, nicht berauschend.
>Wisst Ihr, ob es eine geläufige Methode ist 32,768 kHz Quarze mit>Absicht zu verstellen, um sie beispielsweise durch RTC Module von>Controllern genauer korrigieren zu können ?
Nein.
> Spricht generell etwas>dagegen diese Methode anzuwenden ?
Ja. Wenn schon per Trimmer trimmen, dann auf nahe 0ppm Abweichung.
> Kennt ihr eine bessere Möglichkeit ?https://www.mikrocontroller.net/articles/AVR_-_Die_genaue_Sekunde_/_RTC#Echtzeituhr_mit_Uhrenquarz
Jörg Wunsch schrieb:> ETC schrieb:>> Ein Quarze mit +/- 20 ppm soll nun durch die Lastkondensatoren so stark>> zu verzogen werden, dass er mit Sicherheit außerhalb der genannten>> Grenzfrequenzen von 32 768,750 Hz oder 32 768,250 Hz liegt.>> Blöde Idee: wenn du schon den Aufwand treibst, den Quarz zu ziehen,> dann kannst du ihn auch gleich auf Sollfrequenz ziehen.>> Ansonsten suche mal hier im Forum nach „Die genaue Sekunde“. Die> Korrektur kann man, wenn man den Korrekturfaktor kennt, auch komplett> in Software vornehmen.>> Allerdings ist das Feature dieses Controllers auch sehr fraglich,> wenn man eine Abweichung von immerhin 7E-6 damit nicht mehr korrigieren> kann. Das ist ja mehr als eine halbe Sekunde pro Tag.
Je nachdem. Einen Quarz über einen einstellbaren Kondensator auf
Sollfrequenz zu ziehen finde ich aufwendiger. Der dreht sich ja nicht
von selbst auf den richtigen Wert.
Zieht man den Quarz einfach durch seine beiden Lastkondensatoren weit
genug, wäre die Softwarekorrektur viel einfacher. VOrausgesetzt das
funktioniert...
ETC schrieb:> Wisst Ihr, ob es eine geläufige Methode ist 32,768 kHz Quarze mit> Absicht zu verstellen,
Ja, ist es (jede billige Armbanduhr hat einen Trimmkondensator dafür),
aber beachte auch die Temperaturabhängigkeit (die am Handgelenk mit
Metallbodenplatte natürlich besonders gering ist, im PC als RTC nicht).
Vielleicht habe ich mich falsch ausgedrückt.
Bei der Softwarelösung kann der einstellbare Kondensator entfallen, da
die Korrektur vom RTC Modul des LPC übernommen wird.
Man muss nur dafür sorgen, dass die Abweichung vom Quarz von der
Sollfrequenz groß genug ist. Hierfür würden zwei fest verbaute und mit
Absich falsch dimensionierte Lastkondensatoren für den Quarz ausreichen.
Die Korrektur durch den LPC ist sehr viel genauer als 0.25 Hz. Siehe
AN10849
> Ja. Wenn schon per Trimmer trimmen, dann auf nahe 0ppm Abweichung.
Und dann baut man zweckmäßigerweise auch gleich noch einen Ofen, sonst
kann man sich den Aufwand sparen. Aber isses den wirklich wert? Der TO
hat noch gar nichts dazu geschrieben, warum er die Langzeitgenaugigkeit
überhaupt braucht.
∗Falls∗ sie wirklich nötig (und sinnvoll) ist werf ich mal noch ntp in
den Raum.
ETC schrieb:> Bei der Softwarelösung kann der einstellbare Kondensator entfallen, da> die Korrektur vom RTC Modul des LPC übernommen wird.
Die Softwarelösung ist der oben verlinkte Wiki-Artikel ;), deine
Variante ist auch eine Hardwarelösung …
> Die Korrektur durch den LPC ist sehr viel genauer als 0.25 Hz. Siehe> AN10849
So? Da steht was von ±1 s/d, das ist keineswegs irgendwie genauer,
sondern passt ziemlich gut (entspricht einem Fehler von ±0,38 Hz).
Mit der reinen Softwarelösung wärst du genauer, allerdings ist die
Frage, wie langzeitstabil dein einfacher Quarz dann ist.
ETC schrieb:> Man muss nur dafür sorgen, dass die Abweichung vom Quarz von der> Sollfrequenz groß genug ist.
Das ist doch vollkommen lächerlich. Du kannst eben nur in Schritten von
0,25 Hz korrigieren, ganz egal welche Frequenz der Quarz ohne Korrektur
hat. Etwas absichtlich zu verstellen, um es dann zu korrigieren ist eine
Idee aus Schilda. Das haben jetzt auch schon mehrere festgestellt, aber
du ignorierst das einfach - nimm doch gleich einen ganz falschen Quarz,
deiner verrückten Theorie nach kannst du den ja umso besser auf den
richtigen Wert korrigieren.
Ist wohl hoffnungslos.
Georg
Trimmkondensatoren bei Uhren zu verwenden ist schon lange out:
-ein Trimmer ist teuer, da feinmechanisches Produkt.
-ein Trimmer hat oft einen größeren Temperaturgang als ein
Festkondensator mit NP0- Keramik.
-ein Trimmer ist hochempfindlich gegen Schmutz, Feuchtigkeit, Öl..., da
all dies in den Kapillarspalt zwischen Rotor und Stator hineingezogen
wird.
-die meisten Trimmer haben für die Beläge einen Silberaufdruck, der mit
der Zeit weggerieben wird oder bei agressiver Atmosphäre einfach
weggammelt.
-Ein Trimmer hat vielmehr Platzbedarf als z.B. ein 0204 SMD-Kondensator.
-Oft ist der Kondensator schon auf dem IC realisiert, ein äußerer
Kondensator ist garnicht mehr vorgesehen.
Entweder wird der Abgleich durch Programmierung des Teilers verwirklicht
oder durch entsprechende Software .
Wegen des Temperaturgangs und Alterung der Quarze sind 20ppm (ca. 2sec
pro Tag) durchaus einhaltbar.
Bei höheren Ansprüchen muss man sich aber Andres einfallen lassen.
(Temperaturkompensation, Thermostat, Korrektur durch DCF oder GPS
usw...)
Ich habe hier 2 Uhren, bei denen ich den Sekundentakt aus je einem
4MHz-Quarz erzeuge, der einen Atmega8 oder einen Attiny2313 taktet.
Das ist so genau, daß ich die Uhrzeit nur zu dem dämlichen Wechsel von
Sommer/Winterzeit stellen muß. Mit den 32768KHz-Quarzen konnte ich nicht
solche Konstanz erzeugen.
>Quarz verziehen
Dem ungenauen Quarz hätte ich nicht verziehen...
;-)
MfG Paul
@ Paul Baumann (paul_baumann)
>Sommer/Winterzeit stellen muß. Mit den 32768KHz-Quarzen konnte ich nicht>solche Konstanz erzeugen.
Die Uhrenindustrie kann das seit Jahrzehnten. AKA Quarzuhr.
Falk Brunner schrieb:> Die Uhrenindustrie kann das seit Jahrzehnten. AKA Quarzuhr.
\Loriot
Ach?!
/Loriot
Hinweis: Ich habe das nicht geschrieben, um Dich zu ärgern. Es gibt hier
auch einige industriell hergestellte Uhren mit eben solchen
32768KHz-Quarzen. Die muß ich deutlich öfter stellen, als die oben
Genannten.
-----------------------------------------------------------------------
Eines habe ich aber hier in den letzten 2 Jahren gelernt: Es ist besser,
manche Erkenntnisse und Erfahrungen nicht zu teilen, weil sich immer
jemand findet, der einen Streit vom Zaun zu brechen versucht. Dazu bin
ich mittlerweile zu alt und auch nicht gewillt.
MfG Paul
Georg schrieb:> Das ist doch vollkommen lächerlich. Du kannst eben nur in Schritten von> 0,25 Hz korrigieren, ganz egal welche Frequenz der Quarz ohne Korrektur> hat. Etwas absichtlich zu verstellen, um es dann zu korrigieren ist eine> Idee aus Schilda. Das haben jetzt auch schon mehrere festgestellt, aber> du ignorierst das einfach
so wie ich das aus dem Datenblatt herauslese, hat der TO recht.
die kleinste Abweichung, die man korrigieren kann, ist 1/2^17=7,62939ppm
die "zweitkleinste" ist 1/(2^17-1)=7,62945ppm
die nächste ist 1/(2^17-2)=7,62951ppm
das bedeutet, dass bei einer Abweichung >7,6ppm praktisch beliebig genau
korrigiert werden kann.
Temperaturdrift und Alterung bleiben natürlich.
ETC schrieb:> Da das benötigte Register vom LPC1778 für die Kalibrierung der Uhrzeit> nur 17 Bits groß ist, kann die Frequenz von Quarz leider nicht lückenlos> korrigiert werden.
Ja, da hilft nur absichtliches Verstellen, damit diese Korrektur geht.
Ansonsten ist sie recht pfiffig und funktioniert sehr genau.
Ich benutze die gleiche Korrekturmethode auf dem AVR, aber der hat kein
solches Register. Daher voll in SW und mit 32Bit Korrekturzähler.
@ Paul Baumann (paul_baumann)
>\Loriot>Ach?!>/Loriot
HERRRR Müller Lüdenscheidt! Die Ente bleibt drin!
>Hinweis: Ich habe das nicht geschrieben, um Dich zu ärgern. Es gibt hier>auch einige industriell hergestellte Uhren mit eben solchen>32768KHz-Quarzen. Die muß ich deutlich öfter stellen, als die oben>Genannten.
Auch die Industrie ist nicht mehr das, was sie mal war.
>Eines habe ich aber hier in den letzten 2 Jahren gelernt: Es ist besser,>manche Erkenntnisse und Erfahrungen nicht zu teilen, weil sich immer>jemand findet, der einen Streit vom Zaun zu brechen versucht. Dazu bin>ich mittlerweile zu alt und auch nicht gewillt.
Nö. Ich wollte auch keinen Streit vom Zaun brechen, nur dem unbedarften
Leser deines Beitrags vermitteln, dass die 32kHz Uhrenquarze als
Zeitbasis absolut brauchbar sind, wenn man weiß, was man tut.
ETC schrieb:> Wisst Ihr, ob es eine geläufige Methode ist 32,768 kHz Quarze mit> Absicht zu verstellen, um sie beispielsweise durch RTC Module von> Controllern genauer korrigieren zu können ? Spricht generell etwas> dagegen diese Methode anzuwenden ? Kennt ihr eine bessere Möglichkeit ?
Ich halte diese "Methode" für groben Unsinn. Denn wenn man schon einen
Trimmkondensator vorsieht und sich den Aufwand macht, den Quarz
abzugleichen, dann kann man ihn auch gleich auf den Nennwert stellen.
M.a.W. der Abgleich in Hardware und der Abgleich in Software sind
Alternativen. Die schließen sich zwar nicht prinzipiell aus, aber es ist
unsinnig, sie gemeinsam zu verwenden. Sozusagen /Gürtel und
Hosenträger/.
PS: du plenkst. Zwischen Satzzeichen und vorhergehendes Wort gehört kein
Leerzeichen.
Axel Schwenke schrieb:> Ich halte diese "Methode" für groben Unsinn. Denn wenn man schon einen> Trimmkondensator vorsieht und sich den Aufwand macht, den Quarz> abzugleichen, dann kann man ihn auch gleich auf den Nennwert stellen.
der TO will doch gar keinen Trimmkondensator verwenden. Einfach mal
richtig lesen.
Er hat zwei Möglichkeiten erwähnt. Einmal den Trimmkondensator
ETC schrieb:> Um> ein zu starkes davonlaufen einer Echtzeituhr auf Grund der Ungenauigkeit> zu verhindern, kann beispielsweise die Frequenz vom Quarz mit Hilfe von> einem einstellbaren Kondensator auf möglichst genau 32,768 kHz> korrigiert werden.
oder als Alternative den Abgleich per Software
ETC schrieb:> Eine weitere Möglichkeit wäre das integrierte RTC Modul von einem> LPC1778 zu verwenden. Ist dem Controller die genaue Frequenz der Quarze> bekannt, kann je nach Abweichung zu bestimmten Zeitpunkten entweder eine> Sekunde zur Echtzeituhr addiert oder subtrahiert werden. Durch diesen> Korrekturfaktor sollten die Uhren in der Theorie sehr genau laufen.
Da der Abgleich per Software mit dem LPC1778 nur bei
Abweichungen >7,6ppm funktioniert, war seine Frage, wie man diese
Abweichung erreichen kann.
Vielen Dank nicht die mama. Du hast mich verstanden.
An die restlichen, die mir nich glauben:
Es gibt zusätzlich zur AN10849 noch ein Beispielprogramm mit
Berechnungen. Da kann man es nochmals nachlesen/ nachrechnen.
Sobald er Quarz die Abweichung von 7.6 ppm erreicht hat, kann man ihn
(theoretisch) beliebig genau über den LPC korrigieren.
Beispiel :
Sollfrequenz : 32768,000 Hz
Istfrequenz : 32767,749 Hz
Abweichung : 0,251 Hz
RTC Calibration Value im LPC Register der eingetragen werden muss :
130550
Bei jedem Sekundentakt wird nun das RTC Calibration Register im 1
inkrementiert. Sind die 130550 Werte erreicht, kann eine Sekunde addiert
oder subtrahiert werden und der QUarz wird korrigiert.
( 1 / 32768,000 ) * 0,251 = 7.659912109375 * 10^-6
7.659912109375 * 10^-6 * 130550 = 1
Siehe da : Zieht man nun nach 130550 Schritten eine Sekunde ab bleibt 0
übrig.
Falk Brunner schrieb:> @ Paul Baumann (paul_baumann)>>>Sommer/Winterzeit stellen muß. Mit den 32768KHz-Quarzen konnte ich nicht>>solche Konstanz erzeugen.>> Die Uhrenindustrie kann das seit Jahrzehnten. AKA Quarzuhr.
In den siebziger Jahren war man der Ansicht, das eine Uhr um so
genauer wird, je höher man die Quarzfrequenz treibt. Man arbeitete
sich da langsam von ca 8kHz bis ca 8MHz nach oben. Anscheinend
hat man dann erkannt, das durch spezielle Schlifftechnik auch
Quarze mit 32kHz die gleiche Genauigkeit wie 8MHz-Quarze erreichen
können. Seitdem ist wohl ein 32kHz Quarz gewissermaßen Standard
in den Uhren geworden.
Harald Wilhelms schrieb:> Seitdem ist wohl ein 32kHz Quarz gewissermaßen Standard> in den Uhren geworden.
Der normale Mitteleuropäer ist einfach mit einer Uhr am Handgelenk
zufrieden, die wenige Minuten im Jahr abweicht und die man nur bei
Gelegenheit der bescheuerten Sommer/Winterzeit mal genau einstellt.
Ich habe zwar einen Bekannten, der absoluten Wert drauf legt, dass alles
in seiner Wohnung (Uhren, PCs, Fernseher, Handys, Radio) auf
Sekundenbruchteile synchron läuft, daran arbeitet er notfalls
stundenlang - aber das ist wohl mehr eine Krankheit als eine echtes
Bedürfnis.
Georg
Axel Schwenke schrieb:> Ich halte diese "Methode" für groben Unsinn.
Das ist Quatsch.
Das Problem ist, daß das Korrekturregister mit 17 Bit einfach zu klein
ist.
Bei zu großer Genauigkeit werden die 17 Bit überschritten, aber der
Fehler ist immer noch so groß, daß er korrigiert werden müßte.
Man muß daher den Quarz soweit ziehen, daß der Fehler immer >250mHz ist.
Wie groß er genau ist, ist dabei egal.
Bei einem 32Bit Register spielt das keine Rolle mehr. Man hat dann zwar
immer noch einen nicht korrigierbaren Bereich, aber dann ist die
Genauigkeit schon hoch genug.
Ich würde daher die Korrektur voll in SW machen, die paar Byte Flash und
die paar ppm CPU-Last tun doch nicht weh.
Georg schrieb:> Ich habe zwar einen Bekannten, der absoluten Wert drauf legt, dass alles> in seiner Wohnung synchron läuft,
Naja, wenn mein Küchen-UKW-Radio und das im Fernseher eingebaute
Kabel-Radio den gleichen Sender um einige Sekunden versetzt
empfangen, klingt das schon recht komisch.
Peter Dannegger schrieb:> Axel Schwenke schrieb:>> Ich halte diese "Methode" für groben Unsinn.>> Das ist Quatsch.> Das Problem ist, daß das Korrekturregister mit 17 Bit einfach zu klein> ist.
Vielleicht hast du mich nicht richtig verstanden. ich halte es für
groben Unsinn, den Quarz erst mutwillig neben die gewünschte Frequenz zu
ziehen, um ihn dann per Fehlerkorrektur in der RTC wieder zurück zu
korrigieren. Wenn man überhaupt hardwaremäßig die Quarzfrequenz
manipuliert, dann doch gleich auf die korrekte Frequenz.
Daß die Variante mit dem 17 Bit Korrekturregister suboptimal ist, steht
noch mal auf einem anderen Blatt. Viel mehr als das "Loch" rund um die
korrekte Quarzfrequenz stört mich dabei, daß die RTC mit dieser Lösung
auch mal eine Sekunde überspringen kann. Wäre interessant zu wissen, was
passiert, wenn man sich genau zu dieser Zeit per Interrupt von der RTC
wecken lassen wollte.
> Ich würde daher die Korrektur voll in SW machen, die paar Byte Flash und> die paar ppm CPU-Last tun doch nicht weh.
Sehe ich genauso.
Axel Schwenke schrieb:> den Quarz erst mutwillig neben die gewünschte Frequenz zu ziehen,
Ich vermute mal, das sich dadurch auch die Temperaturabhängigkeit
der Frequenz verändert.
> Wäre interessant zu wissen, was> passiert, wenn man sich genau zu dieser Zeit per Interrupt von der RTC> wecken lassen wollte.
Das wäre m.E. ein Programmiererfehler. Man testetnicht auf "gleich",
sondern auf "grösser" oder "kleiner". :-)
Axel Schwenke schrieb:> Wäre interessant zu wissen, was passiert, wenn man sich genau zu dieser> Zeit per Interrupt von der RTC wecken lassen wollte.
Das kann dir doch aber selbst bei einer DCF-77-Uhr passieren, wenn
du gerade die Schaltsekunde erwischst. ;-)
Klar, sinnvoller wäre es wohl, da zwischendurch den Teiler zwischen
1:32767, 1:32768 oder 1:32769 umzuschalten, statt ganze Sekunden zu
springen. Das hätte ja dann wenigstens mal Potenzial für eine
Hardwarelösung gehabt. ;-)
@ Peter Dannegger (peda)
>Das Problem ist, daß das Korrekturregister mit 17 Bit einfach zu klein>ist.
Nö, die Jungs haben dort einfach gepennt. Das Korrekturkonzept ist nicht
viel wert. Wie man es deutlich besser macht, selbt mit nur 16 Bit, steht
im Artikel.
https://www.mikrocontroller.net/articles/AVR_-_Die_genaue_Sekunde_/_RTC#Echtzeituhr_mit_Uhrenquarz
Das hätte man auch in Hardware gießen können. Naja, vielleicht beim
nächsten Mal.
Wenn es so genau werden soll, werfe ich mal einen Quarzofen in die
Runde. Ich hoffe, es muss keine billige Lösung werden.
Wenn das nicht reichen sollte, empfehle ich einen Blick hierhin:
http://www.darc.de/de/distrikte/h/24/projekte-und-selbstbau/10-mhz-rubidium-frequenznormal/
Das bewegt sich dann im Bereich einer Abweichung von 10^-12 und sollte
für den Rest unserer Lebenszeit mehr als ausreichend sein, um morgens
den Wecker zur richtigen Zeit klingeln zu lassen.
Max
Harald Wilhelms schrieb:>> Wäre interessant zu wissen, was>> passiert, wenn man sich genau zu dieser Zeit per Interrupt von der RTC>> wecken lassen wollte.>> Das wäre m.E. ein Programmiererfehler. Man testetnicht auf "gleich",> sondern auf "grösser" oder "kleiner". :-)
Das hat mit Programmieren nichts zu tun. Die meisten RTC haben ein oder
sogar mehrere Alarm-Register und können einen Interrupt auslösen, wenn
die dort eingetragene Uhrzeit erreicht wird. Außer natürlich wenn die
RTC gerade diesen Zeitpunkt überspringt ;)
Auszug aus dem Artikel "Die genaue Sekunde":
> Wenn man sich die Idee der Festkommaarithmetik mal eine Weile durch> den Kopf gehen lässt, kommt man vielleicht auf folgende Idee.
Welch eine komplizierte Idee. 1000 ist für den µC eine krumme Zahl!
Viel einfacher: Man nimmt für die Darstellung der Sekunden eine 24- oder
32-bit-FixedPoint-Variable.
Entweder man zählt bis 60 und subtrahiert dann 60, dann hat man 6
Vorkommabits und 18 bzw. 26 Nachkommabits, oder man zählt bis 86400,
dann sind es 17 Vorkomma- und 7 bzw. 15 Nachkommabits.
Dann addiert man mit den 128 Hz des Hardware-Timers ein korrigiertes
Festkomma-128stel in die Variable - fertig.
Beispiel: Sekunde zählt bis 60, 32(6+26)-bit-FP
U32_t SCALE=67108864L,secFp; //2**26
U16_t einsDurch128Fpkorrigiert=SCALE/128+Korrektur;
ISR(TIMER2_OVF_vect) {
if(secFp += einsDurch128fpKorrigiert > 60*SCALE){secFp -= 60*SCALE;}
}
In Asm geht das besonders schön, weil man für den Vergleich und die
Subtraktion nur das oberste Byte von secPF betrachten muss. Die ganze
ISR ist vielleicht 20-40 Bytes lang. In C kann man es mit einer Union
machen.
Die ISR ist nicht zeitkritisch, da auf das Timer-Register nicht
zugegriffen wird.
Was die Leute immer mit ihren Quarzöfen haben, das sind doch
Steinzeit-Methoden. Temp-Sensor ran und Korrekturwert aus einer
Lookup-Table (LUT) geholt - fertig.
eProfi schrieb:> Was die Leute immer mit ihren Quarzöfen haben, das sind doch> Steinzeit-Methoden.
Die aber zumindest gut funktionieren.
> Temp-Sensor ran und Korrekturwert aus einer> Lookup-Table (LUT) geholt - fertig.
Geht auch ohne Software, nennt sich dann TCXO. Trotzdem ist ein OCXO
in der Stabilität besser (daher werden sie auch heute noch benutzt,
trotz „Steinzeit“), aber eben auch aufwändiger.
@ eProfi (Gast)
>Welch eine komplizierte Idee.
Was für eine schlechte Grammatik!
> 1000 ist für den µC eine krumme Zahl!
Er wird's mir hoffentlich nicht krumm nehmen ;-)
>Viel einfacher: Man nimmt für die Darstellung der Sekunden eine 24- oder>32-bit-FixedPoint-Variable.
Vollkommen nebensächlich und vor allem in erster Linie für den Leser
irritierend. Der denkt nämlich meist eher dekadisch, auch als
Programmier(anfänger). Dass man das noch geringfügig durch 2er Potenzen
optimieren kann, ist nebensächlich.
>Dann addiert man mit den 128 Hz des Hardware-Timers ein korrigiertes>Festkomma-128stel in die Variable - fertig.>Beispiel: Sekunde zählt bis 60, 32(6+26)-bit-FP>U32_t SCALE=67108864L,secFp; //2**26>U16_t einsDurch128Fpkorrigiert=SCALE/128+Korrektur;>ISR(TIMER2_OVF_vect) {> if(secFp += einsDurch128fpKorrigiert > 60*SCALE){secFp -= 60*SCALE;}>}>In Asm geht das besonders schön, weil man für den Vergleich und die>Subtraktion nur das oberste Byte von secPF betrachten muss. Die ganze>ISR ist vielleicht 20-40 Bytes lang. In C kann man es mit einer Union>machen.
Klar, diese Darstellung ist gaaaaanz sicher vollkommen einleuchtend und
verständlich . . . Der liebe Josef G. lässt grüßen . . .
>Die ISR ist nicht zeitkritisch, da auf das Timer-Register nicht>zugegriffen wird.
Eben darum kann man sich auch eine handvoll zusätzlicher, suboptimer
Takte duch die dekadische Version locker erlauben.
>Was die Leute immer mit ihren Quarzöfen haben, das sind doch>Steinzeit-Methoden. Temp-Sensor ran und Korrekturwert aus einer>Lookup-Table (LUT) geholt - fertig.
Nö, das ist "nur" ein digialer TCXO. Genau, aber nicht so genau wie ein
Quarzofen.
