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.
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.
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.
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 einembestimmten µ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...
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?
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". ;-)
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:
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.
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.
Thread beobachten
Seitenaufteilung abschalten