Hallo! Hat jemand eine Funktion, die die UNIX-Zeit (Sekunden seit dem 1.1.1970) in die normale Zeit umrechnet und in eine Struktur wie z.B. diese: struct time { uint8_t volatile second; uint8_t volatile minute; uint8_t volatile hour; uint8_t volatile day; uint8_t volatile month; uint16_t volatile year; }; oder in einzelne Variablen ablegt?
Das kommt natürlich darauf an, welche libc Du verwendest und ob dort Funktionen wie "localtime" "strftime" etc vorhanden sind. Ausserdem wird die "time.h" benötigt, dort ist eine struct tm enthalten, die eigentlich genau das beinhaltet, was Du suchst. Ist aber alles implementationsabhängig (und damit abhängig von der libc).
Du könntest ja mal in die Sourcen der C-Standardlibrary Deines PC-C-Compilers blicken ... und die dann portieren. Bei Microsofts VC++6 ist der betreffende Quelltext beispielsweise in der Datei gmtime.c zu finden.
Mal eine Frage an Jörg: Besteht interesse, die "time-Funktionen" in die avr-libc aufzunehmen? Dann würde ich mir das Zeug mal zur Brust nehmen...
Hat wohl wenig Sinn, da jeder seine eigenen Buchhaltungsfunktionen für die Zeit macht. Die wenigsten werden wohl eine Unix-Zeit im AVR implementieren.
ich hab mir das schon mal aus der libc geholt... oder wars ms vc6...auf jeden fall hab ich struct time_info GetLocalTime und asctime in compilierfähiger art und weise.... funktionieren sollte es auch... falls einer haben will...is schon in 2 files ;) 73 de OE6JWF /hans
bitte sehr... vielleicht schaut nochmal einer drüber... hab derzeit wenig zeit zum dokumentieren usw... dann könnte mans unter umständen auch ins wiki verfrachten... weil ich kann mir gut vorstellen das man sowas der öfteren braucht... was zu machen wäre... void SystemTick() { g_ulTimeStamp++; //1 sec tick } das sollte vielleicht irgendwie umgetrixt werden... so wie mans eben braucht ;) und wie gesagt...der code kommt mit 90%tiger sicherheit aus der libc... das steht zwar nirgends is aber so... 73 de oe6jwf
also ich habe etwas nachgegraben ... der code stammt anscheinend von m$... zumindest sind die struktur-definitionen von denen übernommen... man sollte also wirklich da mal drüber gehn um gegebenenfalls das ganze zu optimieren und auf die veränderten umgebungsbedingungen anzupassen...bei mir ist der code nur in einer quick & dirty anwendung gelaufen...
"Hat wohl wenig Sinn, da jeder seine eigenen Buchhaltungsfunktionen für die Zeit macht. Die wenigsten werden wohl eine Unix-Zeit im AVR implementieren." Das sehe ich ein bisschen anders. Die UNIX-Zeit ist sehr praktisch. Besonders, wenn man Zeiten im kleinen EEPROM speichern will. Eine UNIX-Zeit verbraucht ja bloß 4 Bytes, wärend eine tm*-Struktur 7 Bytes oder mehr verbraucht. Wegen diesem Vorteil werden bestimmt viele Leite UNIX-Zeit verwnden.
Ja, und, warum sollte man sie deshalb aber gerade am 1. 1. 1970 beginnen lassen? Andere wiederum könnten es bevorzugen, stattdessen eine ,globale' Zeit in ihrer Applikation zu haben, die eine höhere Auflösung besitzt (z.B. 10 ms), entweder weil das sowieso gerade mit dem in Nutzung befindlichen Hardwaretimer zu machen ist, oder weil sie die Auflösung wirklich brauchen. Ich denke, was für den einzelnen ,,sehr praktisch'' ist, wird gerade im Controllerumfeld jeder selbst entscheiden müssen. Auch die Unix-Zeit hat sich ja für Unixe durchaus als nicht ausreichend erwiesen, gettimeofday() existiert inzwischen an die 20 Jahre mit einer Auflösung von bis zu einer Mikrosekunde (die bei aktuellen Systemen auch tatsächlich live durch eine Timerabfrage realisiert wird), Posix normt mit clock_gettime() sogar Nanosekunden-Auflösung. Dass man im laufenden Betrieb keine struct tm hochzählen wird, halte ich natürlich für selbstverständlich. ;-)
Bitte 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.