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
das JSON Format wird zur Zeit auch ganz gerne genommen, ist eine kompaktere XML Variante. http://de.wikipedia.org/wiki/JSON
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
Vermutlich ein ziemlich "ahnliches Problem: http://www.lpcware.com/content/forum/iap-and-variable-memory-mapping
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.
Hallo, hallo Zwei Links... 1. Hier die Technik (als Beispiel für die Verwendung vom offsetof-Makro) http://www.rmbconsulting.us/uses-for-cs-offsetof-macro 2. Hier ein EEPROM-Emulator im Flash: Beitrag "STM32: EEPROM Emulator im Flash" (1) hat für mich immer funktioniert... Gruß, Radu
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?
Thread beobachten
Seitenaufteilung abschaltenBitte 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.