PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Zeitabschnitt als time_t erstellen



Cysign
24.06.2015, 22:57
Hallo zusammen,
ich hänge derzeit an einem Problem mit time_t.
Ich habe 3 Ints, eins für Tag, eins für Stunden, eins für Minuten.
Diese 3 Zeitspannen möchte ich gerne zusammenaddieren, also in Sekunden umrechnen und dann als time_t abspeichern.
Aber genau hier liegt das Problem.

Ich habe jetzt etliche Stunden damit verbracht, einen sauberen timestamp zu erzeugen. Aber bei meinen testausgaben RTC.get() und Zeit der nächsten Aktion, welche 60 Sekunden danach erfolgen sollte, habe ich jeweils Werte zwischen 70000-80000 heraus, statt Differenzen von 60.

Mein letzter Versuch sah wie folgt aus:


unsigned long days2 = (unsigned long) EEPROM.read(4);
days2 *= 86400;

unsigned long hours2 = (unsigned long) EEPROM.read(5);
hours2 *=3600;

unsigned long minutes2 = (unsigned long) EEPROM.read(6);
minutes2 *= 60;

unsigned long temptime1 = days2 + hours2 + minutes2;

Ich würde mich über weitere Ideen freuen, wie ich aus int eine saubere time_t-Zeitspanne erstellen kann.

Cysign
25.06.2015, 12:56
So, meine INTs werden nun folgendermaßen umgewandelt:

unsigned long days2 = (unsigned long) EEPROM.read(4);
days2 *= 86400;

unsigned long hours2 = (unsigned long) EEPROM.read(5);
hours2 *=3600;

unsigned long minutes2 = (unsigned long) EEPROM.read(6);
minutes2 *= 60;

unsigned long temptime1 = days2 + hours2 + minutes2;

intervall0 = reinterpret_cast <time_t> (temptime1);

Valen
25.06.2015, 20:25
...habe ich jeweils Werte zwischen 70000-80000 heraus, statt Differenzen von 60.
...Welcher werten macht er den aus den Eprom speicher daten? Welcher bytes stehen dort in dem Eprom? Und was ist den Resultat deiner Berechnung? Las dein Arduino die Quell daten, Zwischenwerten und Resultaten zum PC senden. Vielleicht kannst du dan den Fehler zurück recherchieren. Mit etwas zwischen 70000 und 80000 können wir nichts anfangen. Etwas mehr Konkreter bitte!

Cysign
26.06.2015, 17:57
Danke für dein Feedback.
Meine Lösung befindet sich in meinem zweiten Post, das Problem ist somit bereits gelöst.

Ich hatte gehofft, dass die Werte auf eine bekannte Art von Overflow schließen lassen, was aber nicht der Fall ist. Hierbei handelt es sich um Zeitdifferenzen in meiner Anwendung.