Hallo,
seit kurzem ist JSON offizeller ECMA-Standard:
http://www.ecma-international.org/publications/standards/Ecma-404.htm
Es ist ein einfaches Datenformat für fast beliebige Daten.
Hier im Forum gibts schon 73 Threads in denen JSON erwähnt wird.
Was nun fehlt: ein Standard als Pendant für mikrocontroller, ich nenne
es mal "µSON".
Mein Vorschlag:
Statt unicode 7bit ascii, statt /u0000 hexadezimal /x00, /b00000000,
/000, freiwilliges weglassen von Hochkommas.
Anwendung von µSON:
-Logdateien
-Konfiguration
-Messen und Steuern
Was ist von dieser Idee zu halten? Alternativ: gleich beim JSON Standard
bleiben
Besser als XML wäre es allemal, es würde allen Daten eine einheitliche
Form, die leicht zu erstellen und zu parsen ist, geben.
Grüße, Wash
Hmm, kann man mal ein Beispiel dieses Dateiformats erstellen, denn nur
die trockenen Syntaxabbildungen sind etwas, trocken.
Wobei ich nicht den großen Vorteil bei dem Format erkenne.
Ist doch nix großartig anderes als CSV.
Ein paar Beispiele:
1. Beispiel: nur ein Parameter
{"PWM1":255}
oder
{"ERROR":"404 JSON NOT DEFINED"}
oder
{"COMMANDO":"SHUTDOWN"}
2. Beispiel: weggespeicherte Logdaten:
...
{GPS:{timestamp:0x000456, long:-40.00,lat:23.12}}
{TEMP:{timestamp:0x001123, value:21.2}}
{GPS:{timestamp:0x002755, long:-40.00,lat:23.12,velx:0.00,vely:0.02}}
{GPS:{timestamp:0x003234, height:5.55, long:-40.00,lat:23.12}}
...
Obiges kann nicht jeder JSON-Parser verstehen. Wenn man korrekt bleiben
will, müsste man alle strings in Hochkomma packen und kein 0x00
verwenden.
Der große Vorteil ist: Ein einziges Format, was für fast alles taugt.
CSV taugt nicht für Kommandos oder wenn man nicht alle Werte für alle
Spalten hat, oder wenn man nicht die Bedeutung der Spalten kennt weil
die Kopfzeile fehlt.
Es ist ein Format, was man leicht in jeder Programmiersprache erzeugen
und parsen kann, und taugt auch für Android etc, es ist kompakter als
XML, und kann dennoch bei Bedarf auch tief verschachtelte Daten erzeugen
(Ob der Empfänger so tief Parsen kann liegt dann am Empfänger).
Uhu Uhuhu schrieb:> Einen Vorteil gegenüber xml kann ich nicht erkennen.
Ich schon. JSON ist zwar auch nicht das gelbe vom Ei, aber allemal
besser als der XML-Schwachsinn. Schon mal einen XML-Parser programmiert?
je lesbarer die formate sein sollen desto aufgeblasener werden sie - und
platz/datenrate sind bei µc eigentlich eine knappe resource.
das ist irgendwie vergleichbar mit geschwindigkeit vs platzverbrauch…
"code" der schnell sein soll braucht platz, "code" der klein sein soll
ist nicht der schnellste.
also wenn interoperabilität im projekt wichtig ist dann ja, json oder
xml, ansonsten eher ein proprietäres format.
Johann L. schrieb:> Strom kommt ja auch aus der Steckdose :-)
Ja, oder erzeugst du deinen selbst?
Ein XML-Parser ist doch genauso einfach nur ein Werkzeug wie ein
Compiler oder eine Standardbilbiohtek.
Ok, XML ist auch toll.
Aber..
JSON style:
{"Switch1":"On"}
XML style:
<switch value="on"></switch>
oder abgefahrener
<switch> <on></on></switch>
oder doch
<settings>
<switches>
<switch id="1">
<value>On</value>
</switch>
</switches>
</settings>
oder doch etwas umfangreicheres mit komplexer DTD.
Was ich damit sagen will: mit XML kann man Unmengen an Schabernack
treiben, man muss sich nur mal ein leeres docx Dokument anschauen.
XML ist eben als ein Dokumentenformat entwickelt worden, dessen
Markuplanguageteil man aber auch für einfache Daten benutzen kann.
JSON ist dagegen konzipiert als Container für Daten mit Struktur, kleine
Datenpakete, hatte also einen anderen Ansatz.
Gut, bisher kam also als Alternativen:
CSV - da fällt mir gerade NMEA ein.
XML - taugt gut für einzelne Dokumente, aber auch für Data Streams.
und natürlich gibt es eigene Formate, die sind selbstverständlich am
kompaktesten.
Michael Reinelt schrieb:> Uhu Uhuhu schrieb:>> Einen Vorteil gegenüber xml kann ich nicht erkennen.
Hähäh. Dito.
> Ich schon. JSON ist zwar auch nicht das gelbe vom Ei, aber allemal> besser als der XML-Schwachsinn.
Es ist in erster Linie kompakter. Das wars dann schon.
XL
Washington I. schrieb:> XML ist eben als ein Dokumentenformat entwickelt worden, dessen> Markuplanguageteil man aber auch für einfache Daten benutzen kann.
Einfache Daten? Nee, die können ziemlich verzwickt strukturiert sein.
> JSON ist dagegen konzipiert als Container für Daten mit Struktur,
xml auch.
Ich finde xml auch unleserlich und alles andere, als schön. Aber ich
will es weder lesen, noch bestaunen...
Washington I. schrieb:> oder doch etwas umfangreicheres mit komplexer DTD.
DTD? Das war doch im letzten Jahrtausend, oder? ;-)
XSD ist aktuell als Definitionsstandard.
> Was ich damit sagen will: mit XML kann man Unmengen an Schabernack> treiben, man muss sich nur mal ein leeres docx Dokument anschauen.
Wobei die Office-Formate eher als schlechtes Beispiel herhalten. Da
hat jemand in XML einfach nur den gleichen Krempel umgesetzt, den sie
vorher schon in ihrem proprietären Binärformat so gezimmert hatten.
Washington I. schrieb:> Was ich damit sagen will: mit XML kann man Unmengen an Schabernack> treiben, man muss sich nur mal ein leeres docx Dokument anschauen.
docx beiseite. man kann mit einem xsd z.b. in einer oracle datenbank
einfach ein datenmapping aufbauen und mit dem gleichen xsd und einem
wsdl z.b. mit axis2 einen webservice generieren lassen der die daten aus
vorhergehender datenbank übernimmt, verarbeitet und weiterleitet.
man kann sich mit xml also das entwicklerleben einfacher machen, aber
eben wie ich schon schrieb auf kosten von speicherplatz, bandbreite und
verarbeitungsgeschwindigkeit.
kommt immer auf den anwendungsfall an - deswegen einen standard zu
definieren und darauf zu pochen das der auch benutzt werden muss ist
unter umständen kontraproduktiv.
Washington I. schrieb:> freiwilliges weglassen von Hochkommas.
Ich nehme an, du meinst die Anführungszeichen.
Die weguzulassen ist eine ganz, ganz schlechte Idee, weil die Daten dann
den Parser zum Absturz bringen können, z.B. wenn in einem Text : oder }
steht.
XML ist eine Auszeichnungssprache für Dokumente, JSON eine Sprache zur
Darstellung der Inhalte von Datenstrukturen. Auch wenn es Überlappungen
gibt, sind dies zunächst einmal zwei verschiedene Anwendungsbereiche.
Natürlich kann man Dokumente auch als Datenstruktur auffassen und somit
in JSON darstellen, wie in folgendem Beispiel gezeigt:
XML:
1
<dokument>
2
Dieser Text enthält <kursiv>kursive</kursiv> und <fett>fette</fett> Abschnitte.
3
</dokument>
JSON:
1
[
2
{
3
"auszeichnung": "normal",
4
"text": "Dieser Text enthält "
5
},
6
{
7
"auszeichnung": "kursiv",
8
"text": "kursive"
9
},
10
{
11
"auszeichnung": "normal",
12
"text": " und "
13
},
14
{
15
"auszeichnung": "fett",
16
"text": "fette"
17
},
18
{
19
"auszeichnung": "normal",
20
"text": " Abschnitte."
21
}
22
]
In XML können im laufenden Text weitere XML-Elemente stehen, was zu
einer recht übersichtlichen Darstellung führt. In JSON hingegen muss der
Text in mehrere Einzelstrukturen zerstückelt werden, so dass die
Darstellung nicht nur deutlich länger, sondern auch schwerer lesbar
wird.
Andersherum kann man für Datenstrukturen auch ein entsprechendes
XML-Format definieren:
JSON:
1
{
2
"farbe" : "rot",
3
"punkte" : [{ "x": 0.0, "y": 0.0 },
4
{ "x": 3.5, "y": 0.0 },
5
{ "x": 3.5, "y": 4.5 },
6
{ "x": 0.0, "y": 4.5 }]
7
}
XML:
1
<objekt>
2
<element name="farbe">
3
<string>rot</string>
4
</element>
5
<element name="punkte">
6
<liste>
7
<objekt>
8
<element name="x"><zahl>0.0></zahl></element>
9
<element name="y"><zahl>0.0></zahl></element>
10
</objekt>
11
<objekt>
12
<element name="x"><zahl>3.5></zahl></element>
13
<element name="y"><zahl>0.0></zahl></element>
14
</objekt>
15
<objekt>
16
<element name="x"><zahl>3.5></zahl></element>
17
<element name="y"><zahl>4.5></zahl></element>
18
</objekt>
19
<objekt>
20
<element name="x"><zahl>0.0></zahl></element>
21
<element name="y"><zahl>4.5></zahl></element>
22
</objekt>
23
</liste>
24
</element>
25
</objekt>
Die JSON-Syntax sieht nicht viel anders aus als die Literale in den
meisten Programmiersprachen (Python, C99 usw.). Das ist auch nicht
weiter verwunderlich, da es sich dabei um Javascript-Syntax handelt. Die
Typinformation, die in JSON durch die Syntax der Literale gegeben ist,
muss in XML durch entsprechende Tags mitgeliefert werden, was die
Darstellung gewaltig aufbläst und unübersichtlich macht.
Die Beispiele zeigen: Obwohl beide Sprachen mächtig genug sind, um
beliebige Informationen darzustellen, hat jede von ihnen ihre eigene
Domäne, in der sie ihre Stärken ausspielen kann.
Washington I. schrieb:> Anwendung von µSON:> -Logdateien> -Konfiguration> -Messen und Steuern
Da es in diesen Anwendungen primär um Datenstrukturen geht, ist dafür
JSON in meinen Augen die bessere Wahl.
Washington I. schrieb:> Was nun fehlt: ein Standard als Pendant für mikrocontroller, ich nenne> es mal "µSON".
Wenn es dir nur um JSON in Binär geht, bittesehr: http://bsonspec.org/#/
Die ganzen Beispiele wie schön und klar doch XML ist, haben nur einen
klitzekleinen Nachteil: Man begegnet so schönen XML's "da draußen"
leider fast nie...
1
<switch value="on"></switch>
schön wärs, in der Praxis ist das sowas wie
1
<attrlist>
2
<attribute>
3
<name>switch</name>
4
<type>string</type>
5
<value>on</value>
6
</attribute>
7
</attrlist>
Besonders meine Freunde aus Redmond liebe ich da heiß für ihre
Serialisierung....
Und damit komme ich auch zu meinem meiner Hauptkritikpunkte an XML: aus
dem Format geht nicht hervor, ob ein Element einfach oder mehrfach
vorkommen kann. Und genau dieses Problem löst z.B. JSON sehr schön,
indem es die eckige Klammer verwendet, um eine Liste einzuleiten.
Ja, XML hat auch mein Leben vereinfacht. CSV lässt mich regelmäßig
erschaudern (Umlaute, mehrzeiliger Feldinhalt, Texterkennung, ...)
Andererseits hätte man halt manches in XML besser und einfacher (und mit
weniger Overhead) machen können.
Übrigens hab ich sowas wie JSON schon verwendet, als es noch kein JSON
gab: meine Aufgabe war eine Datenübernahme komplexer Produktstrukturen
aus einem PDM-System in ein anderes. Mehrere Millionen Datensätze,
komplexe Strukturen, jedes Element in seiner eigenen XML-Datei,
Querverweise zwischen den XML-Dateien. In punkto Rechenzeit
(XML-Parser!) und Speicherplatz (nicht zuletzt die vergleichsweise
riesigen Dateien wegen XML-Overhead) praktisch nicht mehr handhabbar.
Umwandeln aller XML-Files in etwas JSON-ähnliches (eigentlich eine
Perl-Datenstruktur bestehend aus Hashes und Arrays, rausgeschrieben mit
Data::Dumper, eingelesen mit eval() ) => Speicherplatz/100,
Rechenzeit/300
>Wenn es dir nur um JSON in Binär geht, bittesehr: http://bsonspec.org/#/
BSON ist auf den ersten Blick recht sympathisch.
PRO: Die BSON Syntax geht auf ein paar Zeilen und ein En-/Decoder sind
einfach auf einem µC zu schreiben.
CONS: BSON ist
- redundant (viele Längenelemente, gut zum Syncen auf Streams)
- die Längen-Elemente sind auf große Datenmengen ausgelegt
- es gibt keine byte- und unsigned int Datentypen als Werte.
Beispiel von der Webseite:
Durch den Overhead ist BSON nicht perfekt fuer den µC Einsatz geeignet.
Man koennte die Definitionen etwas Abruesten, sozusagen ein BSON8
definieren und das Ergebnis versuchen bei BSON mit einzubringen.
PS: Von einem µ im Protokoll-Namen würde ich nach 5 Jahren mit µracoli
eher abraten ;-)
Es gibt einen Punkt den man bei der Betrachtung nicht vergessen sollte.
Ein Grund für den "Siegeszug" von JSON ist, dass es nativ von allen
Webbrowsern unterstützt wird. Das bedeutet, wenn ich selbst auf einem
kleinen µC einen Webserver betreibe und die statische GUI (html,js) von
den Daten trenne und die Daten dann per AJAX anfordere, dann ist JSON
das Format der Wahl. Klein, leicht und gut zu verstehen auf beiden
Seiten. XML und CSV oder ein spezielles Format erfordern im Browser
immer erst einen Parser. Das entfällt für JSON als Transportschicht
komplett. Das haben auch einige schon in ihren Webservices erkannt. JSON
ist da deutlich resourcenschonender als XML.
Leider interessiert das heute aber irgendwie kaum noch einen. Egeal wie
groß die Lib's sind die man verwendet. Hauptsache es geht irgendwie.
Jörg Wunsch schrieb:> Ein XML-Parser ist doch genauso einfach nur ein Werkzeug wie ein> Compiler oder eine Standardbilbiohtek.
Wobei du dir gern mal ansehen solltest, wie groß die Implementierungen
von JSON- und XML-Parsern sind und welchen Speicherbedarf sie zur
Laufzeit haben.
Um beim Stromvergleich zu bleiben. Das ist so als ob du in deinem Haus
nur 32A Kraftsteckdosen verbaust weil es ja so schön einheitlich ist....
Schließlich ist es ja nur Strom und mein Küchenradio geht damit über
einen "kleinen" Adapter doch auch.
Auch einfache Werkzeuge sollte man immer mal wieder darauf untersuchen
ob sie auch wirklich zur Aufgabe passen oder nur geeignet sind.
Jürgen Liegner schrieb:> Wobei du dir gern mal ansehen solltest, wie groß die Implementierungen> von JSON- und XML-Parsern sind und welchen Speicherbedarf sie zur> Laufzeit haben.
Du hast das falsch verstanden: das sollte in keiner Weise ein
Plödoyer sein, dass man grundsätzlich statt JSON XML benutzt.
Jedes Werkzeug für seine Aufgabe.
Michael Reinelt schrieb:> Und damit komme ich auch zu meinem meiner Hauptkritikpunkte an XML: aus> dem Format geht nicht hervor, ob ein Element einfach oder mehrfach> vorkommen kann.
Da liegst du falsch.
Jürgen Liegner schrieb:> Ein Grund für den "Siegeszug" von JSON ist, dass es nativ von allen> Webbrowsern unterstützt wird.
Das ist m.A. der einzige wirklich handfeste Grund, der für JSON spricht.
> JSON ist da deutlich resourcenschonender als XML.
Nur bedingt: Wenn die Daten zum Transport komprimiert werden, dann ist
es ziemlich egal, ob JSON, oder xml zum Zug kommt.
Bei kleinen Datenmengen und wenn ein einfacher Reload der Webseite zur
Darstellung aktueller Daten ausreicht ist es mit Abstand das Einfachste,
eine HTML Webseite komplett im Mikrocontroller zu erstellen/vorzuhalten
und dann auf Anfrage auszuliefern. Benötigte Grafiken usw. können von
anderem Webspace verlinkt werden.
Nicht daß noch jemand auf die Idee kommt man müsste zum Zugriff auf den
heimischen Controller Komplexität und Lernaufwand mit Ajax, Json & Co
unnötig aufblasen.
Dennis S. schrieb:> Nicht daß noch jemand auf die Idee kommt man müsste zum Zugriff auf den> heimischen Controller Komplexität und Lernaufwand mit Ajax, Json & Co> unnötig aufblasen.
Das sehe ich anders. Ajax im Browser ist in max. 20 Zeilen kodiert. Der
µC braucht sich nur noch um die relevanten Daten zu kümmer. Alles was
statisch ist kann durchaus von anderen Orten kommen. Es ist aber auf der
µC Seite wesentlich entspannter ausschließlich Daten zu liefern und
nicht dynamisch html-Seiten zu Parsen und darin Ersetzungen zu machen.
Das ist aber der übliche Weg wenn die Seiten nicht so trivial sind, dass
auch die html-Tags durch den µC zusammengebaut werden. Ich verweise nur
mal auf das httpd-Beispiel von µIP. Schön ist was anderes.
Ab wann etwas aufgeblasen ist oder nicht entscheidet die Komplexität der
Anwendung. Wenn die Html-Seite nur aus der Anzeige der Aussentemperatur
besteht gebe ich dir recht.
Falk Brunner schrieb:> Wobei ich nicht den großen Vorteil bei dem Format erkenne.> Ist doch nix großartig anderes als CSV.
CSV ist flach und Zeilen/Spaletn-orientiert, JSON ermöglicht es
Objektstrukturen und Hierarchien abzubilden, es gibt feste Datentypen
(String, Zahl, Boolean, Array, Hash).
Ein µJSON macht eigentlich keinen Sinn, JSOn ist schon dermaßen minimal,
und wenn es auf die letzen paar bits und bytes ankommt hat man
vermutlich für die Aufgabe den falschen Controller gewählt.
Zu dem XML Vergleich: In meinen Augen Blödsinn. Und wenn es 100x in
Wikipedia steht, sind das weder zwei vergleichbare noch austauschbare
Formate, und jedes hat seine Daseinsberechtigung und seinen
Einsatzzweck.
Und genauso wie bei Programmiersprachen gibt es Leute die das passende
Werkzeug nutzen und welche die nur den Hammer kennen und deshalb alles
wie ein Nagel aussieht.
Ich finde es auch immer wieder lästig, wenn ich strukturierte Daten in
XML vorgesetzt bekomme. XML ist eine Dokumentenauszeichnungssprache. Es
gibt in XML keinen generischen Weg, grundlegende Datenstrukturen
(Listen, Hashes) abzubilden, und jeder der es dazu missbraucht kocht
deshalb sein eigenes Süppchen. Glücklicherweise tritt zumindest bei
Web-APIs inzwischen JSON den Siegeszug an.
Es gab übrigens schon vor JSON ein mittelmäßig verbreitetes Format für
strukturierte Daten: YAML. Ist sogar noch schöner lesbar.
Uhu Uhuhu schrieb:> Michael Reinelt schrieb:>> Und damit komme ich auch zu meinem meiner Hauptkritikpunkte an XML: aus>> dem Format geht nicht hervor, ob ein Element einfach oder mehrfach>> vorkommen kann.>> Da liegst du falsch.>>
>> Für maxOccurs kann auch eine Zahl angegeben werden.
Ja sehr super. In der Praxis hast du die halbe Zeit kein Schema, die
andere halbe zeit stimmt es nicht oder ist veraltet, und außerdem: XML
ist ja noch nicht aufgeblasen genug, wir müssen die CPU ja unbedingt
auch noch mit einem Schema-Parser beschäftigen...
Das mag alles schön in der Theorie sein, die Praxis da draußen sieht
leider anders aus. Vor allem seit jeder Furz in XML kodiert wird, weil
es ja so schön hip ist, und außerdem braucht man ja nur
object.serialize() aufrufen...
deswegen mag ich JSON: "reduced to the max"
Michael Reinelt schrieb:> In der Praxis hast du die halbe Zeit kein Schema, die andere halbe zeit> stimmt es nicht oder ist veraltet
Das Schema braucht man ja normalerweise auch nur, um die Software
selbst zu validieren, die das XML erzeugt. Wenn man es benutzen will,
um jedes einzelne Dokument erstmal zu validieren, obwohl man dem
Generator des Dokuments eigentlich vertraut, dann ist da irgendwas
grundlegend faul.
Wenn das Schema nicht stimmt oder veraltet ist, ist noch mehr faul.
Wenn sich Generator und Konsument nicht über die Syntax und Semantik
der ausgetauschten Daten einig sind, kannst du XML genauso vergessen
wie JSON oder irgendein völlig proprietäres Binärformat.
Also wenn ich nur einfach und kompakt eine Datenmenge unterbringen
möchte, die in irgendeiner Form strukturiert ist, dann würde ich auf dem
Mikrocontroller vermutlich sogar ASCII-Steuerzeichen verwenden.
Mit denen lässt sich schon recht elegant hantieren. Unter der Annahme
natürlich, dass am anderen Ende wieder ein Programm diese Daten
zerpflückt und dass ich möglichst wenig Redundanz haben möchte. Denn
genau diese bläht XML und JSON auf: Wenn ich ohnehin ein festes
Datensatzformat ablege, brauche ich nicht in jedem Datensatz noch die
Feldbezeichner mitzuschleppen.
Jürgen Liegner schrieb:> Wenn die Html-Seite nur aus der Anzeige der Aussentemperatur> besteht gebe ich dir recht.
Was mit einem Wert einfach ist wird mit 20 kaum komplizierter.
Es braucht nur den Mikrocontroller, der auf eine entsprechende GET
Anfrage eines Webbrowsers sein bischen vorbereiteten HTML-Code sendet;
noch nicht einmal irgendeine eigene Webseite/Webspace ist dafür nötig.
Wenn ich die Sache mit Ajax/Json recht begriffen habe wird das doch erst
interessant bei (und/oder)
-sehr vielen Daten, die
-programmsprachlich verarbeitet,
-grafisch anspruchsvoll aufbereitet,
-in Echtzeit (ohne Reload) angezeigt,
-mit einer Datenbank verknüpft werden sollen.
!?
Dennis S. schrieb:> Wenn ich die Sache mit Ajax/Json recht begriffen habe wird das doch erst> interessant bei (und/oder)>> -sehr vielen Daten, die> -programmsprachlich verarbeitet,> -grafisch anspruchsvoll aufbereitet,> -in Echtzeit (ohne Reload) angezeigt,> -mit einer Datenbank verknüpft werden sollen.
Mal angenommen du möchtest ohne viel Aufwand den Verlauf über die Zeit
in einem Diagramm darstellen. Das geht heute mit html5 und dem
Canvasobject ohne dass wie früher Bilder erzeugt werden. Der µC würde
z.B. alle 2min einen Datensatz per Ajax abliefern und bei Bedarf eine
auf SD-Karte abgelegt Historie über einen bestimmten Zeitraum. Bei 10
Werten geschätzte 200 Byte/Datensatz.
Alles andere wird dann vom JS im Browser direkt erzeugt.
Damit ist kein µC überfordert der Tcp/Ip kann. Klar ist das mit einem
gewissen Aufwand verbunden, eröffnet aber viele weiter Möglichkeiten.
Noch ein Aspekt:
Sobald html-Tags im Controller zusammengebaut werden, steigt der Aufwand
für Firmawareupdates auf dem Controller überproportional, da nirgends
soviel Änderungen anfallen wie bei der GUI. Eine reine
Datenschnittstelle hat diesen Änderungsbedarf nicht.
Ein eigener Webspace ist hier auch nicht nötig. Nur möglich. Den
statischen Teil lädt der Browser maximal 1 mal vom Controller und nicht
bei jeder Aktualisierung aufs neue. Das kann schon einen gewaltigen
Unterschied ausmachen. Auch während der Entwicklung können die üblichen
komfortabelen Werkzeuge auf dem PC benutzt werden, der Hauptteil der GUI
Entwicklung passiert halt auf dem PC und nicht im Controller.
Mit Datenbanken hat das absolut nichts zu tun.
Ich wollte damit auch nur sagen, dass es sich lohnt hin und wieder über
den Tellerrand zu gucken.
Insbesondere für Messwerte kann ein JSON-Stream extrem einfach auf dem
µC erzeugt werden, da dass Format ziemlich trivial ist. JS,Php,Java
wandeln das dann mit einem einzigen Funktionsaufruf in ihre interen
Datenrepräsentation. Da lohnt es sich nicht sich etwas auszudenken und
dann noch einen Parser dafür zu schreiben.
Ja, das leuchtet durchaus ein- wenn die Ansprüche größer werden und/oder
wir hier von mehr als etwas Hobbyprogrammierung reden scheint die
professionelle Lösung via Ajax/Json das flexible Mittel der Wahl. Wenn
die schnelle Realisierung im Vordergrund steht sind natürlich aber auch
(noch nicht) vorhandene Kentnisse /Lernaufwand von Bedeutung... Nachdem
(m)eine kleine 20 Messwert-HTML Seite in 0,nichts aus dem Controller
geladen ist (steht fertig im RAM, der Controller setzt nur aktuelle
Strings in die vorgesehenen Lücken) bleib ich zwar erst mal dabei. Zumal
ein paar geplante, JS vorcodierte, simple Canvas-History-Diagramme mehr
das Kraut sicher auch nicht fett machen dürften. Aber die zusätzliche
Möglichkeit der Json Datenausgabe werde ich nun auch einplanen!
Unabhängig von der Notwendigkeit einer solchen Implementierung wollte
ich einmal auf einen bereits sehr minimalistischen json-parser
hinweißen, mitdem sich standard json code bereits relativ
resourcenschonend verarbeiten lässt:
http://zserge.bitbucket.org/jsmn.html
Frohes diskutieren noch ;)
Thread beobachten
Seitenaufteilung abschalten