mikrocontroller.net

Forum: Compiler & IDEs unix zeit -> normale Zeit.


Autor: F@n (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: OldBug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: F@n (Gast)
Datum:

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

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: OldBug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Jörg Wunsch (Gast)
Datum:

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

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: F@n (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hätte es gern. Kannst du es hier posten?

Autor: Hans (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: niemand (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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.

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.