Hallo Zusammen
Ich erarbeite gerade das Software-Design für eine Firmware, welche auf
einem Cortex M3 läuft.
Unter Anderem muss die Firmware auch Einstellungen abspeichern können.
Da ich relativ viele Einstellungen mit unterschiedlicher Grösse
(Int32,Arrays,structs,etc) abspeichern muss und das Mapping von
Speicheradresse zu Einstellung ziemlich aufwändig und fehleranfällig
ist, frage ich mich was es da für bewährte verfahren gibt.
Zum System: Flash Speicher ist genügen vorhanden auch ein File System
läuft bereits.
XML scheint mir für einen Cortex M3 nicht angebracht zu sein, oder?
Gibt es andere Formen einer rudimentären Datenbank für M3s?
Ich bin für gute Vorschläge offen
Grüsse
BAuer
Tag - Length - Data, so wie bei TIFF und anderen Binärformaten. Das gibt
zwar einen ziemlichen Overhead, wenn Du viele Einzelwerte ablegen
willst, aber die kannst Du ja in structs sinnvoll gruppieren.
fchk
Danke Frank
Ich werde mir das mal genauer durchdenken. Ist mit "Tag" ein Key gemeint
nach dem dann in einem Array von Tag-Length-Data structs gesucht wird?
Was ist mit SQLite3, läuft das zufriedenstellend auf einem M3?
Ich habe auch schon mal mehrere 100 Parameter verwaltet.
Dazu habe ich mir eine Struktur geschaffen um einen Parameter zu halten.
Enthalten waren z.B. Parameter-Nummer, Zeiger auf Variable, Typ, Max/Min
Werte, EEPROM-Adresse usw. sowie einen Funktionszeiger wenn bei Änderung
eine Funktion ausgeführt werden soll (z.B. Uhr stellen).
Diese Struktur als Array deklariert und liegt im Flash. Die eigentliche
Variable liegt dann irgendwo im RAM.
Hat gut funktioniert, war übersichtlich und ist einfach erweiterbar.
Das schöne war: Das Bedien-Menü kann über dieses Array die Werte
Darstellen und ändern, sowie die Parametrierung über CAN Bus war auch
kein Problem.
Um schneller auf die Werte zu zugreifen habe ich mir eine Tabelle im
RAM angelegt Parameter-Nummer <> Array-Index und ich habe die maximale
Parameter-Nummer auf 1000 begrenzt damit die Tabelle nicht zu groß wird.
Einfacher geht das fast nicht. SQLite würde ich jetzt nicht für einen
M3er verwenden.
BAuer schrieb:> Ich werde mir das mal genauer durchdenken. Ist mit "Tag" ein Key gemeint> nach dem dann in einem Array von Tag-Length-Data structs gesucht wird?
Ja, üblicherweise ein FOURCC, dh. 4 Chars wie 'FORM' oder 'DATA', die
das menschliche Suchen in einem Hexdump vereinfachen. Lies mal...
http://en.wikipedia.org/wiki/Interchange_File_Format
Das kam vor 30 Jahren mit dem Amiga auf und lebt heute in verschiedenen
Varianten wie PNG oder WAV weiter.
> Was ist mit SQLite3, läuft das zufriedenstellend auf einem M3?
Das wäre mir jetzt zu fett. TLV-Arrays bekommst Du auch auf einem
8-Bitter problemlos implementiert.
fchk
BAuer schrieb:> Da ich relativ viele Einstellungen mit unterschiedlicher Grösse> (Int32,Arrays,structs,etc) abspeichern muss und das Mapping von> Speicheradresse zu Einstellung ziemlich aufwändig und fehleranfällig> ist, frage ich mich was es da für bewährte verfahren gibt.
Ähh..wie bitte?
Könntest du mal erklären, was du da eigentlich speichern willst?
Für Einstellwerte braucht man einen externen (oder falls vorhanden
internen) EEPROM oder evtl auch sowas wie einen seriellen Flash, weil
der interne Programmspeicher meist nicht so viel Schreib/Lösch-Zyklen
aushält.
Deine Einstellungen wirst du ja wohl im laufenden Betrieb brauchen,
oder? Dafür müßten sie dann auch im internen RAM vorgehalten werden und
dort wäre ein simples struct, das man komplettiko in den EEPROM/SerFlash
rettet, die sinnvollste Lösung: braucht am wenigsten Platz, braucht
keinerlei Codierung und Decodierung - bloß eben ein wenig Gehirnschmalz
zur sinnvollen Strukturierung des struct-Inhaltes.
W.S.
Ich danke euch für eure Hilfe.
Ich denke ich werde etwas in der Richtung von Markus Vorschlag
entwerfen.
Das IFF Format hört sich aber auch interessant an, werde es bei
Gelegenheit genauer studieren. Muss ja meine Messwerte auch irgendwie
gescheit speichern aber das ist ein anderes Thema.
Das JSON Format scheint mir für C nicht geeignet, oder ich habe da etwas
falsch verstanden. Ich müsste ähnlich wie bei XML viel Text parsen.
Danke
BAuer
W.S. schrieb:> Ähh..wie bitte?> Könntest du mal erklären, was du da eigentlich speichern willst?
Hatte was aehnliches schon geschrieben, aber dann doch komplett
verworfen.
> XML, File System, Datenbank...
Alles overkill.
Ich kenn ein besseres buzzword: KISS
W.S. schrieb:> Dafür müßten sie dann auch im internen RAM vorgehalten werden
Man könnte die Werte auch einfach im Flash lassen und direkt von da
verwenden; also zB ein struct definieren und das im Flash platzieren.
Bei Bedarf da die Werte auslesen & verwenden. Zum Flash lesen brauchts
ja am M3 keine Sonderbefehle wie beim AVR. Die werte im RAM zwischen zu
speichern ist RAM-Verschwendung... Nur beim speichern muss man ein
bisschen magic machen zum Flash-schreiben.
es kommt doch darauf an wie komplex das Gerät(chen) ist: ob ich die
Parameter auch ausserhalb des Gerätes bearbeiten können möchte, ob
Firmware Updates geplant sind und wie häufig Parameter geändert und
gespeichert werden.
Bei letzerem ist das Limit die Speichertechnologie, da würde ich evtl.
FRAM nehmen wenn Betriebsstunden zyklisch gespeichert werden oder sich
Parameter ständig im Betrieb ändern können. Dann schreibt man auch so
häufig das es performant sein soll und Speichern/Laden über binäre
Strukturen das einfachste ist.
Wenn man (häufige) Firmwareupdates vor hat sollte man bedenken: binäre
Strukturen müssen immer kompatibel erweitert werden. Bei Änderungen muss
von jeder vorheriger Version auf eine Neue die Struktur kompatibel
bleiben oder in der Firmware automatisch konvertiert werden oder man
muss auf Default zurückfallen können. Und da fängt der Spass an wo JSON
& Co. Sinn machen. Beispiel ein Receiver der seine Senderliste im Flash
hält: eine kleine Erweiterung je Sender und alle gespeicherten Daten
werden falsch interpretiert und der Benutzer darf alles neu eingeben.
Oder noch gefährlicher bei einer Motor/Maschinensteuerung die plötzlich
unplausible Einstellungen vorfindet.
Da ist JSON/XML wesentlich wartungsfreundlicher und kompatibel zu
halten. Für einen kleinen Timer der nur die letzte eingestellte Zeit
merken soll oder ein Gerätchen an dem nur die IP-Adresse einstellbar ist
das natürlich Overkill. Aber wenn Firmware Updates ein Thema sind sollte
man sich das gut überlegen. Es gibt so Libs wie JSONlite o.ä., da muss
man den Parser auch nicht neu erfinden.
Dr. Sommer schrieb:> Man könnte die Werte auch einfach im Flash lassen
Dann wären es aber keine Einstellwerte mehr, sondern Konstanten. Aber
der TO will ja
"Unter Anderem muss die Firmware auch Einstellungen abspeichern können."
haben. Also doch in den RAM und nicht ins Flash. Das ginge zwar, würde
aber unter den Schreibvorgängen leiden.
W.S.
W.S. schrieb:> Das ginge zwar, würde aber unter den Schreibvorgängen leiden
EEPROM aber genauso. Und wie oft willst du die Einstellungen ändern? So
oft dass das Zwischenspeichern lohnt?
