Strategie zum Speichern von Funkdaten

[Christian J. (Gast)]

Hallo,

es ist nur ein Hobbyprojekt (Wetterstation) aber es macht eben Spass das 
zu erweitern.

Eine SD karte nutze ich nicht, das geben diese Bluepill Boards nicht her 
an internem Speicher. daher nutze ich ein 128kb EEPROM als 
Datenspeicher.

Folgende Lage:

Der Master (429er Cortex) nimmt Messdaten eines Sensors draußen auf und 
zwar jede Stunde. Er stellt die grafisch da und zwar 6 Tage insgesamt. 
Jeder neue Datensatz wird vorne angefügt und hinten ein alter 
rausgeschoben. So entsteht ein langsam scrollendes Profil des 
Luftdruckes, Temperatur, Feuchte. Mittels "Zambretti" lässt sich daraus 
eine Art Wettervorhersage erzeugen, vor rund 100 Jahren hat da mal 
jemand etwas gemacht, was sich per Software abbilden lässt.

Der Slave hängt bei mir in der Küche, ein Grafikdisplay mit einigen LED 
Reihen, die die Tendenzen anzeigen, ähnlich einer Mausspur.

Der Master sendet per Funk im 10s Takt rotierend seinen gesamten 
Datensatz, immer wieder von vorne. Der Slave sortiert die numerierten 
Daten in seinen Satz ein und nach 144 Datensätzen hat er alle so wie der 
Master auch. Aus den Daten berechnet er auch die Skalierung des Displays 
und diverse Eckdaten. Die Grafik skaliert sich selbst, es werden nur 
relative Veränderungen dargestellt.

Der Slave soll aber auch die Daten von einem ganzen Jahr speichern. Und 
der Slave wird auch mal ausgeschaltet, ich bastel daran rum, ändere die 
Software usw. Das macht aber nichts, der Master hat ja die letzten 6 
Tage parat im Speicher (Batterie Backup RAM) und immer wenn der Slave 
online geht kriegt er die erneut.

Jeder Datensatz hat eine Unix Time Zeitkennung und kann damit eindeutig 
identifiziert werden.

Es geht nun darum: Wie kann man es pfiffig anstellen, dass der Slave 
neue Daten im EE speichert und zwar so, dass es keine Doppelten gibt und 
keine Lücken usw. Wenn er eingeschaltet wird weiss es nicht was als 
nächstes kommt. Das was kommt kann ja schon gespeichert sein.

Im EE herum sortieren geht nicht, viel zu langsam. Das muss da direkt 
sortiert rein. Oder man fängt an mit Zeigerketten zu arbeiten, jeder 
Block zeigt auf seinen Nachfolger. Um einen einzufügen muss man die 
Kette auftrennen, wie einen Binärbaum. Blöd nur: Ist ein Block fratze 
sind alle dahinter auch weg.

Ideen?

Gruss,
Christian

[Bastler (Gast)]

Ein ATmega8 kann SD incl. Fat. Das Wird der STM ja wohl noch 
hinbekommen. Sehe ich das richtig, dass das Board Arduino-Kompatibel 
ist? Dann wäre das ja noch nicht mal Programmieraufwand...

Wenns nur um den EEprom geht dann nimm halt ein Zeiger auf das EEprom 
und inkrementier den im Kreis, wenn er am ende ankommt zurück zum 
Anfang.

[M.K. B. (mkbit)]

Ich würde im Eeprom einfach einen Ringspeicher verwenden. Also im 
Prinzip ein Array mit Datensätzen und zusätzliche Variablen, mit denen 
man sich merkt wo die letzten Daten geschrieben wurden und wie viele 
Daten im Puffer gespeichert sind (falls dieser nicht ganz voll ist).

Bei der Übertragung könnte man den Zeitstempel übertragen. Damit kann 
dann der Slave einfach prüfen, ob der Zeitstempel schon existiert oder 
die Daten an der richtigen Stelle einfügen.

Da der Slave die Daten ja in unbestimmter Reihenfolge erhalten kann und 
somit Daten an beliebiger Stelle eingefügt werden können bleiben nur 
zwei Alternativen:
1) Array und Daten verschieben
+ Kein Speicheroverhead
- viel Kopieraufwand beim Einfügen

2) Verkettete Liste
+ Kein Kopieren beim Einfügen
- 1 bzw. 2 Pointer pro gespeichertem Element (einfach oder doppelt 
verkettet)

Solltest du keinen Heap haben, dann wird die Implementierung der 
verketteten Liste etwas komplizierter.

Wenn du C++ verwendest, dann kann du einfach vector, list oder queue 
verwenden. Bezüglich Einfügen und Lesen ist der Zugriff so ziemlich der 
gleiche, allerdings unterscheiden die sich unter der Haube bezüglich 
Speicher und Rechenzeit.

[Christian J. (Gast)]

Genauso habe ich es gemacht.

Es wird ja immer die Unixtime übertragen und deren Zeitstempel merke ich 
mir in einer EE Zelle. man braucht auch keine FAT etc. ich warte bis der 
Master den ganzen Datensatz übertragen hat und dann weiss ich das bei 0 
das Kleinste und bei 144 das größte Element ist. Bei jedem Datensatz 
wird seine Array Position ja mit übertragen. Und dann gucke ich nur ob 
bei 144 ein größeres Element ist. Ist jetzt nicht optimal aber es 
funktioniert ohne viel Aufwand, da das Debuggen echt Zeit kostet, bis 
die Daten jedesmal komplett sind.

[Wolfgang H. (Firma: AknF) (wolfgang_horn)]

Hallo Christian,

> Genauso habe ich es gemacht.

Jetzt hast Du auch mich verars**t:
1. Erst fragst Du  nach einer pfiffigen Lösung,
2. Und dann bekennst Du, die schon zu haben.

Danke, nein. Du hast meine Zeit verschwendet, die ich gebraucht habe, um 
Deinen Beitrag zu lesen und selbst zu denken.

Besser wäre gewesen, Du stellst Deine Lösung vor und fragst, wer eine 
noch besseere kennt.

Noch besser wäre eine Kopie Deiner Sourcen gewesen.

Ciao
Wolfgang Horn

[Christian J. (Gast)]

Wolfgang H. schrieb:
> 2. Und dann bekennst Du, die schon zu haben.

Schon mal auf das Datum des Beitrages geschaut? Ich kann ja nicht 
warten, bis das Forum mal reagiert und eine Verpflichtung Lösungen zu 
posten gibt es auch nicht, wenn niemand danach fragt.

Es ist wie immer beim Programmieren: Zettel, Bleistift und dann Eingabe 
gegenüber Ausgabe stellen und die Bedingungen aufschreiben. Da die Daten 
willkürlich zyklisch gesendet werden ist es klüger zu warten bis alle da 
sind, andernfalls vergaloppiert man sich in eine "optimale" Lösung, die 
dann doch Mist ergibt, weil sie nicht alle Fälle abdeckt, die auftreten 
können.