unix zeit -> normale Zeit.

[F@n (Gast)]

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?

[OldBug (Gast)]

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).

[F@n (Gast)]

Ist für einen AVR. Eine time.h ist bei WinAVR nicht dabei. Deshalb frag
ich ja.

[Rufus T. Firefly (Gast)]

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.

[OldBug (Gast)]

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...

[Jörg Wunsch (Gast)]

Hat wohl wenig Sinn, da jeder seine eigenen Buchhaltungsfunktionen für
die Zeit macht.  Die wenigsten werden wohl eine Unix-Zeit im AVR
implementieren.

[Hans (Gast)]

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

[F@n (Gast)]

Ich hätte es gern. Kannst du es hier posten?

[Hans (Gast)]

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

[Hans (Gast)]

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...

[niemand (Gast)]

"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.

[Jörg Wunsch (Gast)]

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. ;-)