Hi! Ich habe einen Atmega8 an einen Rondostat HR20e Heizkörperthermostat gehängt und will vom Thermostat mit seriell Daten empfangen (9600 Baud). Erste Versuche mit dem internen Oszillator auf 2Mhz ergaben nur Müll am Uart. Da ich keine passenden Quarze da hatte und unbedingt weiter machen wollte, habe ich den Takt nachgetrimmt. 1.) Aktuellen Takt gemessen Dazu Endlosschleife (avr-gcc) bei deaktivierten Interrupts: - Pin high setzen - _delay_ms(50) - pin low - _delay_ms(50). Frage dazu: Ist das geeignet (genau genug) um den tatsächlichen Takt zu messen und wie kann kann man das besser machen? 2.) Intervall per DSO gemessen (=120ms) 3.) Kallibrierungsbyte angepasst so dass das gemessene Intervall 100ms beträgt. 4.) Lötkolben und Kältespray auf den Atmega losgelassen, keine Veränderung am Takt festgestellt (verstehe ich nicht, das hätte man doch sehen müssen...?) 5.) Kommunikation getestet, geht :) 6.) Um bei Abweichungen eine größere Toleranz zu erreichen: Im Makefile F_CPU auf 1843200 gesetzt (Baudratenquarz) und Schritte 1-5 wiederholt, also den internen 2Mhz Takt auf 1,8432Mhz "verstellt". Die Übertragung läuft seit 2 Tagen im 4 Minutentakt ohne Aussetzer. Was meint ihr, kann das klappen oder wird es Probleme geben? Die Temperaturen ändern sich ja doch erheblich so nah am Heizkörper. Gruß, Chris
Alternativ kann man auch einen Uhrenquarz anhaengen und auf diesen Synchronisieren. Der Aufwand Quarzgenauigkeit zu erreichen ist etwas gross, wenn ich den Preis eines Quarzes, etwa 0.2 Euro, einsetze. Heisst, ich wuerde mir diese Klimmzuege nicht antun und einen Quarz einsetzen.
Und wenn einem Quarze zu aufwendig sind, dann gibt es noch die Keramikschwinger als Dreibein mit integrierten Kondensatoren.
@ Chris (Gast) >wollte, habe ich den Takt nachgetrimmt. Schon mal ne gute Idee! Mal endlich einer der nicht blind auf den RC-Oszillator vertraut. >Frage dazu: Ist das geeignet (genau genug) um den tatsächlichen Takt zu >messen Naja, eigentlich schon. > und wie kann kann man das besser machen? Timer mit Output Compare/PWM Funktion benutzen und einen Takt mit ~50% Tastverhältnis erzeugen. Ist absolut präzise, egal was die CPU macht. >2.) Intervall per DSO gemessen (=120ms) DSO ist hart an der Grenze der Messgenauigkeit. Dafür ist es nicht wirklich gedacht. Ein Einfacher Freqeunzzähler ist das deutlich besser, selbst die aus einem einfachen Multimeter. >4.) Lötkolben und Kältespray auf den Atmega losgelassen, keine >Veränderung am Takt festgestellt (verstehe ich nicht, das hätte man doch >sehen müssen...?) Nöö, dein Oszi misst wenn es hoch kommt mit 1% Auflösung, Laut Datenblatt driftet der RC-Oszillator um ca. 1,2%/20K. >Die Übertragung läuft seit 2 Tagen im 4 Minutentakt ohne Aussetzer. Das wird sie solange, wie die Temperatur nicht mehr als sagen wir +/-20K schankt oder die Spannung um 0,1V oder mehr sich ändert. >Die Temperaturen ändern sich ja doch erheblich so nah am Heizkörper. Dann wird es eng. Nimm einen Quarz. MfG Falk
> Frage dazu: Ist das geeignet (genau genug) um den tatsächlichen Takt zu > messen [..] Gute Frage. Das wirst Du wahrscheinlich selbst feststellen falls es Probleme gibt an der Heizung.. Und wenn nicht dann wars genau genug :-) > [..] und wie kann kann man das besser machen? Ich würde dafür die 'Toggle OCn on compare match'-Funktionalität des Timers verwenden, die ist genauer (im Sinne von fester mit dem Takt verdrahtet). Atmel hat übrigens auch (mindestens) eine AppNote (AVR053: "Calibration of the internal RC oscillator") die sich mit dem Thema beschäftigt (selbige AppNote läuft aber in die 'andere' Richtung, also Referenztakt von aussen angelegt und der µC dreht so lange am Rad bis es passt).
Danke für die Hinweise. @prx: Diese 3beiner (Keramikresonatoren) kannte ich noch gar nicht... wird getestet :) @Falk: Ich habe hier so einen "Gigaherz Frequenzzähler", ein etwas älterer Bausatz. Mal schauen was der sagt.
Da besonders der interne Oszillator temperaturabhängig, wäre wohl schon ein regelmäßiger Neuabgleich in kurzen Abständen sinnvoll. Idee zum drüber Nachdenken: Peter Dannegger hat in seinem Bootloader eine Autobaud-routine. Funktioniert bei mir mit 115,2kbaud mit internem RC-Oszillator hervorragend. (Respekt und Dank nochmal an Peter!) Vielleicht ist das ja ein Ansatz. Gruß, Dieter
Eben eine Frage des Aufwands... Da ich mit dem Modul eh die Temperatur erfasse, könnte man das einbeziehen. Oder man lässt eine Uhr mitlaufen, vergleicht deren Zeit mit der (ungenauen...) Uhr des Rondostats und errechnet aus dem Delta die Taktabweichung, oder.... Fürs erste lasse ich das so, mal gespannt ob es Probleme gibt. Dann kommen die Keramikresonatoren rein.
Ich hab es bei mir so gemacht: Eine Routine versucht eine Kommunikation aufzubauen, danach wird das Kalibrierbyte inkrementiert. Wenn die Kommunikation mit den Kalibrierbytes 50 bis 70 funktioniert, dann nutze ich für das Hauptprogramm als Kalibrierbyte 60.
Leute, was macht ihr nur für Klimmzüge, wenn es doch mit einem einfachen Quarz getan wäre. Überlegt mal, wieviel Arbeitszeit jede dieser "Lösungen" verdampft, geschweige denn die Zeit für die unzähligen Beiträge in diesem Forum zu genau diesem Thema. *** Kopfschüttel ***
Also ich finde das Thema schon interessant. Nicht, um Quarze an Stellen einzusparen, wo man locker welche einbauen könnte, sondern für Anwendungen wo man keine einbauen kann (z.B. wegen mechanischer Stoßfestigkeit). Ich würde im konkreten Fall mittels Capture-Input und einem Timer die Bitzeiten der uart-Gegenstelle messen und den eigenen Takt so anpassen, dass es passt. Grüße, Peter
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.