Cortex M4 dynamische Listen dauerhaft speichern

[Philipp (Gast)]

Moin!

Ich bin gerade an einem Projekt auf einem TI CC3200 Launchpad dran, bei 
dem ich viele "linked Lists" verwende, z.T. sogar verschachtelt. Diese 
sollen im nichtflüchtigen Speicher abgelegt werden, damit sie nach einem 
Neustart wiederverwendbar sind.

Ich steh grad auf dem Schlauch, wie ich die Rohdaten beim Neustart 
wieder in die "Listen verpackt" kriege. Nach meiner Logik muss ich da 
ziemlich viele Steuerdaten mit Adressen etc. an vordefinierten 
Speicheradressen ablegen, um nachher in einer Startup-Routine die Listen 
wieder zu erstellen und mit Daten zu füllen... das klingt für mich sehr 
komplex und aufwändig.

Hab ich mir das richtig überlegt oder gibt es einen viel einfacheren 
Weg?

Bitte nicht böse sein, falls es eine blöde frage ist - ich hab schon 
länger nicht mehr embedded programmiert :-)

Vielen Dank!

Gruss
Philipp

[pegel (Gast)]

Gleich alle Listen im FRAM bearbeiten und halten?

[Benjamin S. (recycler)]

Die Frage ist, ob sich die Listen zur Laufzeit ändern oder immer gleich 
sind.
-> Dann könntest du sie im Code ablegen.
Nächste Frage wäre, ob sich die Listen bei "Konfiguration" ändern.
-> Dann müssteste du dir eine Konfigurationsstruktur überlegen.

Sind sie völlig dynamisch, dann wäre ein Konfigurationsloader sinnvoll, 
der die Daten aus dem Flash einliest.
Da wäre es sinnvoll mit IDs und Header zu arbeiten, analog FAT 
Dateisystem.

Vielleicht hast du ein einfaches Beispiel, dann kann man das besser 
abschätzen.

[S. R. (svenska)]

Das Stichwort lautet "Serialisieren".

Du musst deine Datenstrukturen (d.h. alle deine Listen/Bäume) irgendwie 
in einen seriellen Bytestrom umwandeln (serialisieren), den du dann 
direkt abspeichern kannst. Zum Einlesen verwandelst du diesen Bytestrom 
wieder in deine Listenstruktur (deserialisieren). Dafür gibt es fertige 
Bibliotheken, oder du baust das selbst.

Als Beispiel: Wenn du eine doppelt verkettete Liste hast, dann 
speicherst du darin mindestens zwei Zeiger plus das Datenelement. 
Abspeichern brauchst du aber nur die Anzahl der Datenelemente plus die 
Elemente selbst (die Zeiger kannst du beim Einlesen neu erzeugen, deren 
genaue Werte sind ja egal).

Speichert deine Liste aber Zeiger, dann musst du diese vorher auflösen, 
d.h. entweder das gezeigte Objekt stattdessen speichern oder eine 
Referenz darauf (z.B. ID).

[Philipp (Gast)]

Hi!

Vielen Dank für die schnellen antworten, das hilft mir weiter und ich 
habe nun auch das Gefühl, dass ich ungefähr in die richtige Richtung 
überlegt habe!

Die Listen können zur Laufzeit jederzeit verändert, erweitert oder 
verkleinert werden... zudem enthalten sie Pointer auf andere Listen, was 
das genannte serialisieren schwierig machen dürfte.

Als Codebeispiel:

// Struct to define the order and use of the DMX-Channels for a specific fixture type
typedef struct fixtureChannel {
    char purpose[MAX_NAMING_LETTERS]; // Predefined are d = Dimmer, r = red, g = green, b = blue, w = white, a = amber, u = uv, c = cyan, m = magenta, y = yellow
    struct fixtureChannel * next;
} fixtureChannel_t;

// Struct to define the DMX protocol of a fixture
typedef struct fixture {
    int id;
    char name[MAX_NAMING_LETTERS];
    fixtureChannel_t * chanList;
    int chanCount;
    char colType; // 1 = No Color, 2 = RGB, 3 = RGBW, 4 = RGBWA, 5 = RGBWUV, 6 = RGBWAUV, 7 = CMY, 8 = Wheel
    char hasDimmer; // 1 = yes, 0 = no (virtual Dimmer needed)
    struct fixture * next;
    struct fixture * previous;
} fixture_t;

Ich habe nun so grob die Idee, die "inneren" Listen separat der äusseren 
zu serialisieren und dann in der Serialisierung der "äusseren" Listen 
auf die Anzahl und Startadresse der jeweils inneren zu speichern. Klingt 
das nach einer Idee, falls ich mich verständlich ausgedrückt habe?

Bezüglich fertiger Bibliotheken: Wenn euch gerade eine einfällt, immer 
her damit! :-)

Gruss
Philipp

[Benjamin S. (recycler)]

Kleiner Tipp:
Wenn deine Listen im Speicher auch als Adressen abgebildet sind, hilft 
es, beim serialisieren diesen Nummern zu geben. die Adressen können und 
werden sich im Programm ändern.

Beispiel zum Serialisieren:

typedef struct fixture {
    int id;
    char name[MAX_NAMING_LETTERS];
    fixtureChannel_t * chanList;
    int chanCount;
    char colType; 
    char hasDimmer; // 1 = yes, 0 = no (virtual Dimmer needed)
    struct fixture * next;
    struct fixture * previous;
} fixture_t;

T_FIXTURE;1;test;1;1;1;1
T_FIXTURE;2;test2;1;1;1;1

Annahmen: *next und *previous werden berechnet
Name enthält nur ASCII Space und Zahlen und keine \0
Mit T_FIXTURE definierst du den Typ.
Als chanlist verwendest du eine ID anstatt Zeiger.

Jetzt kannst du über tokenizing die Strings zerlegen und zusammenbauen.
Dabei aufpassen, dass keiner die Strukturen zwischenzeitlich ändert.

[Benjamin S. (recycler)]

typedef struct fixtureChannel {
    char purpose[MAX_NAMING_LETTERS];
    struct fixtureChannel * next;
} fixtureChannel_t;

wird dann zu:

T_CHAN;1;test1
T_CHAN;2;test2


Ich hoffe damit wird es klarer.

[Philipp (Gast)]

Ich glaube, ich habs gerafft!

Danke!