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