HMSensor mit Uhrenquarz

[Matsch]

Aktuell will ich den o.g. Sensor das erst Mal mit einem Uhrenquarz betreiben. Zunächst mit dem internen Oszillator in Betrieb genommen, obwohl Quarz und Cs schon bestückt. Alles klar, ich kann per ISP den Bootloader flashen.
Nun stelle ich auf Low Frequency crystal oscillator um (E5 D2).
Sofort ist kein Zugriff auf den Atmega mehr möglich! Verfused? Hmm, vielleicht schwingt ja auch der Oszillator nicht.
Ich versuche, ein MCU-Detect zu machen. Manchmal kommt sogar ein Code, aber ein falscher. Oft ist nur eine oder zwei Stellen falsch, der Rest richtig.
D.h. doch aber, ein bißchen was geht doch. Und plötzlich meldet er den korrekten Typ, sagt mir auch, dass 32,768 als Takt benutzt wird!
Jetzt versuche ich, ihn auf den internen Oszillator zurückzusetzen - und siehe da, nach vielen schiefgegangenen Versuchen gelingt das plötzlich auch und nun habe ich wieder ungestörten Zugriff.

Das heißt doch, der Oszillator funktioniert nicht stabil.
Ich habe genau den Quarz eingesetzt, der in der Stückliste angegeben ist, den CC7V-T1A. Laut Datenblatt benötigt der eine CL von 9 pF.
Laut Stromlaufplan sind C4/C5 mit 9 pF bestückt, d.h. zusammen mit der Lastkapazität des XTAL-Eingangs von 6 pF sind das schon mal 15 pF!
Liegt dort der Grund?
Hat schon mal jemand an dieser Stelle mit diesen Bauelementen den Low frequency Modus benutzt und Erfolg gehabt?
Für mich sieht das so aus, als ob man die C4/C5 ganz entfernen oder auf 2,7 pF heruntersetzen sollte.

[Matsch]

Hmm, ich habe mal die Stromlaufpläne von eQ-3 angesehen. Da gibt es welche mit Atmega328P und Uhrenquarz.
Sieht so aus, als habe der Quarz einen CL von 12,5 pF - und bestückt sind als Kondensatoren 12 pF.

[HMSteve]

Ich fand fuer Deinen Quarz ein CL von 12.5pF? Wenn Du 5pF parasitaere Kapazitaeten annimmst, muesstest Du also immer noch 2x15pF zusaetzlich bestuecken.
Ich hatte mir mal einen 6pF Quarz besorgt, um die zusaetzlichen Cs zu sparen, das lief gut.

Viele Gruesse,
Stephan

[Matsch]

Ääh?
Der von mir bestückte und von papa vorgesehene Quarz ist mit 9 pF angegeben. 12,5 pF hat der Quarz, den eQ-3 einsetzt.
Steht so auch im Datenblatt des Atmega, dass man bei einem Quarz mit 6 pF keine Cs benötigt.
Als Formel steht da C = 2 x CL - CS

CS ist die Streukapazität.

Einen Quarz mit 6 pF habe ich nicht gefunden.

Hab's noch nicht verstanden. Müssten die Cs nun kleiner oder größer als 9 pF sein?

[HMSteve]

Stimmt natuerlich, den CC7V-T1A gibt es auch mit 9pF sowie auch 6pF, allerdings sind die mit 12,5pF sehr ueblich. Wenn Du ihn aus verlaesslicher Quelle hast, werden die 9 aber schon stimmen.
Die Formel verstehe ich nicht. Der Quarz sieht die zusaetzlichen Cs in Reihe und diese Reihenschaltung parallel zu parasitaeren Kapazitaeten, jene von mir hier angenommen mit 5pF. Wenn die zusaetzlichen Cs gleich gross sind, muesste es also heissen CL/2+5pF=Cquarz. Also wuerde Deine CL-Bestueckung mit 2x9pF ungefaehr fuer einen 9pF-Quarz passen. Bei einem 12.5pF-Quarz waeren 2x15pF zu bestuecken, oder evtl 2x12pF, bei einem 6pF-Quarz gar keine separaten Cs.

Die beiden Varianten wuerde ich probieren, wenn keine geht und die Fuses passen (lange Anlaufzeit einstellen), liegts wohl nicht an den Cs. Quarz schon getauscht?

Viele Gruesse,
Stephan

[Matsch]

War der letzte Quarz im Vorrat, insofern momentan kein Ausstausch möglich. Quarz stammt von reichelt.
Nach deiner Darstellung wären die beiden Cs mit je 9 pF doch richtig. Umso verwunderlicher, dass es mit der Kombination Probleme gibt.

[Matsch]

