Bisher verwende ich für meine STM32-Projekte einen 32,768 kHz-Kristall
für die Low Speed External (LSE) clock. Die notwendigen Kapazitäten der
beiden Widerstände waren relativ einfach auszurechnen.
Jetzt habe ich vor kurzem erfahren, dass auch der g_m-Wert (auf Englisch
"transconductance") eine Rolle spielen soll und dieser im Datenblatt
steht. Leider steht in meinem Datenblatt nichts dergleichen, und auch
bei anderen Herstellern habe ich keine g_m-Werte gefunden.
Jetzt habe ich mir gedacht, ob man sich das ganze Theater nicht sparen
kann, indem man einfach einen Oszillator verwendet? Hat ein Oszillator
irgendwelche Nachteile gegenüber einem Kristall (speziell beim STM32)?
Die Werte der Kondensatoren an dem Quarz sind im Allgemeinen relativ
unkritisch. Man kann da durchaus PiMalDaumen verwenden. Wenn du hingegen
eine genau abgleichbare Frequenz haben willst, mußt du sinnvollerweise
einen Trimmkondensator vorsehen.
W.S.
Christian schrieb:> Jetzt habe ich vor kurzem erfahren, dass auch der g_m-Wert (auf Englisch> "transconductance") eine Rolle spielen soll und dieser im Datenblatt> steht.
Der spielt eine Rolle, es würde mich aber sehr wundern wenn den jemand
ins Datenblatt des IC schreibt.
Was meistens angegeben wird ist die Anschwingreserve, angegeben z.B.
über den Umweg der "negative Resistance". Am Ende musst du schauen was
im Datenblatt des IC für ein Quarz benötigt wird, und dementsprechend
einen Quarz auswählen.
Christian schrieb:> Hat ein Oszillator> irgendwelche Nachteile gegenüber einem Kristall
Höherer Stromverbrauch, längere Anschwingzeit, evtl Störungen durch die
recht steilen Flanken, kommt auf die Anwendung an.
W.S. schrieb:> Die Werte der Kondensatoren an dem Quarz sind im Allgemeinen relativ> unkritisch. Man kann da durchaus PiMalDaumen verwenden. Wenn du hingegen> eine genau abgleichbare Frequenz haben willst, mußt du sinnvollerweise> einen Trimmkondensator vorsehen.
Für eine Bastellösung bei Raumtemperatur ja. Für ein Serienprodukt zu
beidem nein.
Thomas schrieb:> Am Ende musst du schauen was> im Datenblatt des IC für ein Quarz benötigt wird, und dementsprechend> einen Quarz auswählen.
Ja, da sind Hunderte angegeben. Aber bei g_m hört es nicht auf:
Eigentlich bin ich nur auf g_m und g_mcritical gestoßen, weil ich wissen
wollte, mit welchem "level" der LSE-Quarz "gedriven" werden soll: low,
medium low, medium high, high.
Beim Oszillator ist doch vieles einfacher. Längere Einschwingzeit ist
bei einer Batterie-unterstützten Uhr wohl belangslos.
Die Ganggenauigkeit läßt sich übrigens in Software korrigieren.
Oh Mist, da habe ich etwas vergessen.
Die Batterie ist mit dem STM32 verbunden, als eine Art
Minimalversorgung. Damit wird u.a. der LSE am Laufen gehalten, damit die
Uhr weiterhin funktioniert. Aber das geht natürlich nur mit einem Quarz!
Mit einem Oszillator müßte ich diesen ebenfalls an Vbat anschließen, was
die Batterie strapaziert.
Wobei, der Stromverbrauch wird bei Oszillatoren von mA bis uA angegeben.
Ist so eine große Schwankung wirklich möglich?
Christian schrieb:> Oh Mist, da habe ich etwas vergessen.>> Die Batterie ist mit dem STM32 verbunden, als eine Art> Minimalversorgung. Damit wird u.a. der LSE am Laufen gehalten, damit die> Uhr weiterhin funktioniert.
War ja klar. Es geht eben nicht nur um irgendein STM32 Projekt,
sondern um eine Uhr, die stromsparend die Zeit halten soll.
> Aber das geht natürlich nur mit einem Quarz!
Zumindest ist das der Weg, den ST vorgesehen hat und für den die
Stromaufnahme des µC minimal wird.
> Mit einem Oszillator müßte ich diesen ebenfalls an Vbat anschließen, was> die Batterie strapaziert.
Das kommt auf den Oszillator an. Aber wenn es eine Uhr werden soll, dann
würde man wohl auch keinen stinknormalen Oszillator verwenden, sondern
eben ein Uhren-IC, eine sogenannte Echtzeituhr.
> Wobei, der Stromverbrauch wird bei Oszillatoren von mA bis uA> angegeben. Ist so eine große Schwankung wirklich möglich?
Wenn man Äpfel mit Birnen vergleicht: natürlich. Einen Oszillator für
eine Echtzeituhr wird man natürlich extra stromsparend auslegen, die Uhr
soll ja mit minimaler Versorgung (aus einer Batterie oder gar nur einem
Goldcap-Kondensator) möglichst lange weiterlaufen. Einen Oszillator für
eine höhere Frequenz, sagen wir mal 16MHz für einen Arduino, der auch
noch 5V Logikpegel liefern muß, den kann man nicht genauso stromsparend
bauen. Muß man aber auch nicht.
Ich kann übrigens auch gar nicht erkennen, wo dein Problem liegen soll.
Ja, 32kHz Quarze gibt es mit einem breiten Spektrum an Eigenschaften.
Und ja, eine gegebene Oszillatorschaltung (z.B. die in einem µC
integrierte) funktioniert nur für einen gewissen Bereich dieses
Spektrums. Aber warum sollte das für dich ein Problem sein? Wenn du
einfach einen Quarz aus deiner Teilekiste an den STM hängst, dann wird
das mit 99%iger Wahrscheinlichkeit funktionieren. Und wenn nicht, dann
nimmst du einen anderen Quarz. Für ein Einzelprojekt doch vollkommen
egal.
Wenn du jetzt ein Gerät in Millionenstückzahlen bauen wölltest und wenn
du dafür Quarze bei zig verschiedenen Herstellern auf Preis und
Datenblattwerte anschauen müßtest ... dann wäre das etwas anderes.
Christian schrieb:> Ja, da sind Hunderte angegeben. Aber bei g_m hört es nicht auf:> Eigentlich bin ich nur auf g_m und g_mcritical gestoßen, weil ich wissen> wollte, mit welchem "level" der LSE-Quarz "gedriven" werden soll: low,> medium low, medium high, high.
Dann nimm einen der vom Hersteller angegeben ist. Oder du erzählst ein
paar details was du eigentlich vorhast. Für ein Einzelstück zahlt sich
der Aufwand wohl kaum aus.
Das gm und drive-level hängen auch nur indirekt zusammen. Wenn du ein zu
hohes drive level nimmst wirkt sich das negativ auf den Langzeitdrift
aus und alle Datenblattparameter sind meistens für ein sehr kleines
drive level spezifiziert. Wird leider aber oft nicht angegeben für
welches drivelevel die Parameter gelten.
Christian schrieb:> Wobei, der Stromverbrauch wird bei Oszillatoren von mA bis uA angegeben.> Ist so eine große Schwankung wirklich möglich?
Typisch sind sicher ein paar hundert uA für 32k. Die Dinger sind nicht
für low-power Anwendungen wie deine gemacht. Ich sehe hier auch keinen
Grund dafür.
Axel S. schrieb:> War ja klar. Es geht eben nicht nur um irgendein STM32 Projekt,> sondern um eine Uhr, die stromsparend die Zeit halten soll.
Nein, es ist ein STM32-Projekt, und der STM32 enthält eine Echtzeit-Uhr,
die ich nutzen will.
> Das kommt auf den Oszillator an. Aber wenn es eine Uhr werden soll, dann> würde man wohl auch keinen stinknormalen Oszillator verwenden, sondern> eben ein Uhren-IC, eine sogenannte Echtzeituhr.
Wie gesagt, die Uhr ist schon im STM32 drin, es fehlt nur ein Taktgeber.
Beim Prototyp habe ich laut Reichelt einen Uhrenquarz verwendet, der wie
ein Insekt mit Fühlern aussah. Aber jetzt suche ich etwas kleineres. Und
die Kategorie Uhrenquarz kennt Digikey nicht.
>> Wobei, der Stromverbrauch wird bei Oszillatoren von mA bis uA>> angegeben. Ist so eine große Schwankung wirklich möglich?>> Wenn man Äpfel mit Birnen vergleicht: natürlich.
Logisch. Ich habe aber Oszillatoren verglichen, die ich auf meinem Board
einsetzen würde. Mein Favorit hat einen Eingangsstrom von 3,5 uA, bei
einem anderen waren es einige mA. Natürlich eine andere Serie, aber
woher soll ich wissen, welche Serie wofür gedacht ist?
> Einen Oszillator für eine Echtzeituhr wird man natürlich extra> stromsparend auslegen, die Uhr soll ja mit minimaler Versorgung> [...] möglichst lange weiterlaufen.
Und den erkennt man (außer am Verbrauch) woran?
> Wenn du> einfach einen Quarz aus deiner Teilekiste an den STM hängst, dann wird> das mit 99%iger Wahrscheinlichkeit funktionieren.
ST veröffentlich extra einen Oscillator Guide. Da steht drin, bei
welchen Transconductance-Werten man welchen Drive Level zu benutzen hat.
Ja, mein Prototyp, wo ich den Guide noch nicht kannte, hat funktioniert,
aber wer weiß, wie lange?
> Und wenn nicht, dann nimmst du einen anderen Quarz. Für ein> Einzelprojekt doch vollkommen egal.
Es soll auch noch drei Jahren, und bei 40+°C funktionieren. Ich möchte
das Ergebnis auch an Freunde verschenken, da wäre später ausbessern
nicht so toll.
Thomas schrieb:> Dann nimm einen der vom Hersteller angegeben ist. Oder du erzählst ein> paar details was du eigentlich vorhast. Für ein Einzelstück zahlt sich> der Aufwand wohl kaum aus.
Ich dachte, die Liste ist unsortiert, aber das ist sie nicht, d.h., für
jeden Quarz ist angegeben, für welchen Controller das ist. Gut, werde
ich durchsehen.
Vorhaben habe ich nur, dass ich die Echtzeit-Uhr im STM32 nutzen will.
Das mit dem Einzelstück ist ja schön und gut, aber entweder der Quartz
funktioniert richtig oder nicht -- das hat doch mit der Anzahl nichts zu
tun?! Oder meint ihr, 0,1% der Boards laufen dann falsch, und das merkt
man nur bei einer Großserie?
> Das gm und drive-level hängen auch nur indirekt zusammen. Wenn du ein zu> hohes drive level nimmst wirkt sich das negativ auf den Langzeitdrift> aus und alle Datenblattparameter sind meistens für ein sehr kleines> drive level spezifiziert. Wird leider aber oft nicht angegeben für> welches drivelevel die Parameter gelten.
Also in dem Design Guide steht eine Tabelle für jeden Controller, der
g_m und g_mcritical mit dem Drive Level in Verbindung setzt.
Christian schrieb:> Jetzt habe ich mir gedacht, ob man sich das ganze Theater nicht sparen> kann, indem man einfach einen Oszillator verwendet? Hat ein Oszillator> irgendwelche Nachteile gegenüber einem Kristall (speziell beim STM32)?
Braucht mehr Strom, ist teurer und die meisten haben ein extrem kleines
Gehäuse. Wer das löten kann, nimmt den SIT1552AI-JE-DCC-32.768E. Das ist
ein temperaturkompensierter MEMS, max. ±12ppm über -40...+85°C,
1.8...3.6V. Und er altert nicht so stark wie ein Quarz.
Für Grobmotoriker gibt's den SIT1630AI-S4-DCC-32.768E im SOT-23. Das ist
kein TCXO, aber immerhin noch etwas genauer als ein normaler Uhrenquarz.
Beide brauchen ca. 2uA.
Bauform B. schrieb:> Für Grobmotoriker gibt's den SIT1630AI-S4-DCC-32.768E im SOT-23. Das ist> kein TCXO, aber immerhin noch etwas genauer als ein normaler Uhrenquarz.> Beide brauchen ca. 2uA.
Nicht schlecht, den werde ich mal ausprobieren. Für das Projekt selber
habe ich jetzt doch einen Quarz gewählt, das scheint mir sicherer. Und
der Drive Level läßt sich später über Software korrigieren.
