Gesucht: Counter / Timestamp Counter IC

[Adam P. (adamap)]

Hallo zusammen,

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)

Gruß Adam

[Michael B. (laberkopp)]

Adam P. schrieb:
> derzeit suche ich nach einer Möglichkeit einen ms Tick hochzuzählen ohne
> meinen Host µC jedes mal aufzuwecken

Es gibt haufenweise RTC real time clock IC die Millisekunden zählen und 
dabei fast keinen Strom brauchen.

Die liefern halt keine 32 bit sondern Millisekunde Sekunde Minute Stunde 
Tag Monat Jahr.

Den System Tick synchron zur RTC zu bekommen ist bloss ein 
Programmierjob, also dein Job.

[Michael P. (mipo)]

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.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Adam P. schrieb:
> 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.

[Adam P. (adamap)]

Michael B. schrieb:
> Es gibt haufenweise RTC real time clock IC die Millisekunden zählen und
> dabei fast keinen Strom brauchen.

OK, hab bis jetzt noch keine gefunden, dann werde ich mal suchen.

Michael B. schrieb:
> Den System Tick synchron zur RTC zu bekommen ist bloss ein
> Programmierjob, also dein Job.

Na wenn es ms in der RTC gibt, ist das auch kein Problem.

[Adam P. (adamap)]

Lothar M. schrieb:
> 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.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Adam P. schrieb:
> 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.

[Michael B. (laberkopp)]

Adam P. schrieb:
> Na wenn es ms in der RTC gibt, ist das auch kein Problem.

Auch ohne ist es kein Problem den Systemtakt millisekundengenau auf den 
Sekundenwechsel zu synchronisieren.

Du musst halt nur programmieren lernen.

[Falk B. (falk)]

Adam P. schrieb:
> Hallo zusammen,
>
> 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.

[Michael B. (laberkopp)]

Lothar M. schrieb:
> wie der MAX31334

Abracon AB0805, AB0815: Millisekunden oder genauer

PCF2129: 1/256 Sekunde

M41T82  M41T83  M41T94: 1/100 Sekunde

MCP79410 / MCP79411 / MCP79412: 1/64 Sekunde

[Norbert (der_norbert)]

Adam P. schrieb:
> 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.

[Falk B. (falk)]

Norbert schrieb:
> Adam P. schrieb:
>> 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.

[Rüdiger B. (rbruns)]

48ms sind ca 1/20 Sekunde, also reicht der 1/256 Zähler doch aus.

[Adam P. (adamap)]

Michael B. schrieb:
> 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.

Sei es drum.

[Adam P. (adamap)]

Falk B. schrieb:
> Dein SAM4E
> ist keine Linuxkiste.

Ist mir bewusst, jedoch fehlt mir da der Bezug zum realen Stromverbrauch 
im Vergleich.

Aber dann wird es wohl darauf hinauslaufen ein paar Tests zu machen:

- Sleep Mode mit dem SAM4E
- RTC mit Millisekunden, wie die z.B.

Michael B. schrieb:
> Abracon AB0805, AB0815: Millisekunden oder genauer
> PCF2129: 1/256 Sekunde
> M41T82  M41T83  M41T94: 1/100 Sekunde
> MCP79410 / MCP79411 / MCP79412: 1/64 Sekunde

- Oder halt ein Slave µC der dann auch noch andere Aufgaben übernimmt, 
wie Peripherie Ein-,Ausschalten, Tastendrücke erkennen... (im Betrieb).

[Norbert (der_norbert)]

Falk B. schrieb:
> Man muss nur den AVR gescheit programmieren und den 32k Uhrenquarz am
> Timer2 im Power Save mode arbeiten lassen.

Der AT90S1200 hat einen Timer2?
Hmmm.
Oder beziehst du dich auf einen moderneren AVR wie ich ihn in der 
jüngeren Vergangenheit erwähnt hatte?

> Etwas Moderneres wird wohl 1-2 Größenordnungen sparsamer sein.

[Michael B. (laberkopp)]

Adam P. schrieb:
> Und ich werde bestimmt nicht jede ms die RTC pollen nur um den Wechsel
> mitzubekommen, das wäre echt bescheuert.

So so.

Wenn Lösungen zu bescheuert sind, bleibt dir die Arbeitslosigkeit.

