Hallöchen, mich beschäftigt gerade die Frage, inwieweit JSON als Datei-Austausch-Format zwischen µC und PC das geeignete Format ist. Um ein klein wenig die Anwendung einschätzen zu können für Eure werte Meinung: Die Daten werden in Form von Dateien zur Verfügung gestellt und ausgetauscht. Die auszutauschenden Daten in den Dateien werden sein: - überwiegend Messdaten + Kalibrierdaten, - Konfigurationsdaten, - Status-/Service-Daten u.ä. Ich muss Dateien im µC lesen aber auch erzeugen können. Gibt es Erfahrung mit JSON Libraries für (embedded) C? Oder soll ich hierfür die Finger von JSON lassen und was anderes machen für diese Art von Daten? Klar Proprietär geht immer. Aber vielleicht gibts a) vernünftige Alternativen b) zu denen es vielleicht auch Libraries gibt. Ich freue mich auf Erfahungsaustausch und Vorschläge.
Hallo, als Übertragungsformat für JSON wird im allgemeinen XML verwendet, das bringt dir recht viel Overhead - auf einem μC (wobei du keinen genannt hast) würde ich mir das lieber sparen. Sascha
Sascha Weber schrieb: > als Übertragungsformat für JSON wird im allgemeinen XML verwendet, hä? JSON ist doch ein Format warum sollte man JSON in XML stecken? JSON hat ja den Vorteil, das man weniger Overhead als bei XML hat.
Peter II schrieb: > JSON hat ja den Vorteil, das man weniger Overhead als bei XML hat. nicht nur den...
Matz K. schrieb: > inwieweit JSON als > Datei-Austausch-Format zwischen µC und PC das geeignete Format ist. Kommt schwerstens auf den µC an. Ein EFM32GG mit 1MB Flash und 128kB RAM kann mehr Overhead vertragen als ein LPC1343 mit 32kB Flash und 8 kB RAM. Und für JSON braucht es mindestens Stringfunktionen wie sprintf(), die man bei direkt binärer Übertragung weglassen kann. Aus diesem Grund ist eine allgemeine Antwort nicht möglich.
Jetzt gebe ich auch mal billige Allgemeinplätze von mir: Es kommt darauf an... Der Nachteil von allen Zeichenbasierten Formaten in Bezug auf Messdaten ist, dass man für jede Ziffer ein byte verscheuert. Eine lausiger Char-Wert kann dann 3 Byte haben. Das frisst natürlich Bandbreite ohne Ende. WENN die Übertragungsrate aber nicht das schlagende Kriterium ist, kann es durchaus Sinn machen, in JSON zu übertragen, da sich dafür fertige Parser finden. Das spart dir Entwicklungszeit ohne Ende.
Matz K. schrieb: > Gibt es Erfahrung mit JSON Libraries für (embedded) C? Von JSON-C (Linux/Win) und jsmn habe ich schon positives gehört, aber noch nie benutzt. Vorgabe war immer XML oder schlimmer. https://github.com/json-c/json-c https://github.com/json-c/json-c/wiki http://zserge.com/jsmn.html http://alisdair.mcdiarmid.org/2012/08/14/jsmn-example.html Wenn µC ohne Betriebssystem bedeutet, fällt json-c raus.
kringel schrieb: > fällt json-c raus. Neben json-c gibt es ja noch viele andere Möglichkeiten. JSON auf einem µC kann also problemlos gehen, wenn man sich nicht zu dusselig anstellt. RAM ist auch nicht das Problem, wenn man die ankommenden Daten intelligent verarbeitet und nicht erst alles bis zur letzten geschweiften Klammer als Text zwischenspeichert. Ich hatte einmal davon Abstand genommen, weil beim UART irgendwo zwischen 0.5 und 8 MBaud Schluss ist und ich so viele Daten übertragen wollte, dass ich das nur binär geschafft habe. Eine allgemeine Antwort ist also schwer.
https://developers.google.com/protocol-buffers/ fand ich ganz interessant, bin aber noch nicht zum Testen gekommen. Es gibt (nicht von Google) auch C-Libraries dafür, teilweise auch mit (32bit-)Embedded als Zielgruppe.
Torsten C. schrieb: > kringel schrieb: >> fällt json-c raus. > > Neben json-c gibt es ja noch viele andere Möglichkeiten. JSON auf einem > µC kann also problemlos gehen, wenn man sich nicht zu dusselig anstellt. Siehe die zweite Option dich ich geschrieben habe...
JSON enthält gleichzeitig die Daten und die Beschreibung der Datenstruktur. Du kannst die Strukturen einfach erweitern. Ein alter Empfänger benutzt dann nur den Teil, den er brauchten kann. So richtig einfach wird das dann in Sprachen wie Javascript. Die Objekte deines Programms passen sich an die übertragenen Datenstrukturen an. Wenn du die Datenstrukturen nur einmal festlegst und beide Seiten selbst programmierst, bringt JSON eigentlich keine Vorteile.
Egal ob du JSON oder XML erzeugst, der Aufwand ist fast der gleiche. XML ist meistens deutlich größer als XML, was dir möglicherweise völlig egal ist. Das Einlesen von XML ist hingegen spürbar aufwändiger, als JSON. Deswegen bevorzuge ich JSON, wenn man mich lässt. Für beides gibt es unzählige Libraries für so ziemlich alle Programmiersprachen und Plattformen. Nur bei Mikrocontrollern würde ich das individuell passend zur Anwendung schneidern, damit ich mit dem Speicher und der begrenzten CPU Leistung auskomme. Das Erzeugen kann ja im einfachsten Fall eine simple Folge von printf Statements sein. Das schaffe ich so gerade noch ohne XML/JSON Framework :-)
> damit ich mit dem Speicher und der begrenzten CPU Leistung auskomme
Warum nimmst du überhaupt so ein aufwendiges Format. Ein Parser für
G-code braucht nur 1/100 der Programmzeilen eines Parsers für Json.
Was sind das für Aufgaben, die sich mit einem Mikrocontroller lösen
lassen, aber so komplexe Daten übertragen, dass so Zeilen mit Kennung
und Parametern nicht ausreichen?
Noch einer schrieb: > JSON enthält gleichzeitig die Daten und die Beschreibung der > Datenstruktur. Nein. Denk mal länger drüber nach... > Du kannst die Strukturen einfach erweitern. Ein alter Empfänger benutzt > dann nur den Teil, den er brauchten kann. Oder um es allgemeinverständlich auszudrücken: Der Empfänger benutzt nur einen (für den Sender undefinierten) Teil der Daten, versteht aber nicht wirklich was die (kompletten) Daten eigentlich bedeuten. Super Idee, IMHO. =8^(
> Warum nimmst du überhaupt so ein aufwendiges Format.
Wenn man universellen Eierlegenden Wollmilchsau Code verwendet, ist das
aufwänding. Aber man kann es auch einfach nutzen.
Zum Beispiel könnte ich die Daten von 5 Temperatursensoren einmal pro
Minute so übermitteln:1 | [ 20.0, 20.1, 22.3, 21.3, 19.9 ] |
Das ist fast genau so einfach zu parsen, wie CSV. Bei JSON muss man nicht immer an komplexe Objektstrukturen denken. Es gibt auch einfache flache Objekte ohne Hierarchie oder wie oben gezeigt simple Arrays.
> Nein. Denk mal länger drüber nach...
Sprechen wir über das selbe?
Ein USB-Paket z.B. hat nur gepackte Bits. Willst du es parsen, musst du
erst mal wissen, wie du die Bits in Zahlen und Texte zerlegst.
Json kannst du auf jeden Fall parsen. Wenn du Pech hast, bekommst du ein
Array of Number. Oder aber name:value Paare, aus denen du erraten
kannst, was die Daten bedeuten.
Meine 2cent: Zunächst gibt es neun XML und JSON noch diverse andere "Übertragungssprachen", die standardiert sind. Der Vorteil der Textbasierten ist die bessere Lesbarkeit bei der Fehlersuche. Als Problem sehe ich nur das Lesen auf der uP-Seite. Das Schreiben einfacher Daten sollte über String-Verkettungen problemlos sein. Wenn man beide Seiten fest unter Kontrolle hat, sind offene Strukturen leichter handzuhaben. Vielleit kannst Du auch zwei Übertrungsprotokolle kombinieren: ein JSON-basiertes für kleiner (Meta-) Daten, und ein Binärprotokoll zur Übertragung einer größeren Binär-Datei.
Ein Format wie JSON oder XML hat Vorteile über den Lebenszyklus einer Installation: Du kannst Server und µCs leichter unabhängig voneinander weiterentwickeln und wenn man sich nicht ganz dumm anstellt kann die ältere Version weiterhin die Daten der neueren verstehen und umgekehrt. Das ist vor allem dann interessant wenn man es mit einer größeren Anzahl von Geräten zu tun hat und als Entwickler nicht direkten Einfluss auf den Zeitpunkt des Einspielens eines Updates.
Matz K. schrieb: > mich beschäftigt gerade die Frage, inwieweit JSON als > Datei-Austausch-Format zwischen µC und PC das geeignete Format ist. > > Um ein klein wenig die Anwendung einschätzen zu können für Eure werte > Meinung: > Die Daten werden in Form von Dateien zur Verfügung gestellt und > ausgetauscht. Ach? Also, du drischst gerade auf den völlig verkehrten Esel ein. Du setzt jetzt zwei Systeme voraus, z.B. einen PC und einen µC. Kläre erstmal, auf welche Weise selbige miteinander in Verbindung stehen, sonst ist es mit deinem Gedanken "Die Daten werden in Form von Dateien zur Verfügung gestellt" nämlich Essig. Daten in Form von Dateien kann man nur zur Verfügung stellen, wenn es irgendwo einen Speicher für Dateien gibt, auf den beide Systeme einen Zugriff haben. Das heißt Netzwerk und Server darin. Dann ist es eigentlich auch wurscht, ob du nun einen PC und einen µC hast oder 99 PC's, die auf besagte Daten zugreifen. In jedem Falle sind das Systeme, die deutlich dicker sind als mal bloß ein kleiner µC, der vor Ort irgend einen Sensor bedient und abfragt. In solchem Falle ist ea dann auch wurscht, wie aufgebläht das Dateiformat zum gegenseitigen ZurKenntnisGeben ist. Ich würde in solchen Fällen eher eine Art Datenbank-Anbindung mir vorstellen. Aber vielleicht meinst du eher eine Direktverbindung zwischen einem PC und einem µC. Also sowas wie ne serielle Strippe. Dort hat es aber keine Dateien, sondern man sollte sich sowas eher als Datenströme vorstellen - und da sind andere Dinge wesentlich eher zu bedenken: Synchonisation und Fehlerkontrolle. Also präzisiere deine Vorstellungen erstmal. W.S.
Hallo W.S.... aufwachen! Da bist du ein bisschen was verpennt. Das Thema hatten wir in den 80ern des letzten Jahrtausends unter dem Titel ISO-OSI Modell ausdiskutiert. Auch wenn von diesen aufgeblähten, bürokratischen Protokollen nichts mehr übrig ist - ein Punkt ist ausdiskutiert: Darstellungsschicht wird unabhängig von der Transportschicht konzipiert. (Schau dir mal IBMs SNA an, dann weißt du warum.)
Noch einer schrieb: > ein Punkt ist ausdiskutiert: Darstellungsschicht wird > unabhängig von der Transportschicht konzipiert. Darstellungsschicht? Transportschicht? Hier will jemand nen billige Daten-Austausch zwischen einem PC und einem µC sich durch den Kopf gehen lassen, aber kein Netzwerk organisieren. Hast du schon mal eine Datei über einen Stream gelesen? Nee, hast du nicht, denn du kannst von dort bestenfalls Protokolle und Pakete und so weiter erwarten. Kurzum: Keiner weiß, was er eigentlich will - auch der TO nicht. Außer, ob es vielleicht schon fertige Bibliotheken zum Parsen von JSON oder Jsonstwas gibt und du redest von Schichtenmodellen - eben Babylon.. W.S.
> Hast du schon mal eine Datei über einen Stream gelesen?
Wie denn sonst?
Bei Systemen mit Betriebssystem hat sich das UNIX Konzept durchgesetzt.
Alles ist ein FileDescriptor. Ganz egal ob Fernschreiber, Netzwerk oder
oder Festplatte.
1 | echo -en "GET / HTTP/1.0\r\n\r\n" | nc google.de 80 | grep Content-Type | tee test.txt |
Alles Streams.
Auch bei Mikrocontrollern baust du den Low-Level Kram mit Streams. Bei
SD-Karten verarbeitet man ein Byte nach dem anderen, holt niemals den
ganzen Block in den Hauptspeicher.
> Keiner weiß, was er eigentlich will
Wie kommst du zu diesem Endruck?
W.S. schrieb: > Kurzum: Keiner weiß, was er eigentlich will - auch der TO nicht. Außer, > ob es vielleicht schon fertige Bibliotheken zum Parsen von JSON oder > Jsonstwas gibt Und Matz K. hat sich seit dem Ursprungspost nicht mehr gemeldet. Also wenn es zwichen PC und µC sein soll und nicht speziell nach einem bestimmten µC (Arduino, STM32, …) oder einer bestimmten PC-Umbebung (Linux, MS.net, …) geht, dann bleiben nur JSON oder XML übrig: Dafür gibt es Parser in allen erdenklichen Programmierumgebungen. W.S. schrieb: > Daten in Form von Dateien kann man nur zur Verfügung stellen, wenn es > irgendwo einen Speicher für Dateien gibt, auf den beide Systeme einen > Zugriff haben. Das heißt Netzwerk und Server darin. Du hast eine SD-Karte vergessen.
Noch einer schrieb: > Warum nimmst du überhaupt so ein aufwendiges Format. Ein Parser für > G-code braucht nur 1/100 der Programmzeilen eines Parsers für Json. Interessant, ein G-Code Parser hat also nur ca. 1.5 Zeilen*? Muss ja ein sehr einfaches Datenformat sein! * mein JSON-Tokenizer samt Zugriffsfunktionen hat ca. 150 C-Zeilen.
Noch einer schrieb: >> Nein. Denk mal länger drüber nach... > > Sprechen wir über das selbe? Möglicherweise schon. > Ein USB-Paket z.B. hat nur gepackte Bits. Willst du es parsen, musst du > erst mal wissen, wie du die Bits in Zahlen und Texte zerlegst. Ja, klar. Aber wenn man drüber nachdenkt ist das bei jeder Schnittstelle so, ohne extra Dokumentation wird man nicht weit kommen. Schon garnicht wenn die Funktion irgendwie garantiert, sichergestellt, definiert, was-weiss-ich sein soll. > Json kannst du auf jeden Fall parsen. Wenn du Pech hast, bekommst du ein > Array of Number. Oder aber name:value Paare, aus denen du erraten > kannst, was die Daten bedeuten. "Erraten was die Daten bedeuten", hmm, ganz fieses Grinsen meinerseits. Wie geht doch der Spruch: Das kannste schon so machen, aber dann isses halt Kacke... Nebenbei, es ist ein Irrglaube dass Json nicht bloss Bits wären, von denen man ganz genau wissen muss wie sie in Zeichen zu übersetzen sind. Am Ende existieren US-ASCII, ISO-8859-1, UTF-8 usw. usf. in der ganz realen Welt.
Jasch schrieb: > Nebenbei, es ist ein Irrglaube dass Json nicht bloss Bits wären, von > denen man ganz genau wissen muss wie sie in Zeichen zu übersetzen sind. > Am Ende existieren US-ASCII, ISO-8859-1, UTF-8 usw. usf. in der ganz > realen Welt. Zum Glück ist das standardisiert. JSON ist bevorzugt UTF-8 (und ca ~100 % von dem was umherfliegt ist UTF-8 oder ASCII auf Oktetts, was man bekanntermaßen nicht unterscheiden kann), kann aber auch UTF-16 oder UTF-32 sein. Im mittleren Fall kann man die korrekte Byte-Order nur durch Annahme/Übertragung im Out-of-band/Ausprobieren rausfinden. Andere Encodings sind ungültig. Durch die Struktur von JSON bedingt ist, dass man das korrekte Encoding (eines der vier genannten) immer bestimmen kann. Für die Anwendung auf einer MCU allerdings reichlich irrelevant...
JSON hat meiner Meinung nach viele Vorteile die auch auf einem µC zum Tragen kommen. Beim Darstellen von Log-Daten zum Beispiel ist es kein Problem selbst längere JSON Arrays auf einem kleinen Controller auszugeben ohne eine riesige Lib oder dyn. Speicher zu benutzen. Der statische js bzw. html-Code kann auf SD, Flash oder auch auf einem anderen Server liegen. Der Controller braucht dann keine Daten in html-Seiten mehr verwursten wie das früher so üblich war. Da bei Requests in der Regel nur ein paar wenige Input-Daten zu Parsen sind, sollte das auch kein Problem sein. Spätestens wenn eine html-Seite oder Teile davon im Browser zyklisch Refresht werden soll, geht heute kein Weg mehr an Ajax vorbei. Und da ist JSON nun mal das Mittel der Wahl. Wenn man sich einmal an diese Form gewöhnt hat, merkt man schnell, dass das ganze ziemlich universell ist. Zumal alle relevaten Sprachen die auf dem PC im Einsatz sind problemlos mit JSON umgehen können.
Ich meinte viel mehr, dass die Encoding-Problematik auf MCUs irrelevant ist, weil man eh nicht genug Speicher hat um Unicode korrekt zu implementieren.
JSON ist immer dann der ideale Ersatz für XML wenn der ganze Datenaustausch unter eigener Hoheit steht. In so fern ist das Encoding schönegal. Sobald das nicht mehr gegeben ist ist JSON auch nicht mehr geeignet, weil un-typisiert und ohne Schema. Jannson funktioniert ganz gut auf Cortex-Ms. Gibt auch ein CMSIS-PACK: http://az717401.vo.msecnd.net/pack/Keil.Jansson.1.0.0.pack
Matthias schrieb: > Jannson funktioniert ganz gut auf Cortex-Ms. Gibt auch ein CMSIS-PACK: > http://az717401.vo.msecnd.net/pack/Keil.Jansson.1.0.0.pack Oha, das will ja nun wirklich keiner. Ok, Cortex M ist ein weiter Begriff. Bei den großen mit externen RAM mag das ja ganz gut sein. Unter Linux, Windows und Mac benutze ich die lib auch. Aber nur um ein Array z.B. mit 100 int-Werten zu transferieren, werden wenigstens 200 mal Speicher allociert und das gesamte Gebilde muss in den RAM. Das ist auf einem M0-M3 ein no go.
Marian B. schrieb: > Jasch schrieb: >> Nebenbei, es ist ein Irrglaube dass Json nicht bloss Bits wären, von >> denen man ganz genau wissen muss wie sie in Zeichen zu übersetzen sind. >> Am Ende existieren US-ASCII, ISO-8859-1, UTF-8 usw. usf. in der ganz >> realen Welt. > > Zum Glück ist das standardisiert. JSON ist bevorzugt UTF-8 (und ca ~100 Durch mindestens zwei konkurrierende Standards soweit man Wikipedia glauben kann. Hmm, naja, tolle Wurst. Der Abschnitt "Data portability issues" in dem Artikel ist auch, ähhh, interessant, oder so. > % von dem was umherfliegt ist UTF-8 oder ASCII auf Oktetts, was man > bekanntermaßen nicht unterscheiden kann), kann aber auch UTF-16 oder > UTF-32 sein. Im mittleren Fall kann man die korrekte Byte-Order nur > durch Annahme/Übertragung im Out-of-band/Ausprobieren rausfinden. Andere Immer wenn ich "Annahme" oder "Ausprobieren" im Zusammenhang mit Schnittstellen/Protokollen höre kriege ich ganz fieses Sodbrennen. Hat diesen widerlichen Gefrickel-Geschmack... > Encodings sind ungültig. Durch die Struktur von JSON bedingt ist, dass > man das korrekte Encoding (eines der vier genannten) immer bestimmen > kann. Mag sein, keine Ahnung, habe ich nicht gecheckt weil ich Json alleine nicht als besonders sinnvoll für Schnittstellen ansehe (ausser beide Seiten sind unter Kontrolle derselben Truppe, aber warum dann Json nehmen?). In jedem Fall würde ich mal vermuten dass ungefähr 0% aller Implementierungen das tatsächlich (korrekt) tun. > Für die Anwendung auf einer MCU allerdings reichlich irrelevant... Hmm, Dinger mit komplettem Linux und allem was dazugehört drauf sind ja nun weit verbreitet, je nach Definition von MCU. D.h. da kann dann auch all der verseuchte Sondermüll drauf laufen wie im Internet sonst auch.
Jasch schrieb: > (ausser beide > Seiten sind unter Kontrolle derselben Truppe, aber warum dann Json > nehmen?). Wenn nur eine Seite ziemlich gut mit Json umgehen kann, rechtfertigt das schon den Einsatz. Insbesondere wenn es ein Browser ist. Was wären denn die Alternativen für Daten die über die "komplexität" von csv hinausgehen? XML? Ok, das hat vielleicht seine Berechtigung für APIs wie Google oder so. Niemand hängt aber einen kleinen µC so ins Netz, dass sich daran Millionen von Entwicklern zu schaffen machen. Der Overhead den xml mit sich bringt ist einfach abartig. Json hat hier für eine Klartextformat ein gutes Verhältnis zwischen Nutzdaten und Strukturdaten. Diese Aussagen mache ich aber für kleine µC die ohne Linux oder Betriebssystem nur mit ein wenigen kB RAM auskommen müssen.
Hallo, schau dir doch mal das netpp-protokoll an, das passt noch auf einen msp430 und hat ähnlich wenig Overhead wie Googles protocol buffers. Ich würde JSON eher bei den schwergewichtigen Protokollen einordnen, gegenüber XMLRPC zwar deutlich leichter, dafür fehlen auf der JS-Seite die entsprechenden Stylesheets in alle möglichen Formate. netpp nutzt auch XML, aber nur für die Beschreibung, nicht für den Transport.
Fitzebutze schrieb: > schau dir doch mal das netpp-protokoll an Meinst du das hier? http://www.section5.ch/netppres Dann sagen die beiden letzten Zeilen: netpp beta source, outdated, unsupported: Download The free netpp development tree is no longer maintained. The focus will lie in commercial support only in future. Sorry. warum man das und vieles was so ähnlich ist nicht haben will. 8-bit wird da auch nicht mehr unterstützt, auch wenn mich das nicht wirklich interessiert.
Matthias schrieb: > Sobald das nicht mehr gegeben ist ist JSON auch nicht mehr geeignet, > weil un-typisiert und ohne Schema. Meiner Erfahrung nach bleibt von diesen theoretischen Vorteilen von XML in der Praxis oft nichts übrig. Ein XML-Schema kann keine Dokumentation ersetzen, und wenn man eine saubere Dokumentation hat, dann braucht man auch kein XML-Schema mehr. Viele Anwendungen verwenden XML sowieso ohne ein definiertes Schema, und manche basteln aus String-Funktionen etwas zusammen das wie XML aussieht, aber nicht standardkonform ist. XML hat eine Berechtigung für die Darstellung von komplexen Dokumenten wie z.B. Webseiten. Für den 0815-Standardfall einer statischen Struktur aus Listen und Key-Value Zuordnungen ist es viel zu mächtig. temp schrieb: > XML? Ok, das hat vielleicht seine Berechtigung für APIs wie Google oder so. Neuen APIs im Web-Bereich basieren fast alle auf JSON (OAuth, diverse Google-APIs).
Andreas Schwarz schrieb: > Neuen APIs im Web-Bereich basieren fast alle auf JSON (OAuth, diverse > Google-APIs). Na wenn die das auch schon erkannt haben kann ich ja nicht so falsch liegen.
Torsten C. schrieb: > Du hast eine SD-Karte vergessen. Und die tauscht sich dann zwischen dem µC und dem PC aus? Ja? Wenn du sowas von Hand machen willst, dann geht sowas ja: Datei auf Karte schreiben, Karte rausziehen, zum anderen Teilnehmen gehen, reinstecken... usw. Aber ich schätze, daran hat der TO nicht gedacht. Noch einer schrieb: > Wie denn sonst? > > Bei Systemen mit Betriebssystem hat sich das UNIX Konzept durchgesetzt. > Alles ist ein FileDescriptor. Ganz egal ob Fernschreiber, Netzwerk oder > oder Festplatte. Ja, noch einer, der bloß Bahnhof versteht. Du verwechselst hier ganz grandios den Formalismus, den eine Applikation gegenüber dem Betriebsystem veranstalten muß, um eine Datei lesen zu können, mit der Übertragung von Daten zwischen zwei voneinander völlig unabhängigien Maschinen. Oder hast du das Internet und dort eine Datei irgendwo schon mal mit einem Filedescriptor gelesen oder geschrieben? Witzbold.. sowas geht NUR über die Protokolle, die zwischen deinem PC und dem Netzwerk Mode sind, also z.B. ftp und so - ganz egal, was für Aktionen dein Programm gegenüber dem BS auf deinem PC machen muß. W.S.
W.S. schrieb: > Aber ich schätze, daran hat der TO nicht gedacht. Bei 'Datei-Austausch-Format'^^? Eine Rätselraterei, was der TO gedacht haben könnte, bringt nix. Matz hat sich seit dem 22.05.2015 nicht mehr gemeldet. Wir werden es wohl nie erfahren.
temp schrieb: > Matthias schrieb: >> Jannson funktioniert ganz gut auf Cortex-Ms. Gibt auch ein CMSIS-PACK: >> http://az717401.vo.msecnd.net/pack/Keil.Jansson.1.0.0.pack > > Oha, das will ja nun wirklich keiner. Ok, Cortex M ist ein weiter > Begriff. Bei den großen mit externen RAM mag das ja ganz gut sein. Unter > Linux, Windows und Mac benutze ich die lib auch. Aber nur um ein Array > z.B. mit 100 int-Werten zu transferieren, werden wenigstens 200 mal > Speicher allociert und das gesamte Gebilde muss in den RAM. Das ist auf > einem M0-M3 ein no go. Warum sollte das so sein?
Matthias schrieb: > Warum sollte das so sein? Weil es so ist. Da reicht ein Blick in den Quellcode bzw. ein kleiner Debuggerlauf. Da kannst du dir ansehen wie oft da jsonp_malloc und free aufgerufen wird. Für jeden int-Wert wenigstens 1 mal bei Strings 2mal. Und wenn dann die Leute nicht mal ne Ahnung davon haben wie malloc und free auf ihrem Controller implementiert sind, dann könnte ich K... Mag sein, dass du das weißt und damit umgehen kannst. Will dir nichts unterstellen. Aber viele machen sich halt kaum Gedanken über die Libs die sie verwenden.
temp schrieb: > Fitzebutze schrieb: >> schau dir doch mal das netpp-protokoll an > > Meinst du das hier? > > http://www.section5.ch/netppres > Jep. > Dann sagen die beiden letzten Zeilen: > > netpp beta source, outdated, unsupported: Download > > The free netpp development tree is no longer maintained. The focus will > lie in commercial support only in future. Sorry. > Das hat den Grund, dass der Autor nicht mit zig Anfragen zu Gratissupport aus englischsprachigen Ländern zugemüllt werden will. Support kostet eben. Ansonsten ist die "beta" durchaus brauchbar. > warum man das und vieles was so ähnlich ist nicht haben will. 8-bit wird > da auch nicht mehr unterstützt, auch wenn mich das nicht wirklich > interessiert. Natürlich gehen noch 8-bitter. Man muss nur richtig lesen. Ich habe das Zeug über USB auf einem 8051 am Laufen (mit Bank-Switching). Allerdings ist es dafür nicht optimiert worden. Zum Thema malloc: Genau das sind Gründe, warum in manchen Applikationen dynamisches Memory-Management a la malloc komplett verboten sind. Spätestens dann, wenn man zig Wochen das laufende System mit "out of memory" aussteigt, geht der Terz los... Das hat mich bewogen, bei den kritischen Applikationen nur noch mit Memory-Pools für Laufzeit-Datentypen (auch in netpp) zu arbeiten. Die meisten Linux-Systeme (nicht alle) kommen mit Memory-Fragmentierung einigermassen klar, insofern würde ich da der Einfachheit halber auch JSON nehmen, sofern man nicht gerade Bilder überträgt.
Hallo zusammen, sorry, war stressbedingt etwas länger aff - away from forum... ;-) Erstmal Danke an alle für die sehr angeregte Diskussion. W.S. schrieb: > ...einen PC und einen µC. Kläre erstmal, auf welche Weise selbige > miteinander in Verbindung stehen,... Ich wollte das bewusst NICHT im Forum diskutieren, da diese Aufgabe bereits gelöst ist. Aber gut. W.S. schrieb: > Daten in Form von Dateien kann man nur zur Verfügung stellen, > wenn es irgendwo einen Speicher für Dateien gibt, auf den beide > Systeme einen Zugriff haben. Meinetwegen. W.S. schrieb: > Das heißt Netzwerk und Server darin. Geht auch anders. Also, dann hier ein paar Infos dazu: Cortex-M3 STM32F2XX. Die uC-PC-Verbindung ist als USB-MSD (Mass Storage Device) realisiert. Der PC greift dabei auf das am uC angeschlossene NAND-Flash zu. Datei-Austausch wie bei einer billigen (oder teuern) Kamera: anstecken: USB-Stick Funktion, Dateien austauschen. Zugriff des uC bzw. der Firmware per Filesystem. Diese Ebene / der Austausch ist also geklärt. Wie gesagt, das wollte ich hier eigentlich nicht erwähnen, weil es mir für meine Frage nicht relevant erschien (was ggf. falsch ist). So war meine Frage ganz allgemein gestellt: Datei-Austausch-Format für z.B. Messdaten, Statusdaten, Konfigdaten. JSON: Erfahrung mit Libraries für embedded C? Alternative Formate? Und dazu gibts ja hier auch tollen Austausch... und einiges was ich daraus aufbereiten muss...
:
Bearbeitet durch User
Also JSON ist dann toll, wenn man (relativ) komplexe Strukturen hat. Wenn Du das nicht hast, würde ich ein simples text- und zeilenbasiertes Format vorschlagen. Sprich jede "Botschaft" (z.Bsp. Datensatz) ist eine Zeile, welche mit, zum Beispiel, CRLF abgeschlossen wird. Die einzelnen Werte sind, zum Beispiel über Leerzeichen getrennt. Nummerische Werte überträgst Du idealerweise dezimal. Für Zeichenketten definierst Du ein Fluchtzeichen, zum Beispiel das \. Falls in der Zeichenkette ein Trennzeichen oder das Fluchtzeichen vorkommt, stellst Du das Fluchtzeichen davor. Dadurch erhältst Du dann Zeilen wie diese: 3 6 Dingsbums 3 21 34 54 Hallo\ Welt 3 18.34 5542 32 Back\\slash 3 12.43 Das ist einfacher zu verarbeiten als Microsofts Variante von CSV welche Anführungszeichen verwendet. Mehr zu dem Thema findest Du hier: http://www.catb.org/esr/writings/taoup/html/ch05s02.html
Christian Berger schrieb: > Sprich jede "Botschaft" (z.Bsp. Datensatz) ist eine Zeile, welche mit, > zum Beispiel, CRLF abgeschlossen wird. Die einzelnen Werte sind, zum > Beispiel über Leerzeichen getrennt. Nummerische Werte überträgst Du > idealerweise dezimal. > > Für Zeichenketten definierst Du ein Fluchtzeichen, zum Beispiel das \. > Falls in der Zeichenkette ein Trennzeichen oder das Fluchtzeichen > vorkommt, stellst Du das Fluchtzeichen davor. Dadurch erhältst Du dann > Zeilen wie diese: und wie überträgst du einen leeren string?
mit zwei Leerzeichen hintereinander
Mit : statt space als Trennzeichen: Ein leerer String:
3 leere Strings:
1 | :: |
1 leerer String, 1 Doppelpunkt, 1 String mit \n drin:
1 | :\::\ |
Torsten C. schrieb: > mit zwei Leerzeichen hintereinander und wie überträgst du einen Leerzeichen als String? solche einfachen Formate, machen früher oder später immer ärger. Das es json schon etwas durchdachter.
Christian Berger schrieb: > Nummerische Werte überträgst Du idealerweise dezimal. Es lohnt sich vielleicht nicht, darüber zu streiten, aber ich denke, dass man vorzugsweise INT benutzt und den besser als Hex überträgt. Das lässt sich im µC einfacher umwandeln. Wir wäre das mit Fließkomma? Ich nehme an, z.B. -1.738E-7 Und statt 18.34 vielleicht 1.834E1? Peter II schrieb: > und wie überträgst du einen Leerzeichen als String? Mit dem Escape-Zeichen. Oder "Fluchtzeichen", was für ein Wort. Ich sage nur: "Kellerspeicherüberlauf". ;-)
:
Bearbeitet durch User
Torsten C. schrieb: > Es lohnt sich vielleicht nicht, darüber zu streiten, aber ich denke, > dass man vorzugsweise INT benutzt und den besser als Hex überträgt. Das > lässt sich im µC einfacher umwandeln. Ja, wobei jetzt natürlich der Aufwand für die Dezimaldarstellung vernachlässigbar klein ist. Wir reden hier von wenigen Zeilen Code. > Wir wäre das mit Fließkomma? Ich nehme an, z.B. -1.738E-7 Ja, Fließkomma ist ein großes Problem. Es wurden ganze Doktorarbeiten nur darüber geschrieben, wie man korrekt Fließkommazahlen in Text überträgt. Die typische Lösung ist einfach zu sagen, dass man n gültige Ziffern verwendet was das Problem deutlich vereinfacht. Binär ist aber das Problem noch deutlich schlimmer, denn da gibt es mehrere inkompatible Normen für Fließkommazahlen. Fließkommazahlen haben eh auch noch ganz andere Probleme, man sollte wissen was man macht wenn man sie einsetzt.
Torsten C. schrieb: > Peter II schrieb: >> und wie überträgst du einen Leerzeichen als String? > > Mit dem Escape-Zeichen. Oder "Fluchtzeichen", was für ein Wort. Hab ich auch noch nie gehört, aber eine sehr einfallsreiche Kreation! :)
Peter II schrieb: > Torsten C. schrieb: >> mit zwei Leerzeichen hintereinander > > und wie überträgst du einen Leerzeichen als String? > > solche einfachen Formate, machen früher oder später immer ärger. Das es > json schon etwas durchdachter. Ergibt sich doch aus den einfachen Regeln. Ein Trennzeichen (Leerzeichen) wird durch ein Fluchtzeichen und ein Leerzeichen ersetzt: ... Trennzeichen Fluchtzeichen Trennzeichen Trennzeichen... Durch das Fluchtzeichen, wird das nächste Zeichen, egal was es ist, nicht mehr als Steuerzeichen behandelt. Damit kann man sogar Carriage Return oder gar beliebige Binärzeichen einbauen. Im Prinzip kriegst Du damit folgenden Pleudocode:
1 | SOLANGE |
2 | x:=Lese_Zeichen; |
3 | FALLS x=Fluchtzeichen |
4 | DANN An_Feldbuffer_anhängen(Lese_Zeichen) |
5 | SONST FALLS x=Feldtrenner |
6 | DANN Feldbuffer_Auswerten |
7 | SONST FALLS x=Zeilenende |
8 | DANN ENDE setzen |
9 | BIS ENDE |
Mit den paar Zeilen kannst Du dieses Format parsen. Deshalb wird es auch so häufig verwendet. In der Codierung von Zeichenkettenkonstanten hat es ältere Verfahren deshalb auch weitgehend ersetzt.
Christian Berger schrieb: > 3 6 Dingsbums 3 21 > 34 54 Hallo\ Welt 3 18.34 > 5542 32 Back\\slash 3 12.43 An eine ähnlich einfache Variante hatte ich ursprünglich gedacht. Die Definition auf beiden Seiten (PC und µC) ist in einer Hand. Je nachdem wie mans aufbaut ist der Parser auch schon fertig: sscanf :-) Ich schätze derzeit JSON als überzogen für unsere Aufgabe ein. Wenn Messwerte anfallen und in der Datei angehangen werden müssen, dann könnte es auch notwendig sein, stets die letzte JSON-Struktur zunächst einzulesen, zu ergänzen um die neuen Daten, und dann wieder wegzuschreiben. Also: file read, modify, file write. Bei einem zeilenweisen eigenen Datenformat bräuchte man dagegen nur jedesmal ins File wegschreiben (Datenzeile anhängen). Erscheint mir irgendwie pragmatischer.
Wenn ich hier "Escape-Zeichen" lese, kräuseln sich mir die Haare. Bloss die Finger von diesen Hacks lassen, da sind beliebte Stolperfallen (Buffer-Probleme) vorprogrammiert. Wenn es nicht unbedingt nötig ist, dass ein fortlaufender, nicht-paketbasierter Stream vom Gerät kommt (a la JPEG), dann ist die simpelste Lösung immer noch ein stupides Read/Write-Register-Protokoll mit definierter Maximal-Paketlänge und Timeouts. Ohne SOT/EOT und das ganze fehleranfällige Gekröse. Also auf konkret-Ascii:
1 | Write: |
2 | >{ [H: len, cmd] [ payload ] [chk] } < { [H: 0, ack] }
|
3 | |
4 | Read: |
5 | >{ [H: len, cmd] [ 0 ] [chk] } < { [H: len, ack] [ payload ] [chk] }
|
6 | |
7 | |
8 | >: out, <: in |
9 | H: header mit länge und Kommandotyp (R/W), data: Nutzdaten, chk: Checksumme |
Sowas reicht für den normalen Master/Slave-Betrieb. Wenn Slaves selber mal Master sein müssen, bloss nicht das Protokoll mit "Attention"-Messages a la Interrupts aufbohren. Besser Master/Slave bidirektional durch den Komm.-Layer tunneln. Aber vom Ausprobieren will ich niemanden abhalten, ist nur meine persönliche Erfahrung mit Protokollen. Ansonsten könnte ich das SWAP-Protokoll (für allerdings drahtlose Geräte) zur Orientierung empfehlen, besonders, wenn mehrere Sensoren an einem "Hub" hängen sollen.
Sorry, ich habe das Thread Thema unscharf gewählt. Thema ist Datei-Formate nicht Kommunikationsprotokolle für Streams. Ist aber natürlich ein nettes Of-Topic Thema.
:
Bearbeitet durch User
Na damit kommst du aber reichlich spät rum. Nachdem sich hier das halbe Forum bereits zerfetzt hat. W.S.
Mea culpa. Vielleicht führt der Hinweis auf die Eingangsfrage zur Milderung meiner Strafe. Aus dieser ging dies m.E. eindeutig hervor. Schönes Wochenende. M.K.
:
Bearbeitet durch User
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.