Hi, um dem Quellcode (für's Arduino Board) möglichst klein und kompakt zu halten, versuche ich möglichst auf Bibliotheken zu verzichten. Von daher suche ich nun nach einer Lösung, wie ich aus den Daten (seconds, minutes, hours, day, date, month, year), welche ich per I2C vom DS1307 erhalte, einen Unix-Zeit-Wert zu ermitteln. Auf Wikipedia ( http://de.wikipedia.org/wiki/Unixzeit ) steht eine Beispielsfunktion, welche (eigentlich) meine Problematik lösen sollte. Leider erhalte ich von dieser Funktion nicht den richtigen Wert :( Per Google finde ich nur irgendwelche Onlineumrechner :/ Muss ich nun tatsächlich die Time.h Library einfügen, nur damit ich die aktuelle Zeit in der Unix-Schreibweise erhalte? So weit, Matthias
Gast
#3208218
Kannst du falsch etwas genauer definieren? Grüsse, R.
Ausschnitt aus der aktuellen Ausgabe:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
Hinten ist jeweils der Zeitstempel von der Uhrzeit zu sehen. Also der Zeitstempel, den die Funktion von Wikipedia zurückgibt. Angenommen wir nehmen nun den letzten Wert und geben ihn in einen Umrechner ein:
1 | |
:/
Matthias S. schrieb: > Auf Wikipedia ( http://de.wikipedia.org/wiki/Unixzeit ) steht eine > Beispielsfunktion, welche (eigentlich) meine Problematik lösen sollte. > Leider erhalte ich von dieser Funktion nicht den richtigen Wert :( Der Code
1 | |
2 | |
3 | |
ist ganz offensichtlich für eine Maschine geschrieben, bei der ein int 32 Bit groß ist. (60*60*24 ist für einen 16-Bit int viel zu groß) Wenn du das berücksichtigst und den Code entsprechend umbaust, dass bei dir alles in long gerechnet werden muss (= ebenfalls 32 Bit), sollte es da eigentlich keine Probleme geben. Zumal die Definition der Unix-Zeit (Sekunden ab dem. 1.1.1970) ja nun wirklich keine Raketentechik ist und man versehentliche Fehler leicht raustesten kann.
Gast
#3208231
Das scheint lediglich ein Offset Fehler zu sein. Du wirst nicht umhin kommen die Werte aus den Arrays zu prüfen resp. nachzurechnen. Grundsätzlich sollte die Funktion so gehen. Grüsse, R.
Gast
#3208236
Karl Heinz Buchegger schrieb: > Zumal die Definition der Unix-Zeit (Sekunden ab dem. 1.1.1970) ja nun > wirklich keine Raketentechik ist. 1969 war das Raketentechnik :-)
Karl Heinz Buchegger schrieb: > Wenn du das berücksichtigst und den Code entsprechend umbaust, dass bei > dir alles in long gerechnet werden muss (= ebenfalls 32 Bit), sollte es > da eigentlich keine Probleme geben. Wenn ich mir das ansehe, dann geht es im wesentlichen darum, dass man ein paar Datentypen anpassen muss, bzw. den Zahl-Literalen mit einem Suffix auf die Sprünge hilft. Nichts was einem C Programmierer groß aufstossen oder vor Probleme stellen sollte. Jeder der Code von woanders übernimmt steht immer wieder vor dem Problem: wie groß ist eigentlich ein int? Was ist die Annahme im vorliegenden Code? FAQ: Datentypen in Operationen
Matthias S. schrieb: > Hi, um dem Quellcode (für's Arduino Board) möglichst klein und kompakt > zu halten, versuche ich möglichst auf Bibliotheken zu verzichten. Was hat das eine mit dem anderen zu tun? Wenn du zugunsten eigenen Codes auf den aus der avr-libc verzichten würdest, dann wette ich, dass du in vielen Fällen größeren und schlechteren Objektcode hättest, und Quellcode sparst du beim Verzicht auf die Benutzung von Bibliotheken nun gleich gar nicht ein. avr-libc hat mittlerweile (im SVN, noch nicht in einem Release) eine recht umfängliche und vollständige time-Unterbibliothek. Deren Quellcode kannst du natürlich auch schon vorab in eigenene Applikationen benutzen, dafür ist es ja Opensource.
Wow krass ... Mit so schnellen Reaktionen habe ich nicht gerechnet :) Das das Arduino Uno für ints nur 16bit verwendet, war mir neu. Habe die Funkion angepasst. Nun läufts. Super und großen Dank :)
Und wenn es genau werden soll: http://de.wikipedia.org/wiki/Schaltsekunde
Gast
#3208481
Matthias S. schrieb: > Das das Arduino Uno für ints nur 16bit verwendet, war mir neu. Das ist eine Eigenschaft des avr-gcc, und kein Problem des "Arduino Uno" Oliver
Wo wir gerade beim Thema sind: Kennt jemand ne C-Source für die Umkehrfkt., also unixzeit zu Tag/Stunde/Minute/Sekunde ? THX Cheers Detlef
Detlef _a schrieb: > Kennt jemand ne C-Source für die Umkehrfkt., also unixzeit zu > Tag/Stunde/Minute/Sekunde ? Schau dir doch bitte mal die aktuelle avr-libc an (im SVN).
Yo, hab 1.8.0 gezogen. Finde nix, wo muß ich denn kucken? THX. Cheers Detlef
Jörg Wunsch schrieb: > Schau dir doch bitte mal die aktuelle avr-libc an (im SVN). Detlef _a schrieb: > Yo, hab 1.8.0 gezogen. Das ist die Release, nicht die SVN-Version. Hint: http://svn.savannah.nongnu.org/viewvc/trunk/avr-libc/libc/time/?root=avr-libc z.B. gmtime_r.c
Gast
#3216853
Matthias S. schrieb: > Von daher suche ich nun nach einer Lösung, wie ich aus den Daten > (seconds, minutes, hours, day, date, month, year), welche ich per I2C > vom DS1307 erhalte, einen Unix-Zeit-Wert zu ermitteln. Gegenfrage: wozu brauchst du denn diese Unix-Zeit? Gerade wenn es ne eher kleine Maschine ist, sollte man besser mit getrennten Zählern für die Tageszeit und das Datum arbeiten. Ist effektiver, weil man dort keine 32 Bit Arithmetik in HW hat. Obendrein braucht man oftmals kein Datum vor dem jahr 2000. Denk also mal eher nach darüber, zu welchen Zwecken du Datum und Uhrzeit brauchst. Ich mach es bei meinem Zeug meist so, daß ich den Systemtick als Uhrzeit (dword) benutze (FR oder ARM) und um Mitternacht das Datum inkrementiere und den Systemtick nulle. Nur für Dinge, bei denen keine feine Auflösung nötig ist, verwende ich die Anzahl Sekunden ab 1.1.2000 Karl Heinz Buchegger schrieb: > ist ganz offensichtlich für eine Maschine geschrieben, bei der ein int > 32 Bit groß ist. Ach, Karlheinz... Zitat aus der angegebenen Quelle: long unix_zeit; und das sollte reichen, um unseren TO auf die richtige Datenbreite hinzuweisen. W.S.
Je nachdem wie lange dein Device laufen soll, bedenke bitte das http://de.wikipedia.org/wiki/Jahr-2038-Problem :)
1 | |
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
1 | |
W.S. schrieb: > Ach, Karlheinz... Zitat aus der angegebenen Quelle: > long unix_zeit; > > und das sollte reichen, um unseren TO auf die richtige Datenbreite > hinzuweisen. Das hat noch lange nichts damit zu tun, ob eine Berechnung
1 | |
überläuft oder nicht. Auf einem System, auf dem ein int 16-Bit breit ist, tut sie es. Auf einem System, auf dem ein int 32-Bit breit ist, tut sie es nicht. Und viele C-Programmierer sehen solche Dinge einfach nicht, weil für sie die Vorstellung, dass auch Konstante einen Datentyp haben, etwas 'esoterisches' an sich hat, das sie gerne ignorieren.
Gast
#3221137
Karl Heinz Buchegger schrieb: > Und viele C-Programmierer sehen solche Dinge einfach nicht, Jaja, geb ich dir ja voll Recht. Der TO hätte sich vorher nen Gedanken machen sollen. Es hätte auch ausgereicht, nicht den ganzen Krempel in eine einzige Anweisung zu quetschen, sondern gemütlich Stück für Stück den long zusammenzusetzen. Der Compiler kann es ja auch nur so machen. Wollen wir jetzt gemeinsam auf die Doofheit des Nachwuchses schimpfen oder doch lieber noch schnell was zum Grillen einkaufen oder wenigstens ein Bier aus'm Keller holen und auf besseres Wetter hoffen? ;-) W.S.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.