Ich messe mit einem Atmega verschiedene Größen (Temperatur, Drehzahl)
und möchte sie in einem Dataflash speichern. Für die Temperatur reicht
eine Auflösung von 1 Hz, für die Drehzahl sollten es aber mind. 5 Hz
sein. Für die zeitliche Zuordnung wird eine Echtzeit-Uhr genutzt. Mir
fällt allerdings keine wirklich sinnvolle Lösung ein, wie ich die Werte
im Speicher anordne. Bei gleicher Messfrequenz ist das leicht zulösen:
01:Wert1,Wert2,Wert3,Zeitstempel;02:Wert1,Wert2,Wert3,Zeitstempel;
etc...
Wie sieht eine sinnvolle Speicherstrategie aus?
Hö?
Warum schreibst du das nicht einfach brav nacheinander in den Flash,
wenn deine Frequenz konstant und bekannt ist, kannst du die Daten lieber
hinterher trennen, so riesig wird der Flash ja nicht sein, dass du da
sinnlos redundante Zeitinformationen reinschreiben kannst ...
Nagut, vielleicht alle Hunder Zyklen mal nen Zeitstempel reinmachen mit
Markierung um die Blöcke zu trennen ist sicher nicht verkehrt, der
Übersicht halber ...
@Student35
Mir ist nicht ganz klar, was dein Ziel ist. Willst du Speicher sparen?
Kommen die Daten gleichmäßig rein und ist die Frequenz bekannt? Im
letzteren Fall kann man sie ja einfach hintereinander speichern und aus
der Position den Zeitpunkt bestimmen.
Kommen die Daten unregelmäßig herein oder ist die Frequenz zuvor nicht
bekannt, kommt man um einen "Zeitstempel" nicht herum. Um Platz zu
sparen, kann man aber auch immer nur die Differenz zum vorherigen
Datensatz speichern. Dafür reicht dann meist ein Byte oder noch weniger.
Eventuell braucht man eine Sonderbehandlung, wenn die Zeit zu lang ist,
um noch in ein Byte zu passen. z.B so: Hat das Zeitbyte den Wert 1-255,
ist das die Differenz in Zeiteinheiten (ms oder was sich sonst so
anbietet), ist der Wert hingegen null, folgen X Bytes, die die Zeit
absolut angeben. Am Anfang kann man in demselben Schema auch die
Startzeit abspeichern, das lässt sich dann einfacher parsen.
Etwas Speicher zu sparen ist nur nebensächlich. Es wird einfach der
größte Dataflash von Atmel verwendet.
Die Aufzeichnungsfrequenz wird vorher festgelegt und ist dann quasi
konstant. Eine Zuordnung anhand einer festen Position habe ich nie für
wirklich praktikabel gehalten. Was ist, wenn plötzlich die
Aufzeichnungsfrequenz minimal schwankt? Die Zeitverschiebung verschiebt
dann den gesamten Datensatz. Ich könnte aber eine Kombination aus einem
Zeitstempel und der festen Position nehmen:
Zeit,Temp,Drehzahl,Drehzahl,Drehzahl,Drehzahl,Drehzahl; Zeit,Temp usw...
So hat man zu jedem Datensatz einen Zeitstempel und addiert jeweils die
Zeit für die AD-Wandlung. Also für die zweite Drehzahl-Messung müsste
ich Zeit + 3 * AD-Zeit rechnen.
Hier wäre es sehr wichtig die AD-Zeit genau zu kennen. Eine variable
Messfrequenz wäre dann aber auch vorstellbar. Denn es ist ja egal,
wieviel Werte nach dem Zeitstempel kommen, da sie immer eine AD-Zeit
lang dauern.
Als letzte Methode fällt mir noch eine Möglichkeit ein zwei Speicher zu
verwenden. Einmal 1 Hz und einmal 5 Hz und dann nur zu Beginn den
Zeitstempel einmal zu schreiben. Aber die vorherige Methode ist
eleganter. So habe ich das auch von Detlev verstanden?
Hallo,
Student35 schrieb:
> Die Aufzeichnungsfrequenz wird vorher festgelegt und ist dann quasi> konstant. Eine Zuordnung anhand einer festen Position habe ich nie für> wirklich praktikabel gehalten. Was ist, wenn plötzlich die> Aufzeichnungsfrequenz minimal schwankt? Die Zeitverschiebung verschiebt> dann den gesamten Datensatz. Ich könnte aber eine Kombination aus einem> Zeitstempel und der festen Position nehmen:
Benutzt Du einen Würfel oder einen ATMega? ;-)
Angenommen der ATMega läuft mit xyz MHz Quarz-Systemtakt.
Ein Timer erzeugt 0,2s Interrupts für die Messungen.
Es wird also bei jedem IRQ ein Wert geschrieben, alle 5 IRQ zusätzlich
der andere.
Mögliche Abweichungen sind also einmal die der Quarzfrequenz und
zusätzlich ein Jitter durch die Programmlaufzeit.
Der Jitter solle wohl unter 1ms liegen, sonst ist das Programmkonzept
ungünstig. Der addiert sich aber nicht, weil der nächste IRQ ja wieder
von Timer bestimmt wird.
Der Zeitstempel macht also Sinn, wenn es eine Echtzeituhr gibt, um die
absolute Zeit bei Beginn der Aufzeichnung zu kennen.
Ab da ist die Zuordnung zur Position eindeutig.
Zusätzliche Zeitstempel wären also eher Debughilfen, falls das Programm
spinnt und Daten verbummelt...
Gruß aus Berlin
Michael