Hi, für ein kleines Weihnachts LED-Gimmick wollte ich eigentlich einen "Timer-Modus" einbauen, wie ihn alle üblichen LED-Lichterketten haben. Also wenn der "Timer-Modus" per Pushbutton aktiviert wird, soll das LED-Dingens noch für 10h laufen und dann bis zur gleichen Uhrzeit am nächsten Tag in den Sleepmode gehen. Plattform ist ein STM32G030. Leider konnte ich sowohl mit dem LSI als auch mit dem HSI16 bzw. den abgeleiteten Takten keine brauchbare Genauigkeit erhalten, um die Funktion halbwegs zufriedenstellend zu implementieren. Der LSI ist dafür absolut unbrauchbar, ich habe dort schon bei 10 Minuten einige Sekunden Abweichung. Das sind in 24h dann >15 Minuten. Auch der HSI ist leider nicht viel besser. Im Datenblatt ist auch nur 1% Genauigkeit angegeben, was auch ~15 Minuten / 24h entspricht. Auch eine Messung der LSI-Frequenz mit Hilfe des HSI ergab kein besseres Ergebnis, in diesem Fall addieren sich ja dann sogar noch die Toleranzen. Wie machen das denn diese ganzen Lichterketten? Verwenden die tatsächlich Quarze? Ohne eine externe Referenz kann man ja sonst keine bessere Genauigkeit bekomen. Gruß Markus
:
Bearbeitet durch User
Markus M. schrieb: > Verwenden die tatsächlich Quarze? Warum nicht? In China kosten Uhrenquarze in größeren Stückzahlen nur ca. 2 Cent.
Nimm einen 32K Quarz an LSE und werde glücklich. Alternativ ne Batteriegepufferte RTC. VG Paul
Für eine uhrenähnliche Präzision braucht man einen Uhrenquarz. Deswegen findet man Uhrenquarze in Uhren. No shit, Sherlock!
Markus M. schrieb: > kleines Weihnachts LED-Gimmick Wenn die Temperatur recht konstant sein sollte, wie wäre HSI mit Kalibrierung?
Ein kleiner Quarz fällt leider flach, da der STM32G030J6 im 8-Pin Gehäuse kein OSC-Out hat, also ginge nur ein Quarzoszillator (LSE). Ist wohl kein wirklich gängiges Bauteil. Bliebe noch ein kleiner Oszillator am HSE-Eingang. Eine externe Referenz zum Kalibrieren des HSI habe ich leider nicht, ich habe mir den HSI Takt mal auf einen Pin ausgeben lassen, es waren lt. Messung mit dem DSO 16.00 .. 16.01 MHz, also eigentlich nichtmal 1% Abweichung - ist natürlich die Frage wie genau das DSO (Siglent SDS1104E) misst. Ich hatte das alles schon auch mit RTC und Deepsleep / Standby Mode am laufen, aber wie gesagt, der LSI ist absolut unbrauchbar dafür von der Genauigkeit. Habe es nun sehr simpel implementiert: Der Timer läuft mit dem Systemtakt (24MHz PLL aus dem HSI generiert), das läuft durch einen Prescaler von 24000 (=23999), also 1000 Pulse pro Sekunde, dann setze ich den Timer-Reload auf 999, somit habe ich einen Timer-Interrupt pro Sekunde. In einer ISR checke ich dann einen Sekunden-Zähler und wenn dieser 86400 erreicht hat (einen Tag) wird ein Alarm-Flag gesetzt, welches letztendlich im Hauptprogramm abgefragt und zurückgesetzt wird. Naja, für dieses Projekt ist der Drops wohl gelutscht, aber wird mir eine Lehre sein in Zukunft zumindest den Platz für einen Oszillator auf dem Board vorzusehen.
Markus M. schrieb: > für ein kleines Weihnachts LED-Gimmick wollte ich eigentlich einen > "Timer-Modus" einbauen, ist eine zentrale Steuerung über ein RFM Funkmodul eine Option? Das bräuchte eine SPI Schnittstelle zur Ansteuerung. Dann kann man zentral Schalten und auch Sonnenstandabhängig.
Oder vielleicht einen Käfer mit 6 Beinen mehr nehmen? L011 oder L021 sind nicht viel größer, passt aber ein Quarz dran.
Markus M. schrieb: > Wie machen das denn diese ganzen Lichterketten? Verwenden die > tatsächlich Quarze? Ich kenne LED-Kerzen von QVC, deren Timer nutzt auch nur einen R/C Oszillator mit der entsprechenden Ungenauigkeit.
Ja der allgemeine 32 bit Wahn. Ein 8 pinniger PIC haette problemlos noch einen Uhrenquarz verkraftet.
Auch, wenn's etwas unbequem ist: Ein 74LVC1GU04 mit ein paar Widerständen und zwei Kondensatoren zum Uhrenquarz tun's auch. Jedenfalls sind das billige Standard-Bauteile, während ein fertiger Quarz-Oszillator ...
PICklig schrieb: > Ja der allgemeine 32 bit Wahn. > Ein 8 pinniger PIC haette problemlos noch einen Uhrenquarz verkraftet. Wobei das eine nun wirklich so garnicht vom anderen abhängt. Ist halt offenbar eine Design-Entscheidung gewesen, bei der 8-Pin Variante auf den OSC-Out zu verzichten und dafür lieber ein paar andere Funktionen auf den Pin zu legen. Die größeren Modelle der STM32G030 Serie haben einen OSC-Out. Die 8-Pin Version ist schon etwas hakelig. 5 Pins fallen eigentlich schon weg, zumindest wenn man auch noch Debuggen will/muss: Vcc, GND, SWDCLK, SWDIO und NRST Wenn ich jetzt noch einen Quarz anschließen würde hätte ich nur noch 1 Pin frei, brauche aber mindestens 2. Würde ich es nochmal designen, würde ich so einen winzigen Quarzoszillator mit drauf packen, z.B. sowas hier: https://www.tme.eu/de/details/osc32.768k-3.3i_s2/quarzgeneratoren-smd/yic/osc32-768k-3-3i-s22/ ca. 2.5mm x 2mm Platz würden sich noch finden...
Markus M. schrieb: > Der Timer läuft mit dem Systemtakt (24MHz PLL aus dem HSI generiert), > das läuft durch einen Prescaler von 24000 (=23999), also 1000 Pulse pro > Sekunde, dann setze ich den Timer-Reload auf 999, somit habe ich einen > Timer-Interrupt pro Sekunde. Mach es noch simpler: Lass die PLL weg, die kostet nur Strom. Nimm als Timer den SYSTICK, der hat 24 Bit, damit kommst du von 16MHz direkt auf 1 Sekunde und kannst auf 1/16000000 trimmen. Dann bleibt nur noch der Fehler durch Temperaturschwankungen.
Die Kalibrierung von LSI/HSI ist schon eine umfangreiche Aufgabe: https://www.st.com/content/ccc/resource/technical/document/application_note/group1/91/56/84/88/94/22/41/8d/DM00469014/files/DM00469014.pdf/jcr:content/translations/en.DM00469014.pdf aber auch interessant.
pegel schrieb: > Die Kalibrierung von LSI/HSI ist schon eine umfangreiche Aufgabe: Deshalb schreibe ich den passenden Wert ins SYSTICK->RELOAD Register und trimme nicht den HSI. Der ist ab Werk schon vernünftig eingestellt.
Mit Kalibrierung meinte ich auch eher die Korrektur des Temperatur- und Spannungsabhängigen Fehlers.
Bauform B. schrieb: > Markus M. schrieb: >> Der Timer läuft mit dem Systemtakt (24MHz PLL aus dem HSI generiert), > > Mach es noch simpler: Lass die PLL weg, die kostet nur Strom. Nimm als Ich benötige 24MHz da ich einen 3MHz SPI-Takt benötige um per SPI ein gutes Signal für die WS2812 LEDs zu generieren (nein, ich werde das jetzt nicht auf Timer-Output-Compare oder Bitbanging umbauen). Zudem benutze ich den den Systick bereits um IRQs im ms Bereich auszulösen. Aber der Fehler ist ja der gleiche, ob ich nun den Systick direkt nutze oder auf einen anderen Timer (TIM16 in diesem Fall) geben. Trimmen kann ich mit dem TIM16 auch, indem ich den Reload-Wert nicht auf 999 sondern z.B. auf 998 oder 1000 setze. > Timer den SYSTICK, der hat 24 Bit, damit kommst du von 16MHz direkt auf > 1 Sekunde und kannst auf 1/16000000 trimmen. Dann bleibt nur noch der > Fehler durch Temperaturschwankungen. Die Frage ist, gegen welche Referenz trimme ich das? Ich würde ja einen externen (stabilen) 16MHz (Quarz)Takt benötigen, oder?
:
Bearbeitet durch User
Markus M. schrieb: > Aber der Fehler ist ja der gleiche, ob ich nun den Systick direkt nutze > oder auf einen anderen Timer (TIM16 in diesem Fall) geben. Trimmen kann > ich mit dem TIM16 auch, indem ich den Reload-Wert nicht auf 999 sondern > z.B. auf 998 oder 1000 setze. Der Fehler des HSI ist noch der gleiche. Der Unterschied ist, wie fein du den Fehler ausgleichen kannst. Mit dem TIM16 ist die kleinste Stufe 1/1000, ±86.4 Sekunden/Tag. Mit den 24 Bit vom SYSTICK ist ±1 eben 1/16000000 oder 0.005 Sekunden/Tag. Wenn du wenigstens die vollen 16 Bit des TIM16 nutzen würdest, wärst du auch schon 65 mal besser dran. Das geht mit 24MHz und PLL natürlich ganz genauso wie mit HSI alleine. Ich fand nur "ganz simpel" und PLL etwas widersprüchlich. > Die Frage ist, gegen welche Referenz trimme ich das? Ich würde ja einen > externen (stabilen) 16MHz (Quarz)Takt benötigen, oder? Früher hätte man das Zeitzeichen vor den Nachrichten im Radio benutzt. Will sagen, ich lasse das Teil einen Tag lang laufen und messe zu Fuß die Abweichung zu einer Funkuhr. 24 Stunden deshalb, weil damit der Temperaturunterschied zwischen Tag und Nacht raus gemittelt wird. Das geht auch benutzerfreundlich: man startet das Teil zu einer bestimmten Uhrzeit und am nächsten Tag zur gleichen Sekunde drückt man den "Kalibrier-Taster". Das Programm rechnet den Korrekturfaktor aus und schreibt ihn ins Flash.
https://de.rs-online.com/web/p/quarz-oszillatoren/9047601/ Der Kleine passt noch Huckpack auf einen SO8. ;)
Markus M. schrieb: > Verwenden die tatsächlich Quarze? Kosten ja nur 1,x Cent in den relevanten Mengen. Dafür läuft das Zeug wie es soll. pegel schrieb: > Die Kalibrierung von LSI/HSI ist schon eine umfangreiche Aufgabe: pegel schrieb: > https://de.rs-online.com/web/p/quarz-oszillatoren/9047601/ Ich tu mir für private Projekte das Herumgehampel mit internen RC-Oszillatoren gar nicht mehr an, seit es Quarzoszillatoren für nen halben € gibt. Und im Geschäft rechne ich ganz genau aus, was die Kalibriererei an Aufwand bedeutet und setze dann auch einen Quarzoszillator ein. Denn wenn das Gelecke mit dem Abgleich mehr als 20 Sekunden kostet, dann ist der Oszillator bezahlt. Und wenn es dann noch eine Reklamation wegen des davonlaufenden RC-Oszillators gibt, dann kan ich viele Oszillatoren defür einbauen. Bauform B. schrieb: > am nächsten Tag zur gleichen Sekunde drückt man den "Kalibrier-Taster". Und dann stellt man am Thermostat noch eine konstante Temperatur ein. Und von wegen Nachtabsenkung!
Lothar M. schrieb: > Und im Geschäft rechne ich ganz genau aus, was die Kalibriererei > an Aufwand bedeutet und setze dann auch einen Quarzoszillator ein. > Bauform B. schrieb: >> am nächsten Tag zur gleichen Sekunde drückt man den "Kalibrier-Taster". > Und dann stellt man am Thermostat noch eine konstante Temperatur ein. > Und von wegen Nachtabsenkung! Musst du das kleingedruckte im Pflichtenheft lesen: dieser G030 muss ja nur im Mittel über 24 Stunden genau ticken :)
Markus M. schrieb: > nein, ich werde das > jetzt nicht auf Timer-Output-Compare oder Bitbanging umbauen Solltest du aber Timer + DMA ist ja wohl die ultimative Lösung :D Mal ganz ehrlich ist es so schwer was auch immer du als Zeitbasis nutzt 1 Stunden oder besser einen Tag laufen zu lassen zu schauen wie die Abweichung ist und deinen Timer einfach entsprechend länger oder kürzer zählen zu lassen?
Kevin M. schrieb: > Markus M. schrieb: >> nein, ich werde das >> jetzt nicht auf Timer-Output-Compare oder Bitbanging umbauen > > Solltest du aber Timer + DMA ist ja wohl die ultimative Lösung :D Nein, ich mache DMA + SPI, da man nicht soviel Zwischenspeicher benötigt. Ich benötige genau das 3-fache der Datenmenge. Bei der Timervariante wäre es dass 8-fache (für jedes Bit muss man ein Byte vorbereiten für den OC). Nachteil ist natürlich das der SPI-Takt stimmen muss, so dass man ein günstiges Teilerverhältnis für die WS2812-Bits erhält. Die optimale Lösung ist DMA mit double-buffering und den Buffer für die nächsten X LEDs im ISR vorbereiten. Lohnt sich bei 47 LEDs allerdings nicht wirklich :-)
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.