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.
da ist nix exakt, Temperaturdriften, .. wenn du es so genau haben willst, nim DCF uns synchronisiere einmal täglich
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...
Der einstellbare Kondensator würde bei der Softwarelösung entfallen. Deshalb diese Idee.
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.
Wäre schon zu haben, kein muss. Die Softwarelösung wäre ohne großen Aufwand und zusätzliche Bauteile/Komponenten umsetzbar.
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
Da will wohl einer unbedingt ein Problem für seine Lösung suchen …
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.
MaWin schrieb: > (jede billige Armbanduhr hat einen Trimmkondensator dafür) Jede? Ich habe hier mehrere ohne aber keine mit. Seltsam. Schöne Grüße
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.
Nimm einen DS32kHz von Maxim. Der hat 2ppm, also max. 1 Minute pro Jahr Abweichung. Alternative als Komplettbaustein inkl. RTC wäre der DS3231.
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.
:
Bearbeitet durch User
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.
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.