Guten Morgen! Wenn ich einen Wert mit der Ablesezeit speichern möche, was ist ein geeignetes Format? Natürlich zunächst TT.MM.JJ hh:mm, wenn man es jetzt so speichern würde, wäre der Zeitstempel sehr groß vom Platz. Mir fällt jetzt z.B. ein, eine Startzeit zu definieren und zu sagen, der nächste Wert würde alle 5min gespeichert werden. Problem ist aber z.B. wenn der Strom ausfällt und dann das Gerät wieder anfängt, dann passt das nicht mehr, also wäre es von der Planung her besser, wenn man irgendwie die Zeit mit abspeichern könnte. Halt in dem Format TT.MM.JJ hh:mm wären das im einfachsten Fall 10Byte. Gibt es vielleicht schon fertige Ansätze, wie man eine Datums- und Zeitangabe in einem sehr viel kleinerem Format sichern kann, weil wenn ich z.B. den Tag betrachte, dann brauche ich ja nur Werte von 1-31. Also wären dafür 5bit-breite ausreichend. Ich könnte mir halt jetzt selber sowas ausdenken, aber vielleicht gibt es ja schon etwas fertig "genormtes", so dass man das Rad nicht nochmal neu erfinden braucht.
wie macht es denn Linux und windows? einfach die Sekunden ab 01.01.1900 dann rechen 4byte ausreichend lange.
Peter II schrieb: > einfach die Sekunden ab 01.01.1900 dann rechen 4byte ausreichend lange Das wird bei 32 bit signed Integer ziemlich knapp. Schau dir mal das THema "unix timestamp" ab: Tatsächlich wird die Zeit hier in Sekunden gespeichert (ab 1.1. 1970). Bibliotheken, um das umzurechnen, existieren in vielen gängigen Sprachen und es rechnet sich einfach damit, solange man keine formattierte Zeitangabe benötigt. Andernfalls kannst du ein eigenes Format erdenken: Tag im Bereich [1..31] -> 5 bit Monat im Bereich [1..12] -> 4 bit Jahr +2000 im Bereich [0..127] (entspricht 2000 bis 2127) -> 7 bit Stunde im Bereich [0..59] -> 6 bit Sekunde und Minute analog Damit kommst du dann auch mit einer gepackten 32-Bit-Variable aus (also 4 Byte). Allerdings ist es nicht sehr kompatibel und fricklig. z.B. würde das dann für die Angabe "Jahr,Monat,Tag,Stunde,Sekunde,Minute" so aussehen (jeder Buchstabe steht für ein Bit): JJJJJJJMMMMTTTTTSSSSSSMMMMMMSSSSSS... Grüße, Paule
Paule schrieb: > Das wird bei 32 bit signed Integer ziemlich knapp. war ja nur als überlegung gedacht, da er ja scheinbar keine sekunden braucht recht es auch ab 1900
Paule schrieb: > umzurechnen, existieren in vielen gängigen Sprachen und es rechnet sich > einfach damit, solange man keine formattierte Zeitangabe benötigt. Auch fuer die Umformatierung gibt es Funktionen. citb
Peter II schrieb: > wie macht es denn Linux und windows? > > > einfach die Sekunden ab 01.01.1900 dann rechen 4byte ausreichend lange. Fast richtig. Wenn von 1900 angefangen worden wäre dann wären wir jetzt schon bei über 3 Milliarden und ein Ende mit 4 Byte unsigned wäre absehbar. Tatsächlich ist der Beginn wenn ich jetzt richtig liege bei 1970. Wenn du C benutzt dann nimm den time_t Typ das sollte ein 4 Byte long sein. Und wenn du im Klartext abspeichern willst idt TT.MM.JJJJ völliger Blödsinn weil du da nicht sortieren kannst dann nimmt man JJJJ:MM:TT:HH:MM:SS. Wahlweise auch ohne Doppelpunkt oder andere Trennzeichen
Yopp, time_t ist bei den meisten Unix-basierten System leider als Signed_ und nicht als _unsigned definiert. Deswegen wird es dieses Jahrhundert auch noch sehr interessant. Ansonsten: beipflicht
Paule schrieb: > Peter II schrieb: >> einfach die Sekunden ab 01.01.1900 dann rechen 4byte ausreichend lange Ab 1900 zu zählen ist m.E. unsinnig, da die Meßwerte ja wohl mindestens aus dem Jahr 2012 stammen. Da wird "Bandbreite" verschwendet. > Damit kommst du dann auch mit einer gepackten 32-Bit-Variable aus (also > 4 Byte). Allerdings ist es nicht sehr kompatibel und fricklig. Ja, aber effektiv! Und der TE hat bei der Umsetzung der Konvertierungsroutinen etwas dazugelernt. Gruß, Günther
Paule schrieb: > Yopp, time_t ist bei den meisten Unix-basierten System leider als > Signed_ und nicht als _unsigned definiert. Deswegen wird es dieses > Jahrhundert auch noch sehr interessant. Hmm, meinst Du wirklich, dass es dieses Jahrhundert schon Probleme gibt? Ich hab einfach mal überschlagen - 4Byte = 32bit und gerechnet: (2^32-1)/(365,25*24*60*60) = 136,1 (Jahre). Wenn das ab 1970 beginnt, dann haben wir bis 2106 Zeit, bie es zu Problemen kommt, oder nicht?
PC-Anfaenger schrieb: > Natürlich zunächst TT.MM.JJ hh:mm nee, überhaupt nicht natürlich, da künstlich verkürzt. Die Zahl PI (wenn ich sie brauchen würde) würde ich halt auch nicht als .1415926 abspeichern, sondern als 3.1415926, auch wenn "jeder weiß", daß Pi mit 3 als Vorkommazahl anfängt. Zweistellige Jahreszeiten sind unnatürlich und schrecklich, weil sie jede Menge Umrechnungsaufwand, Sonderfälle etc. bedeuten. Das ist Murks mit verkürzten Jahreszahlen (Basis 1900, Basis 1970, Vorzeichenbehaftet oder auch nicht, 9 bit in ein byte reingequetscht, etc). Der Mehraufwand der Berücksichtigung der 2 zu ergänzenden Ziffern ist allemale mehr als der Mehraufwand, eine "vollständige" Jahreszahl zu speichern. WIr haben halt aktuell nicht das Jahr 12 (damals rannte Jesus noch in Badelatschen durch Jerusalem), sondern 2012.
PC-Anfaenger schrieb: > > Hmm, meinst Du wirklich, dass es dieses Jahrhundert schon Probleme gibt? > > Ich hab einfach mal überschlagen - 4Byte = 32bit und gerechnet: > > (2^32-1)/(365,25*24*60*60) = 136,1 (Jahre). Wenn das ab 1970 beginnt, > dann haben wir bis 2106 Zeit, bie es zu Problemen kommt, oder nicht? Leider hat ein signed int keine 32 Bit für die positiven Zahlen zur Verfügung, sondern nur 31 Bit (verallgemeinert steht 1 Bit für Vorzeichen zur Verfügung). Damit halbiert sich die Zeitspanne. Kompakt nachzulesen auf der Wiki: http://de.wikipedia.org/wiki/Unixzeit#Jahr-2038-Problem
PC-Anfaenger schrieb: > Paule schrieb: >> Yopp, time_t ist bei den meisten Unix-basierten System leider als >> Signed_ und nicht als _unsigned definiert. Deswegen wird es dieses >> Jahrhundert auch noch sehr interessant. > > Hmm, meinst Du wirklich, dass es dieses Jahrhundert schon Probleme gibt? > > Ich hab einfach mal überschlagen - 4Byte = 32bit und gerechnet: > > (2^32-1)/(365,25*24*60*60) = 136,1 (Jahre). Wenn das ab 1970 beginnt, > dann haben wir bis 2106 Zeit, bie es zu Problemen kommt, oder nicht? Ja, fast. Wie oben bereits erwähnt, ist das ein signed Int. Damit ist der Wertebereich nur noch halb so groß und der Eintritt des Ereignisses statt im Jahr 2106 schon im Jahr 2036. Da dies vermutlich ein großteil der Mitleser noch erleben wird - bleibt das spannend. Gruß Slartibartfass
Wenn ich mit einem uC Werte erfassen will und mit Zeitstempel speichern möchte, dann würde ich also einfach bei der Initialisierung des uCs diesem per PC die aktuelle Datums- und Uhrzeit mitteilen, in dem ich sie über einen passenden Algorithmus wie oben schon beschrieben in das Vier-Byte-Format umwandle, der uC sich die irgendwo speichert und dann der Timer einfach jede Sekunde den Wert um eins hochsetzt oder halt jede Minute den Wert um 60, wie man es auch immer gestalten will? Wäre das so der richtige gedankliche Ansatz?
PC-Anfaenger schrieb: > diesem per PC die aktuelle Datums- und Uhrzeit mitteilen, in dem ich sie > über einen passenden Algorithmus wie oben schon beschrieben in das > Vier-Byte-Format umwandle, der uC sich die irgendwo speichert und dann > der Timer einfach jede Sekunde den Wert um eins hochsetzt oder halt jede > Minute den Wert um 60, wie man es auch immer gestalten will? Wäre das so > der richtige gedankliche Ansatz? Klingt doch ok. Wenn du eh vom PC den Zeitstempel erhältst kannst du gleich das passende Format (falls es für die von der gewählte Programmiersprache des PC-Programms existiert) übertragen und dann auf dem µC Sekundenweise hochzählen. Falls dann irgendwelche Events/daten etc. in zeitbezug gesetzt und auf dem PC ausgewertet werden sollen dann hast du gleich das korrekte Datenformat. In einem Protokoll würde ich wegen der besseren Lesbarkeit allerdings Klartext vorziehen aber wie oben schon gesagt im Format JJJJ.MM.TT:...
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.