Hallo und guten Tag, auch einem ARM Mikrocontroller möchte ich den Zeitstempel um den Wert Millisekunden erweitern. Nun gibt es vom Mikrocontrollerhersteller bereits Libs um den TimerTick auszulsen. Wenn ich den TimerTick auslese erhalte ich ja immer den absoluten Wert. Wie müsste ich das umsetzen damit ich als Zeitstempel HH:MM:SS:MM erhalte?
Beitrag #7333979 wurde von einem Moderator gelöscht.
Entwickler schrieb: > Wie müsste ich das umsetzen damit ich als Zeitstempel HH:MM:SS:MM > erhalte? Einfach ein bisschen rechnen. Die Grundrechenarten wirst du ja hoffentlich beherrschen.
Beitrag #7333987 wurde von einem Moderator gelöscht.
Entwickler schrieb: > Wenn ich den TimerTick auslese erhalte ich ja immer den absoluten Wert. Das dürften eher Werte bezogen auf den letzten Resetzeitpunkt sein, weit weg von "absolut" und überlaufen wird der Zähler gelegentlich auch.
Für so ein Quatsch braucht man keine Libs. Da die Libs eh keine Startzeit hat, wird sie voll nur millis ausgeben. Man braucht ein Uhrenmodul am besten mit DC-Empfang. Am Anfang merkt man sie die Uhrzeit. Dann einfach Millis abfragen und auf die Uhrzeit drauf rechnen. Schon hat man die Laufzeit in Milli-Sekunden. Bei einer Timer-Funktion einfach ALT_millis = Millis() und nach den Ende die Differenz rechnen. Entwickler Pöö :(
Beitrag #7334009 wurde von einem Moderator gelöscht.
Schlaumaier schrieb: > Dann einfach Millis abfragen und auf die Uhrzeit drauf rechnen. Schon > hat man die Laufzeit in Milli-Sekunden. ... bis zum ersten Überlauf von dem mit Millis() abgefragten Zähler.
Wolfgang schrieb: > ... bis zum ersten Überlauf von dem mit Millis() abgefragten Zähler. FALSCH. Wenn ich davon ausgehe das der Zähler überläuft kann ich das relativ unbegrenzt abfragen. Ich muss nur an einer Stelle die das Programm regelmäßig aufruft, ein Millis gegen letzte_millis abfragen. wenn millis < letzte_millis sind, wird der ueberLauf um 1 erhöht. Womit ich weiß das es mind. 1 überlauf gab. Der Rest ist nur noch ein bisschen rechnen extra.
Schlaumaier schrieb: > Der Rest ist nur noch ein bisschen rechnen extra. Das erledigt die Subtraktion sogar von ganz alleine.
1 | uint32_t start = millis(); |
2 | |
3 | tue_etwas(); |
4 | |
5 | uint32_t end = millis(); |
6 | uint32_t duration = end-start; |
Duration ist immer richtig, auch wenn der Timer zwischendurch (höchstens einmal) übergelaufen ist. Entwickler schrieb: > auf einem ARM Mikrocontroller möchte ich den Zeitstempel um den Wert > Millisekunden erweitern. Bei STM32 zählen die RTC Uhren nur Sekunden. Man kann zwar die Prescaler auslesen, aber auf genaue Millisekunden kommt man damit nicht. Nur so ungefähr. Irgendwo habe ich mal gelesen, dass Linux und Windows beide auch keine exakten Millisekunden kennen. Das sieht nur so aus, wenn man sich Logfiles anschaut.
:
Bearbeitet durch User
Steve van de Grens schrieb: > Irgendwo habe ich mal gelesen, dass Linux und Windows beide auch keine > exakten Millisekunden kennen. Macht Sinn und wird auch NIE anders sein. Immerhin dauert auch die Berechnung selbst einige MS. Ergo kann es NIEMALS 100% genau sein.
Steve van de Grens schrieb: > Irgendwo habe ich mal gelesen, dass Linux und Windows beide auch keine > exakten Millisekunden kennen. Das sieht nur so aus, wenn man sich > Logfiles anschaut. Jein. Bei Linux kommt es auf Architektur und Konfiguration an. Bei i386 (und X86_64) wurde der Jiffie-Takt mal von 100 Hz auf 1000 Hz erhöht, aktuell kannst du tickless (mit HPET-Support, nsec-Auflösung) oder mit konfigurierbarem (Kernel-Compile-Time) Jiffie-Takt (100 Hz, 250 Hz, 300 Hz, 1000 Hz) arbeiten. ARM (um diese Architektur geht es hier ja) unterstützt ebenfalls HPET und tickless Kernel. Worst-Case wäre also 100 Hz und damit eine Auflösung von 10msec. Bei meinem Debian-Kernel (x86) sind es 250 Hz und damit 4msec Auflösung. Aber wenn du deinen Kern selbst baust, dann gibt es keinen Grund, warum du dort nicht auf 1000 Hz gehen kannst und somit für die Systemzeit (egal ob REALTIME oder MONOTONIC) echte Millisekunden-Auflösung bekommst. Für Zeitmessungen, Timer etc. unterstützt ein System mit HPET aber wirklich nsec-Auflösung (64 bit) im Kernel, da hängt die Auflösung wirklich nur noch vom Systemtakt ab. Und bei GHz-Systemtakt bist du dann wirklich bei nsec-Auflösung.
Ralf D. schrieb: > Bei meinem Debian-Kernel (x86) sind es 250 Hz und damit 4msec Auflösung. Das ist die Zahl, die ich auch in Erinnerung habe. Aber wie wird denn auf einem PC die RTC Zeit um diese Millisekunden ergänzt? Vielleicht kann man von dem Konzept etwas übernehmen.
:
Bearbeitet durch User
Steve van de Grens schrieb: > Aber wie wird denn > auf einem PC die RTC Zeit um diese Millisekunden ergänzt? Die übliche RTC im PC ist so schlecht, dass sich das nicht lohnt. Was will ich mit Millisekunden, wenn die RTC nach einer Nacht um eine ganze Sekunde daneben liegt? Beim Booten übernimmt der Linux-Kernel die RTC-Zeit mit 1 Sekunde Auflösung, die Milli-, Mikro- oder Nano-Sekunden sind erstmal Null. Danach wird die RTC nicht mehr benutzt -- außer, wenn die Kernel-Uhr vom ntpd synchronisiert wird. Dann stellt der Kernel die RTC alle 11 Minuten. Dabei wird Auflösung von der RTC-Hardware begrenzt, theoretisch 1/32768 Sekunde, praktisch z.B. 1/64 oder 1/8192 Sekunde. In dem Moment geht die RTC normalerweise auf besser als 10ms genau, das schafft der ntpd auch über eine billige DSL-Verbindung. Im LAN oder per GPS kann der Fehler der Systemuhr auch auf wenige Mikrosekunden reduziert werden, aber die RTC schafft kaum einstellige Millisekunden. Bei einer selbstgebauten Hardware mit ARM könnte man auch 100ns Auflösung und mit einem guten GPS-Empfänger unter 1µs Fehler haben. Aber eine RTC, die da mithalten kann, will man nicht bezahlen.
Danke an euch für euren Support. Nach langen übergelgen brauche ich eigentlich einen Datum-Zeitstempel mit einer Erweiterung um den Wert Millisekunde. Ich kann mit der TImerLib einen 64Bit Tick auslesen. Diesen werden kann ich auch quasi konvertieren in Millisekunde (absolut). Allerdings weiß ich nicht wie ich nun den Zeitstempel um den Wert Millisekunde erweitern könnte.
1 | typedef struct TimeDate |
2 | {
|
3 | uint32_t millSec; |
4 | uint8_t sec; |
5 | uint8_t min; |
6 | uint8_t hour; |
7 | uint8_t day; |
8 | uint8_t month; |
9 | uint16_t year; |
10 | }TimeDate; |
Schlaumaier schrieb: > FALSCH. DOCH Schlaumaier schrieb: > Ich muss nur an einer Stelle die das Programm regelmäßig aufruft, ein > Millis gegen letzte_millis abfragen. Eben, aber nicht einfach so: Schlaumaier schrieb: > Dann einfach Millis abfragen und auf die Uhrzeit drauf rechnen. Schon > hat man die Laufzeit in Milli-Sekunden.
Die folgende Implementierung liefert mir auch die Millisekunden.
1 | uint64_t tick = get_tick_count64(); |
2 | uint32_t freq = get_timer_frequency(); |
3 | uint32_t time_ms = (uint32_t)(((uint64_t)((tick & 0xFFFFFFFF) * 1000)) / freq); |
@TE hast du denn die aktuelle Uhrzeit an Bord und in welcher Form?Wo kommt die Uhrzeit her?
Schlaumaier schrieb: > Steve van de Grens schrieb: >> Irgendwo habe ich mal gelesen, dass Linux und Windows beide auch keine >> exakten Millisekunden kennen. > > Macht Sinn und wird auch NIE anders sein. Ja ja, der Schlaumaier. Die Zeiten, in denen auf Intel-HW die 18Ticks/s das sagen hatten, sind eigentlich schon lange vorbei. > Immerhin dauert auch die Berechnung selbst einige MS. Ergo kann es MegaSamples, MegaSiemens, ... aber Du meintest sicherlich ms, was aber auch falsch wäre - eher µs oder gar ns ... Heutezutage (naja, schon eher 2 Jahrzehnte oder so) tickt man eher im ns-Bereich, wenn es unbedingt sein muß. HPET wurde ja schon genannt. Wenn man bei irgendeiner einigermaßen modernen SW Traces ziehen läßt, kann man etliche Trace-Records pro µs fortlaufend sehen. > NIEMALS 100% genau sein. Was ist schon 100%ig genau?
Events nach Zeitstempel zu sortieren ist eh problematisch. Ich habe gerade im Elastic Search mal wieder irritierende Logmeldungen gesehen, deren Reihenfolge durcheinander gebracht wurde, weil sie in der selben ms stattfanden. Da kommt dann manchmal die Fehlermeldung "no record found" vor der Meldung "loading customer with ID 12345". Andererseits brauchen wir die Sortierung nach Zeitstempel, weil wir da Logmeldungen von zahlreichen PODs zusammen tragen.
:
Bearbeitet durch User
Jens G. schrieb: > Ja ja, der Schlaumaier. Die Zeiten, in denen auf Intel-HW die 18Ticks/s > das sagen hatten, sind eigentlich schon lange vorbei. Ich lache morgen. Habt ihr Superhelden auch mal an das "möchte Gern Multitasking" von Windows gedacht. Allein schon bis der Prg. überhaupt berechtigt ist, die Zeit zu messen sind schon einige MS vergangen. Zeitmessung im MS o. kleiner Bereich ist auf ein PC ohne externe Hardware eh nicht möglich. Das verhindert schon sehr wirkungsvoll das System. Ich hatte bei meiner Aussage eh mehr an Microcontroller gedacht, wo man immerhin wesentlich näher an der Hardware ist, als man es bei eine Windows-System je sein wird.
Schlaumaier schrieb: > Habt ihr Superhelden auch mal an das "möchte Gern Multitasking" von > Windows gedacht. Allein schon bis der Prg. überhaupt berechtigt ist, die > Zeit zu messen sind schon einige MS vergangen. ... schon wieder MegaSamples ... Aber die Timerwerte zu ermitteln geht ratzfatz - klar, auf seine Zeitscheibe muß der Prozess schon warten, wenn er gerade nicht dran ist. Aber das müssen dann nicht gezwungenermaßen ms sein, sondern können auch niedrige µs sein - wie bei jedem normalen Multitaskingsystem (Realtime OS (nicht "normale" Linuxe) sind zwar besser, können aber auch nichts garantieren, wenn entsprechend ausgelastet) > Zeitmessung im MS o. kleiner Bereich ist auf ein PC ohne externe > Hardware eh nicht möglich. Das verhindert schon sehr wirkungsvoll das > System. bla bla ... > Ich hatte bei meiner Aussage eh mehr an Microcontroller gedacht, wo man Nöö - Du hast Dich klar auf ein Windows-/Linux-spezifisches Statement bezogen.
:
Bearbeitet durch User
Schlaumaier schrieb: > Zeitmessung im MS Zeitmessung in Mega Siemens - was für ein Quatsch. https://de.wikipedia.org/wiki/Vors%C3%A4tze_f%C3%BCr_Ma%C3%9Feinheiten https://de.wikipedia.org/wiki/Internationales_Einheitensystem#Abgeleitete_Gr%C3%B6%C3%9Fen_und_Einheiten
Steve van de Grens schrieb: > Events nach Zeitstempel zu sortieren ist eh problematisch. Kommt auf den Timestamp drauf an … ;-) > Ich habe gerade im Elastic Search mal wieder irritierende Logmeldungen > gesehen, deren Reihenfolge durcheinander gebracht wurde, weil sie in der > selben ms stattfanden. Da kommt dann manchmal die Fehlermeldung "no > record found" vor der Meldung "loading customer with ID 12345". Für solchen Kram hatte ich normalerweise einen Preprozessor, der die einzelnen Zeilen derartiger Messages zusammengesetzt hat bevor sie an ES verfüttert wurden. Gerade bei Fehlermeldungen von Datenbanken (PostgresQL in meinem Fall) war das extrem hilfreich. > Andererseits brauchen wir die Sortierung nach Zeitstempel, weil wir da > Logmeldungen von zahlreichen PODs zusammen tragen. rsyslogd mit Hires Timestamps liefert Mikrosekunden, da werden Verdrehungen schon erheblich unwahrscheinlicher. Im Zweifelsfall helfen Sequenznummern in den Messages (muss man halt selbst in seiner Software einbauen), um bei der Sortierung der Zeilen die Reihenfolge beizubehalten.
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.