Moin moin, ich suche nach einem Dateiformat mit dem man möglicht leicht Parameter (Zahlen, Strings, Char) zwischen einem µC und dem PC via SD-karte austauschen kann. Es geht um hunderte Parameter, also sollten die einigermaßen stukturiert vorliegen und auch weitgehend fehlerfei editierbar sein. Außerdem sollte der Zugriff auf die elemente im C-Code möglichst einfach von statten gehen (Und nicht jedes mal nach Strings suchen). Ich hatte mal einen kurzen Blick auf libxml geworfen, nachdem das aber kompliziert aussieht, frag ich erst mal bevor ich mich da rein fuchse. Letztlich so was wie XML oder Json. Vielleicht gibts aber auch viel schlauere Formate? Hat jemand Ideen? Oder so was schon mal gemacht?
Fabian F. schrieb: > Außerdem sollte der Zugriff auf die elemente im C-Code möglichst einfach > von statten gehen (Und nicht jedes mal nach Strings suchen). XML ist Text, wie soll das ohne Stringsuche gehen? Man kann zwar die ganze XML-Datei einlesen und dann auf die Baumstruktur zugreifen, aber das ist Ok für einen PC, aber für einen µController eher nicht, da wäre ein Zugriff auf einzelne Parameter eher geeignet. Georg
Fabian F. schrieb: > Außerdem sollte der Zugriff auf die elemente im C-Code möglichst einfach > von statten gehen (Und nicht jedes mal nach Strings suchen). > Ich hatte mal einen kurzen Blick auf libxml geworfen was denkst du wie "libxml" das intern macht? xpath ohne string-vergleiche? willst du tatsächlich parameter einlesen, oder suchst du eine möglichkeit vom µc ermittelte werte auf eine sd-karte zu speichern um sie im pc auszulesen? bei ersterem würde ich var=wert, zeilenweises einlesen und stringvergleich vorschlagen, außer der µc ist so richtig fett mit RAM ausgestattet und kann XML problemlos parsen. bei letzteren würde ich CSV vorschlagen. einfach die ermittelten werte (komma)seapriert zeilenweise in eine datei schreiben.
georg schrieb: > Fabian F. schrieb: >> Außerdem sollte der Zugriff auf die elemente im C-Code möglichst einfach >> von statten gehen (Und nicht jedes mal nach Strings suchen). > > XML ist Text, wie soll das ohne Stringsuche gehen? ICH will nicht nach Strings suchen müssen :-). Wenn das eine Layer unter der Haube macht ist mir das egal. Die Liste mit den Parametern als txt ist rund 2,8kb. Der Controller hat 380kB RAM, so ein XML sollte also rein passen. Und ja, die Werte sollem vom PC zum uC. Anders herrum erzeugt der uC einen log als txt. Schema ist z.B: AnzahlModes : 2 Mode1: MaxStrom : 200 MinStrom : 6 Mode2: MaxStrom : 65 MinStrom : 0 Wenn man einfach nach "MaxStrom" in der txt sucht findet man zunächst mal nur den 1. eintag. Mit XML artiger Struktur wär dann z.b. eine Entsprechende Struktur als ergebnis Nett: for(int i; i<XML.AnzhalModes;i++) { value = XML.Mode[i].MaxStrom do something... } Oder eben ein Dictionary in Json in ähnlicher form. *.dbf klingt interessant nachdem man das wohl in excel bearbeiten kann? wie entdröselt man das dfb dann aber auf dem uC? Da gibts wohl mehrere Parser wie z.B. https://sourceforge.net/projects/dbase/ Schon einen davon ausprobiert?
Fabian F. schrieb: > Mit XML artiger Struktur wär dann z.b. eine Entsprechende Struktur als > ergebnis Nett: > for(int i; i<XML.AnzhalModes;i++) > { > value = XML.Mode[i].MaxStrom > do something... > } du musst den pfad im XML zu deinen modes schon adressieren entweder:
1 | for(int i; i<XML.array("/path/to/elements").size; i++) {
|
2 | value = XML.array("/path/to/elements").getValue(i);
|
3 | do something... |
4 | } |
oder, falls du ein xsl erstellst aus dem du per framework c-klassen erstellen lassen kannst:
1 | for(int i; i<XML.path.to.elements.size; i++) {
|
2 | value = XML.path.to.elements.getValue(i); |
3 | do something... |
4 | } |
so in der art. bin kein c++ programmierer.
Fabian F. schrieb: > Letztlich so was wie XML oder Json. Vielleicht gibts aber auch viel > schlauere Formate? Wenn es von Menschen lesbar/editierbar sein soll, würde ich das .ini-Format verwenden: https://de.wikipedia.org/wiki/Initialisierungsdatei Auf uC-Seite baut man sich ein paar Funktion ala get_ini_parameter_type( section, key, default_value) und die Sache ist geritzt.
Ich würde es als Text machen, ähnlich wie Egon(Gast) es schon vorgeschlagen hat. So hat man das vor über 20 Jahren schon gemacht und das ist IMO auch heute nicht falsch. Um die "Textsuche" zu verkürzen kann man sich im Vorfeld die Struktur überlegen und definieren in welchem Bereich der Datei was stehen soll. Wenn man dann nach entsprechenden Einträgen in der Datei suchen will weiß man wo man danach suchen muss und das vereinfacht die Suche ungemein, man muss ja nicht an eine Stelle in der Datei suchen, an der der gesuchte Eintrag nicht stehen kann ;)
Fabian F. schrieb: > Schema ist z.B: > AnzahlModes : 2 > Mode1: > MaxStrom : 200 > MinStrom : 6 > Mode2: > MaxStrom : 65 > MinStrom : 0 > > Wenn man einfach nach "MaxStrom" in der txt sucht findet man zunächst > mal nur den 1. eintag. Dann suchst du erst nach "Mode2:" und dann nach "MaxStrom". Das wäre aber in jeder anderen Struktur ähnlich. M. K. schrieb: > Ich würde es als Text machen, ähnlich wie Egon(Gast) es schon > vorgeschlagen hat. So hat man das vor über 20 Jahren schon gemacht und > das ist IMO auch heute nicht falsch. Das ist der Code, den ich auch nach 25 Jahren noch benutze. Mittlerweile gibt es offenen Implementationen in (fast) jeder Programmiersprache.
Egal was du verwendest wenn du zur Laufzeit darauf zugreifen möchtest ist das parsen extrem unglücklich. Eigentlich ließt man solche files beim starten und erzeugt damit ein struct im Speicher. Zumindest von Parametern die man zur Laufzeit benötigt. Deswegen ist es fast egal wie lange es dauert bis das File eingelesen ist, da es ja nur beim starten gelesen werden muß bzw. beim speichern wird aus dem Struct das File neu erzeugt.
XML halte ich für unglücklich. Wenn es schon ein Standardformat sein soll würde ich Json nehmen. Wenn irgendwann mal ein Web-Server ins Projekt soll kommst du um Json meistens auch nicht herum. Das ist wesentlich leichter zu Handeln als XML. Hier gibt es auch eine nette Lib die ohne dynamischen Speicher auskommt: https://github.com/bblanchon/ArduinoJson Lass dich nicht vom Namesbestandteil "Arduino" vergraulen. Dass hat mit Arduino eigentlich nichts zu tun und läuft auf jedem Controller oder Rechner ohne auf irgendwelche Arduino-Bestandteile zugreifen zu müssen.
Fabian F. schrieb: > Es geht um hunderte Parameter, *.ini, XML und JSON wollen geparst werden. u.U. in voller Länge. Dank der variablen Feldbreite, ist kein "Random Access" Zugriff möglich. Beim *.dbf muss nur die Felddefinition geparst werden. Danach hat man die Daten/Zeiger für den "Random Access" Zugriff. Der Vorteil ist hier die fixe Feldbreite. Ich denke mal, das sollte der markanteste Unterschied sein.
Hallo, das unter Windows übliche INI-Format kennt Abschnitte - Linuxfanatiker bitte nicht weiterlesen - z.B. [Fenster1] xpos=100 ypos=80 [Fenster2] xpos=100 ypos=80 width=40 height=35 usw. Man kann also beim Programmstart die Abschnitte parsen und in einer Tabelle speichern, dann weiss man später von welcher Position an man den gewünschten Wert suchen muss. Die Tabelle ist viel kleiner als die ganze Datei und das Suchen geht viel schneller. Bei den meisten config-Dateien unter Linux geht das übrigens ähnlich, nur gibt es da keinen Standard, jeder macht was er will. Georg
da finde ich JSON schöner weil es eine hierarchische Darstellung erlaubt.
Unbekannte Quelle schrieb: > Irgendwann ist der Augenblick da, wo wir uns > entscheiden und handeln müssen und nicht > mehr zurückblicken dürfen.
Für das von Georg angesprochene ini-Format gibt's es sogar eine schöne Bibliothek. https://www.compuphase.com/minini.htm
STM32 schrieb im Beitrag #5253839: > Für das von Georg angesprochene ini-Format gibt's es sogar eine schöne > Bibliothek. > > https://www.compuphase.com/minini.htm Bitte korrigiere mich, wenn ich flashc liege, aber so wie ich das sehe hat Egon das Format als Erster angesprochen [1]. Georg bleibt die Ehre, vermutet zu haben, daß dies von "Linuxfanatikern" als Provokation empfunden würde -- dabei erfreut sich das .ini-Format auch unter Linux und anderen UNIXoiden Systemen großer Beliebtheit: es ist sehr einfach und dennoch strukturiert aufgebaut, läßt sich von Menschen und Maschinen gut und ressourcenschonend lesen und schreiben, und es gibt eine Reihe von Bibliotheken, darunter auch besonders kleine, die für Embedded-Anwendungen geeignet sind, neben der von Dir verlinkten zum Beispiel auch noch diese [2] und jene [3]. ;-) [1] Beitrag "Re: Emfehlung für Config File-Format" [2] https://github.com/benhoyt/inih [3] https://github.com/ndevilla/iniparser
Json ist halt eleganter als das *.ini-Format, da es Arrays und Objekte (== Strukturen) kennt. Dafür ist es halt deutlich aufwendiger zu parsen, und damit nicht für extrem knapp mit Ressourcen ausgestattete Controller geeignet. Eine recht sparsame, in C geschriebene Implementierung eines Json-Parsers ist frozen, das eine scanf/printf- artige API aufweist. https://github.com/cesanta/frozen Beim Parsen von Konfigurationsdateien kommt es weniger auf die Geschwindigkeit an (das geschieht beim Starten des jeweiligen Gerätes schließlich nur einmal, und sonst nur bei Änderungen an den Dateien), sondern eher auf den Speicherbedarf und die Codegröße. Wie sich der Einsatz von frozen auf RAM-Bedarf und Codegröße auswirkt, kann ja einer der geneigten Leser mal in einer stillen Winternacht eruieren und dann das Resultat hier veröffentlichen.
INI-Dateien gehen auch hierarchisch. Qt macht das z.B., wenn es muss:
1 | [Foo] |
2 | Wert=1 |
3 | |
4 | [Foo/Bar] |
5 | Wert=2 |
6 | |
7 | [Foo/Bar/Bla] |
8 | Hallo=Welt |
Um XML, JSON und Co zu schreiben/lesen, braucht Mensch entweder Frustrationsvermögen oder einen passenden Editor. Eine reine Textdatei in der Art einer INI, ist da schon pflegeleichter - auch nach Jahren noch.
Brummbär schrieb: > Eine reine Textdatei in der Art einer INI, ist da schon pflegeleichter - > auch nach Jahren noch. Und wenn man den Komfort auf die Spitze treiben will, kann man sogar noch Kommentare einfügen, soviel man will... Nicht alles was älter als 5 Jahre ist muss deswegen schlecht sein. Höchstens uncool. Georg
Sheeva P. schrieb: > Bitte korrigiere mich, wenn ich flashc liege, aber so wie ich das sehe > hat Egon das Format als Erster angesprochen [1]. Stimmt Steiger, die Kohlen sind schwarz.... Das ist mir durchgegangen. Sorry. Wieso ich MININI angegeben hatte, ist, daß das bei mir schon jahrelang im Einsatz ist. Es hat bei mir auf Anhieb unter Verwendung der (mitgelieferten) Glue-Files sofort funktioniert. Weswegen ich die INI-Files präreferiere, ist auch schon mehrfach angesprochen worden; es ist schlichtweg ein reines Textformat ohne Schnickschnack, das mit einem normalen Texteditor angepasst werden kann. JSON hat eine vergleichbvare Struktur, ist aber imho schwieriger zu parsen, das müsste man mal ausprobieren. XML möchte ich nicht so ohne weiteres parsen müssen, wäre aber auch sicher machbar. Insgesamt muss man sich darüber im Klaren sein, was man benötigt wird, welche Ressourcen der verwendetet Controller dafür bereitstellen kann und welchen Aufwand man betreiben möchte/muss.
Fabian F. schrieb: > Es geht um hunderte Parameter, also sollten die einigermaßen stukturiert > vorliegen und auch weitgehend fehlerfei editierbar sein. Hunderte Parameter, möglicherweise numerische Parameter die evtl. auch noch voneinander abhängen und möglicherweise berechnet werden könn(t)en? Dann evtl. eine kleine Script-Sprache integrieren: www.lua.org Deine Config-Datei ist dann ein kleines Script welches globale Variablen setzt, die Du vom C-Code dann ausliest.
Evtl. käme auch YAML in Frage (https://en.wikipedia.org/wiki/YAML); da hat man im Grunde die gleichen (und sogar noch mehr) Möglichkeiten, die man bei JSON hat, aber es ist leichter für Menschen zu lesen/bearbeiten, weil mit Einrückung (statt mit geschweiften Klammern etc.) gearbeitet wird. Hier ein (vglw. komplexes) Beispiel-YAML aus der englischen Wikipedia:
1 | --- |
2 | receipt: Oz-Ware Purchase Invoice |
3 | date: 2012-08-06 |
4 | customer: |
5 | first_name: Dorothy |
6 | family_name: Gale |
7 | |
8 | items: |
9 | - part_no: A4786 |
10 | descrip: Water Bucket (Filled) |
11 | price: 1.47 |
12 | quantity: 4 |
13 | |
14 | - part_no: E1628 |
15 | descrip: High Heeled "Ruby" Slippers |
16 | size: 8 |
17 | price: 133.7 |
18 | quantity: 1 |
19 | |
20 | bill-to: &id001 |
21 | street: | |
22 | 123 Tornado Alley |
23 | Suite 16 |
24 | city: East Centerville |
25 | state: KS |
26 | |
27 | ship-to: *id001 |
28 | |
29 | specialDelivery: > |
30 | Follow the Yellow Brick |
31 | Road to the Emerald City. |
32 | Pay no attention to the |
33 | man behind the curtain. |
:
Bearbeitet durch User
STM32 schrieb im Beitrag #5254181: > Sheeva P. schrieb: >> Bitte korrigiere mich, wenn ich flashc liege, aber so wie ich das sehe >> hat Egon das Format als Erster angesprochen [1]. > > Stimmt Steiger, die Kohlen sind schwarz.... Das ist mir durchgegangen. > Sorry. Kein Problem, ich wollte die Ehre nur dem überlassen, dem sie gebührt. ;-) > Weswegen ich die INI-Files präreferiere, ist auch schon mehrfach > angesprochen worden; es ist schlichtweg ein reines Textformat ohne > Schnickschnack, das mit einem normalen Texteditor angepasst werden kann. Mir mußt Du das Format nicht verkaufen, ich kenne es, mag es, und benutze es sehr regelmäßig. Neben den genannten Vorteilen ist es nämlich so, daß die Software meines Arbeitgebers .ini-Dateien benutzt, und meine Kollegen deswegen ohnehin im Umgang damit geübt sind. > JSON hat eine vergleichbvare Struktur, ist aber imho schwieriger zu > parsen, das müsste man mal ausprobieren. Mit entsprechenden Libraries tut sich das nicht viel. Und obwohl ich viel mit JSON mache, ist das .ini-Format für Menschen jedenfalls einfacher zu verstehen, zu lesen und zu schreiben. > XML möchte ich nicht so ohne weiteres parsen müssen, wäre aber auch > sicher machbar. XML ist ein Konglomerat von wenigen klugen Ideen und einem großen Haufen von Grusel, Ärger und Schmerz. Was ich davon halte? Abstand! > Insgesamt muss man sich darüber im Klaren sein, was man benötigt wird, > welche Ressourcen der verwendetet Controller dafür bereitstellen kann > und welchen Aufwand man betreiben möchte/muss. Natürlich. Gerade deswegen finde ich das Konzept des event-basierten Parsers mit Callbacks, wie Ben Hoyt das in [1] macht, sinnvoll. Ohne Erfahrungen mit dieser konkreten Bibliothek zu haben, kenne ich aber verschiedene andere event-basierte Parser, und in der Regel sind die besonders ressourcenschonend, schnell, und für Embedded-Geräte daher wahrscheinlich ganz gut geeignet. YMMV. [1] https://github.com/benhoyt/inih
Sheeva P. schrieb: > XML ist ein Konglomerat von wenigen klugen Ideen und einem großen Haufen > von Grusel, Ärger und Schmerz. Was ich davon halte? Abstand! Finde ich, ehrlich gesagt, nicht. XML ist nur eigentlich nicht dafür gedacht, dass man da mit einem Texteditor drin umwerkelt. Strebt man solch eine Bearbeitung an sollte man auch meiner Meinung nach nicht XML wählen.
XMLs lassen sich mit dem MS XML Notepad durchaus bequem bearbeiten. Ich hab jetzt mal ein paar versuche mit SXMLC und MinIni gemacht. XML kommt der Strucktur der Daten näher, aber INI ist eine Ecke einfacher handzuhaben. Ich mach mal ne umfrage bei den Kollegen die damit arbeiten müssen :-)
Fabian F. schrieb: > Ich mach mal ne umfrage bei den Kollegen die damit arbeiten müssen Was ist das denn für ein unstrukturiertes Vorgehen? Nur du weisst im Moment welche Art die Konfigurationsdaten sind. Gibt es Arrays, Strukturen, 0:n-Beziehungen, ... eventuell sogar assoziative Tabellen? Aus diesen Anforderungen ergibt sich ein möglichst einfaches aber eben nicht zu einfaches Format, das diese Anforderungen abdeckt.
Fabian F. schrieb: > Außerdem sollte der Zugriff auf die elemente im C-Code möglichst einfach > von statten gehen (Und nicht jedes mal nach Strings suchen). Ich kenne leider auch Leute, die Strings in einer unübersichtlichen riesen sscanf-Monsterkette parsen. Ich mag das überhaupt nicht, sondern lege eine Tabelle der Strings im Flash ab, die dann einmal geparst wird und dann die Daten in einem Array ablegt. Das erfolgt nur einmal beim Einlegen der SD-Karte, hat also keinerlei Laufzeitauswirkungen. Das ini-Format finde ich gut.
Der Andere schrieb: > Fabian F. schrieb: >> Ich mach mal ne umfrage bei den Kollegen die damit arbeiten müssen > > Was ist das denn für ein unstrukturiertes Vorgehen? > Nur du weisst im Moment welche Art die Konfigurationsdaten sind. Sagt wer? Ich weiß wie die Parameter in der Regel aussehen aber ich bin nicht der, der sie bestimmt. Bisher bekomme ich die Parameter in einer Excel und code die hart ein. Ist aber keine Dauerlösung. Ergo-> Suche nach einem Format mit dem ich die Parameter möglichst einfach parsen kann und die Kollegen die Parameter-files möglichst einfach erstellen können. Ini und XML scheint die Anforderungen zu erfüllen. JSMN würde wohl auch gehen, ist aber am anfälligsten für Fehler, wenn man die Files händisch bearbeitet. Bei Ini werden falsch geschriebene Parameter Ignoriert. Im XMl Editor kann man die Srucktur nicht aus versehen ändern. (Bestenfalls blödsinnige Werte eingeben)
Fabian F. schrieb: > Bisher bekomme ich die Parameter in einer Excel Dann nimm eine abgewandelte Form der INI => CSV Erste Spalte Kategorie, zweite Spalte Feldname, dritte Spalte Daten. Du solltest sicherheitshalber "," und ";" als Trennzeichen erlauben. Deine Kollegen können einfach weiter arbeiten, wie sie es immer schon machen. Die Daten können einfach als CSV gespeichert und übernommen werden.
Brummbär schrieb: > Dann nimm eine abgewandelte Form der INI => CSV > Erste Spalte Kategorie, zweite Spalte Feldname, dritte Spalte Daten. > Du solltest sicherheitshalber "," und ";" als Trennzeichen erlauben. Das sollte man NIE tun, schon gar nicht sicherheitshalber. Es sei denn, man will mit absoluter Sicherheit ausschließen, diese Datei mit handelsüblichen Bibliotheken verarbeiten zu können.
Ich bin ein Fan von JSON und nehme es fast überall her. Es gibt da auch nette µC-fähige Parser in C++ wie ArduinoJSON, das mit einem statisch allozierten Speicher wunderbar klar kommt und keine dynamische Speicherverwaltung benötigt. Man benötigt Arduino selbst nicht dafür - ist einfach plain C++. Da gibt es ein paar Beispiele: https://github.com/bblanchon/ArduinoJson JSON finde ich ansonsten auch sehr praktisch, da ich auch oft viel in Kombination mit Webbrowser + Javascript mache und da das Format quasi direkt in Javascript-Objekte quasi "importiert" werden können.
Bei all den JSON Empfehlungen könnte man sich auch mal BSON anschaun: http://bsonspec.org/ Der Vorteil gegenüber JSON entsteht durch explizite Längenangaben der eingebetteten Dokumente. Ich hab vor einiger Zeit mal einen simplen Tokenizer ähnlich dem oben erwähnten jsmn (https://github.com/zserge/jsmn) geschrieben und war damit mehr als 3x so schnell beim Parsen verglichen zu einem identen JSON file. Nachteil natürlich: BSON ist definitiv nicht mehr lesbar. /edit Braucht man die Performance nicht, dann würd ich selbst auch zu JSON greifen... Grad wenns rein um irgendeine Config geht die rein beim Systemstart gebraucht wird.
:
Bearbeitet durch User
Brummbär schrieb: > Fabian F. schrieb: >> Bisher bekomme ich die Parameter in einer Excel > > Dann nimm eine abgewandelte Form der INI => CSV > Erste Spalte Kategorie, zweite Spalte Feldname, dritte Spalte Daten. > Du solltest sicherheitshalber "," und ";" als Trennzeichen erlauben. > > Deine Kollegen können einfach weiter arbeiten, wie sie es immer schon > machen. Die Daten können einfach als CSV gespeichert und übernommen > werden. Die Excel/csv ist ein export aus matlab. Ob die nun csv, json, xml oder inis exportieren ist denen ziemlich egal. Für CSV hab ich jetzt noch keinen fertigen Parser in C gesehen, von da tendiere ich eher zu ini. Im Notepad++ ist so eine INI auch sehr übersichtlich.
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.