derzeit suche ich nach einer Möglichkeit einen ms Tick hochzuzählen ohne meinen Host µC jedes mal aufzuwecken.
Ein externes IC wird wohl weniger Strom verbrauchen, als ein SAM4E16E im Sleep?
Gesehen habe ich welche mit max. 16 Bit.
32 Bit wären jedoch das Minimum.
Oder wäre ein Slave µC die bessere Wahl?
Kenn da nicht die Stromverbräuche, aber vllt. etwas in Richtung ATtiny?
Oder gibt es noch eine andere Möglichkeit?
Ein System Tick ist naturlich im µC vorhanden, jedoch startet ja dieser bei jedem Restart/Reset neu.
RTC ebenfalls vorhanden, jedoch würde bei diesem "mapping" von RTC + SysTick ein max. delta von 1000 ms beim hochfahren entstehen.
Beim Hochfahren des Systems würde ich gerne einmal kurz den "externen" Tick auslesen und dann intern weiterverwenden.
Diese Idee (Anforderung) kam heute von den PC Software Entwicklern :-/
Problem ist:
Messdaten werden mit einem Tick der momentanen Messdauer per WLAN versendet.
Nun kann es passieren, dass die Verbindug abbricht und/oder das Gerät Aus-,Eingeschaltet wird.
Soweit kein Problem was die Synchronisierung betrifft, jedoch gibt es anscheinend PC seitig gewisse Konstellationen wo die Zuordnung dann nicht mehr richtig erfolgen kann.
(Dies soll hier aber nicht mein / unser Problem sein)
Dafür ist ne ja eigentlich ne RTC da, die macht eigentlich nichts anderes. Muss "nur" mit dem PC syncronisiert werden und das ggfs nicht nur beim Hochfahren sonderen regelmäßig. Aber mit WLAN kann das schon schwierig werden (im ms Bereich). Eventuell kann man ein externes Takt-/Sync Signal verwenden (für alle Einheiten, sprich µC & PC), eventuell GPS wenn Empfang möglich.
RTC ebenfalls vorhanden, jedoch würde bei diesem "mapping" von RTC +
SysTick ein max. delta von 1000 ms beim hochfahren entstehen.
Also sind +-500ms Jitter zu viel. Was wäre denn der "maximal tolerable" Jitter?
Oder andersrum: wenn du eine RTC hättest, die alle 100ms hochzählt, wäre das mit +-50ms dann genau genug? Oder wenn die Auflösung 10ms wäre? Oder 1/128 Sekunde?
Denn dann könntest du z.B. die RTC MAX31334 nehmen, die einen Zähler drin hat, der auf 7,8ms auflöst.
Also sind +-500ms Jitter zu viel. Was wäre denn der "maximal tolerable"
Jitter?
Oder andersrum: wenn du eine RTC hättest, die alle 100ms hochzählt, wäre
das mit +-50ms dann genau genug? Oder wenn die Auflösung 10ms wäre? Oder
1/128 Sekunde?
Dies gilt noch herauszufinden.
Ich kann leider nichts über die Synchronisation am PC sagen.
Datenversand erfolgt zumindest alle 48ms in 4k Blöcken.
Damit ist im Paket (x) z.B. der Tick 1000 drin und im nächsten Paket (x+1) steht dann 1048 drin usw.
Na wenn es ms in der RTC gibt, ist das auch kein Problem.
Weil die meisten RTC mit 32,768kHz takten und es keinen Teiler durch 32,768 gibt, gibt keine genaue Millisekunde in der RTC.
Es gibt daher bestenfalls a) fraktionale Zähler, die einen Jitter um diese 0,768ms haben oder eben wie der MAX31334 b) die binären "Subsekunden" implementiert haben.
derzeit suche ich nach einer Möglichkeit einen ms Tick hochzuzählen ohne
meinen Host µC jedes mal aufzuwecken.
Ein externes IC wird wohl weniger Strom verbrauchen, als ein SAM4E16E im
Sleep?
Wer sagt das? Dieses kurze Aufwachen dauert wenige us und ist das Normalste in der Mikrocontrollerwelt. Siehe Sleep Mode. Dein SAM4E ist keine Linuxkiste.
Oder wäre ein Slave µC die bessere Wahl?
Kenn da nicht die Stromverbräuche, aber vllt. etwas in Richtung ATtiny?
Bei 3.3V und einem Uhrenquarz 2¹⁵Hz schafft selbst ein steinzeitlicher AT90S1200 weniger als ¼ mA im Idle Modus(Timer enabled).
Und der ist aus dem letzten Jahrtausend.
Etwas Moderneres wird wohl 1-2 Größenordnungen sparsamer sein.
Oder wäre ein Slave µC die bessere Wahl?
Kenn da nicht die Stromverbräuche, aber vllt. etwas in Richtung ATtiny?
Bei 3.3V und einem Uhrenquarz 2¹⁵Hz schafft selbst ein steinzeitlicher
AT90S1200 weniger als ¼ mA im Idle Modus(Timer enabled).
Und der ist aus dem letzten Jahrtausend.
Etwas Moderneres wird wohl 1-2 Größenordnungen sparsamer sein.
Man muss nur den AVR gescheit programmieren und den 32k Uhrenquarz am Timer2 im Power Save mode arbeiten lassen. Dann reicht eine Handvoll Mikroampere. Siehe Sleep Mode.
Auch ohne ist es kein Problem den Systemtakt millisekundengenau auf den
Sekundenwechsel zu synchronisieren.
Du musst halt nur programmieren lernen.
Darum geht es hier gar nicht.
Aber ja, ich muss noch C lernen, daran wirds liegen.
Denk mal ein wenig drüber nach wo du dich in der Sekunde befindest wenn du diese ausliest, dass kann bei Sekunde + 1ms sein, aber auch Sekunde + 999ms und genau dieses Problem kannst du nicht lösen, da du diese Info von der RTC nicht erhälst.
Und ich werde bestimmt nicht jede ms die RTC pollen nur um den Wechsel mitzubekommen, das wäre echt bescheuert.
Wenn Lösungen zu bescheuert sind, bleibt dir die Arbeitslosigkeit.
In meinen Augen ist das keine Lösung (zumindest nicht die beste) und Arbeitslos werde ich deshalb auch nicht.
Aber das spielt hier gar keine Rolle.
Meine Hoffnung bestand halt darin, dass es vllt. ein kleines IC gibt, welches nur einen 32bit Tick implementiert hat, den man auslesen kann, nicht mehr nicht weniger.
dass kann bei Sekunde + 1ms sein, aber auch Sekunde + 999ms und genau
dieses Problem kannst du nicht lösen
Sagte ich doch: der Jitter bei einer Sekundenauflösung ist +-500ms. Deshalb brauchst du einen Zähler, der auf Bruchteile einer Sekunde auflöst. Ob da dann 1/256 Sekunden oder 1/128 Sekunden oder sonst ein Teiler ausreicht, das musst du für dein System abklären.
Denk mal ein wenig drüber nach wo du dich in der Sekunde befindest wenn
du diese ausliest, dass kann bei Sekunde + 1ms sein, aber auch Sekunde +
999ms und genau dieses Problem kannst du nicht lösen, da du diese Info
von der RTC nicht erhälst.
Und ich werde bestimmt nicht jede ms die RTC pollen nur um den Wechsel
mitzubekommen, das wäre echt bescheuert.
Manche RTC haben auch einen Alarm-Interrupt (auf deinen Zeitstempel). Ist halt die Frage, wie hoch der Jitter dann ist. GGfs ließt du die RTC aus, setzt den Alarm auf die nächste volle Sekunde und wartest in einer Busy-Loop oder Sleep auf den Interrupt.
dass kann bei Sekunde + 1ms sein, aber auch Sekunde + 999ms und genau
dieses Problem kannst du nicht lösen
Sagte ich doch: der Jitter bei einer Sekundenauflösung ist +-500ms.
Genau.
Laut den SW Leuten, wäre sogar ein ganzes Intervall von 48ms daneben nicht schlimm. Aber wenn es möglich ist, dann mach ich es direkt so wie es sein soll.
derzeit suche ich nach einer Möglichkeit einen ms Tick hochzuzählen ohne
meinen Host µC jedes mal aufzuwecken.
Ein externes IC wird wohl weniger Strom verbrauchen, als ein SAM4E16E im
Sleep?
32-Bit Zähler, < 20µA: SN74LV8154PWR, notfalls sogar im DIL-20 ;)
1ms-Taktgeber, < 6µA: SiT1576AIPJE-XXE-0001.000000
Der SiT1576 liefert eine frei programmierbare Frequenz. Die Programmierung sollte ein Distributor machen: Digikey, Spezial-Electronic, Endrich...
Der 8154 hat ein 8-Bit Parallel-Interface, das kostet den SAM ein Dutzend Pins; irgendwas ist immer...
Jede 1ms wach werden und Timer inkrement, kann auch mal 2-7 Tage so
der Zustand sein.
Falls Gerät ON ist, dann läuft der µC eh voll durch und sendet alle
48ms.
Aber das ist ja nur für den laufenden Betrieb wichtig.
Na dann ist doch alles klar!
1.) Backup Mode, nur die RTC mit Uhrenquarz läuft, 1uA. Beim Aufwachen muss man sich halt mit dauerhafter Abfrage wieder auf die exakte Millisekunde herantasten, aka synchronisieren (Übergang der RTC zur nächsten vollen Zeiteinheit)
2.) Normaler Modus
Beim Aufwachen
muss man sich halt mit dauerhafter Abfrage wieder auf die exakte
Millisekunde herantasten, aka synchronisieren (Übergang der RTC zur
nächsten vollen Zeiteinheit)
Jede RTC, die den Namen verdient, liefert einen 1Hz-Interrupt...
Jede RTC, die den Namen verdient, liefert einen 1Hz-Interrupt...
Mindestens das. Viele lassen sich allerdings auch auf diverse binäre Vielfache davon umkonfigurieren, z.B. 64Hz, 128Hz oder sowas.
Wir nutzen das, um Testdurchläufe von Devices mit RTCs zu beschleunigen. Beim Test werden die halt entsprechend umkonfiguriert und danach wieder zurück auf 1Hz.