Inzwischen ist einige Zeit vergangen, ich habe andere Quarze mit 6pF beschafft. Lt. Datenblatt wären für den keine weiteren externen Kondensatoren erforderlich. Pustekuchen, keine Kommunikation mit AVRDUDE möglich. Am Oszi sehe ich am Quarz aber eine Sinusfrequenz von ca. 32 kHz, allerdings mit sehr geringer Amplitude, Spitze-Spitze nur 200 mV. Letzteres könnte aber auch an der Belastung durch die Probe liegen.

Nun frage ich mich, ob ich noch irgendwas anderes in AVRDUDE einstellen muß. Bitrate? Habe ich aber schon alle möglichen Varianten durchprobiert.
Es ist ja nicht so, dass gar nichts funktionieren würde, aber offensichtlich werden immer wieder falsche Bytes übertragen bzw. erkannt. Mit "Detect" wird meist eine falsche ID erkannt, wobei auffällt, dass da meist nur ein Byte falsch ist, aber jedes Mal ein anderes. Hin und wieder erkennt er den richtigen Code. D.h. prinzipiell erfolgt eine Kommunikation. Wenn nun aber der Takt nicht stabil ist und immer mal aussetzt oder die Frequenz verändert, käme es zu Übertragungsfehlern.
Ich frage mich, hat schon mal jemand erfolgreich einen Uhrenquarz eingesetzt und wie hat er dabei die Fusebits gesetzt?

Ich hatte kurz die Hoffnung, weitere Experimente dazu mit dem 328PB zu machen, weil der ja eine Mechnik eingebaut hat, bei fehlendem Takt automatisch auf den internen 128kHZ-Oszillator umzuschalten, da dürfte man ja den Chip nicht ganz verlieren.
Wie ich dem Datenblatt aber entnehme, funktioniert diese Taktdetektion nur für die Varianten externer Takt und Low Power Oscillator, nicht für Low Frequency Oscillator.

[TomMajor]

Ich frage mich, hat schon mal jemand erfolgreich einen Uhrenquarz eingesetzt und wie hat er dabei die Fusebits gesetzt?

Bin nicht sicher ob du den 32k Quarz als timer2 Osc (RTC) oder als system clock für den gesamten AVR hernehmen willst.

Als RTC wurde das schon oft gemacht, z.B. aus Gründen
a) kleinerer Ruhestrom
https://github.com/TomMajor/SmartHome/b ... -save-mode

b) Kopplung an HM Thermostate wegen dem benötigten genauen Timing, Stichwort EXTRAMILLIS Feintuning.
viewtopic.php?f=76&t=65320&start=210

Dass man den 32k als system clock einsetzt ist imho extrem selten.
Laut datasheet aber möglich, allerdings sind dann unsymmetrische 18pF XTAL1 und 8pF XTAL2 angegeben statt 6/6 im RTC Betrieb.
Die Formel C = 2 x CL - CS gilt m.E. nur für RTC, nicht für system clock.

[Matsch]

Danke dir, schau ich mir alles an. Letzten Endes stand hier die Ruhestromersparnis an erster Stelle. Da bin ich vielleicht auch falsch rangegangen. Ursprung war ja der HMSensor, der wahlweise einen Uhrenquarz benutzt. Aus der Website des HMSensors bin ich nicht schlau geworden, ob dann die gleichen Fuses wie bei internem Takt zu verwenden sind. Hoffe, ich bekomme da Anregung über deine Links.

Im letzten Fall habe ich das allerdings so verstanden, dass die 18pF und 8pF die interne Eingangskapazität der Taktanschlüsse sind, nicht die externen Cs. Die richten sich ja noch nach der spezifizierten Lastkapazität des Quarzes.

Ich bin aber drauf und dran, doch alles pauschal nur noch mit einem 8MHz-Quarz bzw. Resonators zu machen, das scheint problemloser zu sein.

[TomMajor]

ja die 18/8 pF sind die internen Kapazitäten, sie weisen aber auf eine Asymmetrie hin die man eigentlich dann bei den externen berücksichtigen müsste.
Für den Ruhestrom (sleep), also RTC mode, hilft der 32k Quarz auf jeden Fall, 4uA vs. 1uA, die Fuse sollte dann auf 8MHz RC internal stehen.

Falls du aber Energie sparen willst für den Betriebsstom, mit 32k system clock bringt das glaub ich nicht viel. Wenn ich mich recht erinnere gibt es Untersuchungen für moderne CPUs mit dynam. Taktfreq. wo rauskommt dass mit hoher Freq. kurz die Berechnung machen und dann Idle/Sleep effizienter ist als mit langsamer Freq. entsprechend länger zu brauchen.