Forum: Mikrocontroller und Digitale Elektronik JSON für Daten-Austausch zwischen uC und PC?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Matz K. (xt-matz)


Lesenswert?

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.

von Sascha W. (sascha-w)


Lesenswert?

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

von Peter II (Gast)


Lesenswert?

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.

von Michael R. (Firma: Brainit GmbH) (fisa)


Lesenswert?

Peter II schrieb:
> JSON hat ja den Vorteil, das man weniger Overhead als bei XML hat.

nicht nur den...

von Jim M. (turboj)


Lesenswert?

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.

von Chefkoch (Gast)


Lesenswert?

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.

von kringel (Gast)


Lesenswert?

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.

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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.

von Tom (Gast)


Lesenswert?

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.

von kringel (Gast)


Lesenswert?

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...

von Noch einer (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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 
:-)

von Elliot (Gast)


Lesenswert?


von Noch einer (Gast)


Lesenswert?

> 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?

von Jasch (Gast)


Lesenswert?

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^(

von Stefan F. (Gast)


Lesenswert?

> 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.

von Noch einer (Gast)


Lesenswert?

> 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.

von Achim H. (anymouse)


Lesenswert?

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.

von Gerd E. (robberknight)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Noch einer (Gast)


Lesenswert?

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.)

von W.S. (Gast)


Lesenswert?

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.

von Noch einer (Gast)


Lesenswert?

> 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?

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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.

von Marian (phiarc) Benutzerseite


Lesenswert?

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.

von Jasch (Gast)


Lesenswert?

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.

von Marian (phiarc) Benutzerseite


Lesenswert?

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...

von temp (Gast)


Lesenswert?

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.

von Marian (phiarc) Benutzerseite


Lesenswert?

Ich meinte viel mehr, dass die Encoding-Problematik auf MCUs irrelevant 
ist, weil man eh nicht genug Speicher hat um Unicode korrekt zu 
implementieren.

von Matthias (Gast)


Lesenswert?

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

von temp (Gast)


Lesenswert?

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.

von Jasch (Gast)


Lesenswert?

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.

von temp (Gast)


Lesenswert?

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.

von Fitzebutze (Gast)


Lesenswert?

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.

von temp (Gast)


Lesenswert?

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.

von Andreas S. (andreas) (Admin) Benutzerseite


Lesenswert?

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).

von temp (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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.

von Matthias (Gast)


Lesenswert?

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?

von temp (Gast)


Lesenswert?

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.

von Fitzebutze (Gast)


Lesenswert?

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.

von Matz K. (xt-matz)


Lesenswert?

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
von Christian B. (casandro)


Lesenswert?

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

von Peter II (Gast)


Lesenswert?

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?

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

mit zwei Leerzeichen hintereinander

von Tom (Gast)


Lesenswert?

Mit : statt space als Trennzeichen:

Ein leerer String:

3 leere Strings:
1
::

1 leerer String, 1 Doppelpunkt, 1 String mit \n drin:
1
:\::\

von Peter II (Gast)


Lesenswert?

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.

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

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
von Christian B. (casandro)


Lesenswert?

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.

von Marian (phiarc) Benutzerseite


Lesenswert?

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! :)

von Christian B. (casandro)


Lesenswert?

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.

von Matz K. (xt-matz)


Lesenswert?

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.

von Fitzebutze (Gast)


Lesenswert?

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.

von Matz K. (xt-matz)


Lesenswert?

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
von W.S. (Gast)


Lesenswert?

Na damit kommst du aber reichlich spät rum. Nachdem sich hier das halbe 
Forum bereits zerfetzt hat.

W.S.

von Matz K. (xt-matz)


Lesenswert?

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
Bitte 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
Noch kein Account? Hier anmelden.