[Falk B. (falk)]

Norbert schrieb:
>> Man muss nur den AVR gescheit programmieren und den 32k Uhrenquarz am
>> Timer2 im Power Save mode arbeiten lassen.
>
> Der AT90S1200 hat einen Timer2?
> Hmmm.

Natürlich nicht.

> Oder beziehst du dich auf einen moderneren AVR wie ich ihn in der
> jüngeren Vergangenheit erwähnt hatte?

Ja sicher.

[Adam P. (adamap)]

Michael B. schrieb:
> 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.

[Falk B. (falk)]

Adam P. schrieb:
>> Dein SAM4E
>> ist keine Linuxkiste.
>
> Ist mir bewusst, jedoch fehlt mir da der Bezug zum realen Stromverbrauch
> im Vergleich.
>
> Aber dann wird es wohl darauf hinauslaufen ein paar Tests zu machen:
>
> - Sleep Mode mit dem SAM4E
> - RTC mit Millisekunden, wie die z.B.

https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/DataSheets/Atmel-11157-32-bit-Cortex-M4-Microcontroller-SAM4E16-SAM4E8_Datasheet.pdf

Table 5-1. Low-power Mode Configuration Summary

Wait Mode w/Flash in Standby Mode
56 μA Stromverbrauch
10 μs Aufweckzeit

Kein Rekord, für deine Anwendung vermutlich ausreichend. Denn dein SAM4 
soll ja alle 48ms sowieso was machen.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Adam P. schrieb:
> 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.

[Michael P. (mipo)]

Adam P. schrieb:
> 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.

[Adam P. (adamap)]

Falk B. schrieb:
> Wait Mode w/Flash in Standby Mode
> 56 μA Stromverbrauch
> 10 μs Aufweckzeit
>
> Kein Rekord, für deine Anwendung vermutlich ausreichend. Denn dein SAM4
> soll ja alle 48ms sowieso was machen.

Das hört sich gut an.

Also eigentlich wären es zwei Aufgaben.

1. Jede 1ms wach werden und Timer inkrement, kann auch mal 2-7 Tage so 
der Zustand sein.
2. 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.

Lothar M. schrieb:
>> 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.

[Bauform B. (bauformb)]

Adam P. schrieb:
> 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...

[Michael B. (laberkopp)]

Adam P. schrieb:
> Meine Hoffnung bestand halt darin, dass es vllt. ein kleines IC gibt,
> welches nur einen 32bit Tick implementiert hat, den man auslesen kann

DS1371 hat 24 bit auslesbaren WD timer, mit Quartzfrequenz, /4 oder /8, 
ein 8kHz Quartz bringt also 1ms, ein 32kHz bringt 250ns, braucht 800nA.

Aber alles überflüssig wenn du das vorhandene souverän programmieren 
könntest.

[Adam P. (adamap)]

Bauform B. schrieb:
> 32-Bit Zähler, < 20µA: SN74LV8154PWR, notfalls sogar im DIL-20 ;)
> 1ms-Taktgeber, < 6µA: SiT1576AIPJE-XXE-0001.000000

Das werde ich mir auch mal anschauen.

[Adam P. (adamap)]

Michael B. schrieb:
> DS1371 hat 24 bit auslesbaren WD timer, mit Quartzfrequenz, /4 oder /8,
> ein 8kHz Quartz bringt also 1ms, ein 32kHz bringt 250ns, braucht 800nA.
>
> Aber alles überflüssig wenn du das vorhandene souverän programmieren
> könntest.

Ja, da wird mir nichts anderes übrig bleiben als mal ein paar Dinge 
auszuprobieren.
Aber nun habe ich zumindest eine grobe Übersicht.

Danke.

Für weitere Vorschläge bin ich weiterhin offen.

[Falk B. (falk)]

Adam P. schrieb:
> Also eigentlich wären es zwei Aufgaben.
>
> 1. Jede 1ms wach werden und Timer inkrement, kann auch mal 2-7 Tage so
> der Zustand sein.
> 2. 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

Keinerlei Bedarf für einen externen RTC.

[Bauform B. (bauformb)]

Falk B. schrieb:
> 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...

[Ob S. (Firma: 1984now) (observer)]

Bauform B. schrieb:

> 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.