json op een gprs modem

[orf]

Voor een klant heb ik een webservice opgezet waar een gprs modem mee kan communiceren. De klant heeft een programmeur die zorgt voor de software (C) op het modem. Nu weet ik best wat van webservices, maar ik heb weinig kaas gegeten van embedded C.

Het GPRS modem zit in een auto, samen met een systeembord. Het systeembord verzamelt allerlei data van de auto (snelheid, GPS positie, temperatuur, etc), het modem moet deze data versturen naar mijn webservice over een GPRS verbinding (gewoon TCP).

Omdat ik de communicatie met een zelfverzonnen standaard niet zo handig vindt, er betrekkelijk veel overhead-data verstuurd wordt en ik sowieso een voorstander ben van standaarden heb ik voorgesteld om de communicatie in JSON te doen.

De programmeur van het modem bouwt nu de data op in JSON, maar doet dit zelf door strings aan elkaar te plakken. Daardoor zie ik vele syntaxfouten en ik was juist in de veronderstelling dat je hiervoor simpelweg een library kunt gebruiken. Op json.org vond ik bijvoorbeeld al deze lib: cJSON, maar volgens de programmeur kon dit niet gebruikt worden. Heeft hier iemand ervaring met een JSON library voor een device als een modem?

Ik zou verwachten dat je in je C software de data (van het systeembord) als variabelen / arrays / etc hebt en dat je met een JSON library gewoon een simpele JSON encode kunt doen, waardoor je niet zelf heel foutgevoelig de JSON op gaat bouwen als tekst.

De klant vertelde me daarnaast dat het systeembord via XML communiceert met het modem. Ook dat vind ik zeer opmerkelijk klinken, ik zou toch verwachten dat die data gewoon binnenkomt op een bus? Helaas weet ik hier te weinig van om iets te roepen, misschien kan iemand me voorzien van munitie.

Dank!

[Grijze Vos]

Embedded C apparaten hebben vaak een ontzettend kleine hoeveelheid geheugen beschikbaar. Vaak delen code en data ook nog eens een stuk geheugen, waardoor een library al snel voor teveel overhead kan zorgen.

[orf]

Ja, daar kan ik me wel iets bij voorstellen. De programmeur heeft eerder aangegeven dat er nog zo'n 12KB vrij is op het flash geheugen. De library is 6KB. Of bedoel je werkgeheugen?

[Grijze Vos]

Soms is dat hetzelfde. Een deel van de rom is dan voor werkgeheugen, de rest wordt opgeslokt door applicatie & data.

Is bijvoorbeeld bij deze apparaatjes zo. Ik heb een scripttaal geschreven die geinterpreteerd wordt, om om de geheugenlimitaties heen te komen. (zit een microchip pic24 controller in)

[ Voor 5% gewijzigd door Grijze Vos op 09-05-2012 15:27 ]

[epic007]

orf schreef op woensdag 09 mei 2012 @ 14:24:
...
Ik zou verwachten dat je in je C software de data (van het systeembord) als variabelen / arrays / etc hebt en dat je met een JSON library gewoon een simpele JSON encode kunt doen, waardoor je niet zelf heel foutgevoelig de JSON op gaat bouwen als tekst.

Dit is dus niet zo.. de C code wordt gecompileerd naar binaire native code en daarbij gaan alle namen van variabelen verloren. Deze zullen dus waarschijnlijk altijd handmatig gecodeerd moeten worden, of je nou JSON of XML of een ander tekst gebaseerd protocol gebruikt.

Die JSON library ziet er op het eerste gezicht vrij compact en bruikbaar uit.. maar misschien heeft de cpu die jullie gebruiken toch te weinig geheugen om de library mee te nemen.. Of er wordt tijdens het opbouwen van de JSON string te veel geheugen aangemaakt.

[ Voor 17% gewijzigd door epic007 op 09-05-2012 16:37 ]

[voodooless]

Ik weet niet hoe vaak je data wil opsturen, maar denk er ook aan dat iedere byte geld kost. JSON is extreem inefficiënt als het om data gaat, en dus misschien wel niet geschikt.

Verder heb je natuurlijk geen library nodig om JSON te gebruiken op je Uc. Aangezien je alleen dingen op gaat sturen kun je af met simpel string plakken.

[orf]

Grijze Vos schreef op woensdag 09 mei 2012 @ 15:26:
Soms is dat hetzelfde. Een deel van de rom is dan voor werkgeheugen, de rest wordt opgeslokt door applicatie & data.

Is bijvoorbeeld bij deze apparaatjes zo. Ik heb een scripttaal geschreven die geinterpreteerd wordt, om om de geheugenlimitaties heen te komen. (zit een microchip pic24 controller in)

Dat klinkt mooi. Ik zie de programmeur niet zo snel een geïnterpreteerde taal schrijven. Ik heb geen idee hoe het zit met de geheugenlimitaties van dit modem. Ik heb slechts een PDF gevonden met de specs: http://www.atmel.com/Images/doc8011.pdf.

epic007 schreef op woensdag 09 mei 2012 @ 16:34:
[...]

Dit is dus niet zo.. de C code wordt gecompileerd naar binaire native code en daarbij gaan alle namen van variabelen verloren. Deze zullen dus waarschijnlijk altijd handmatig gecodeerd moeten worden, of je nou JSON of XML of een ander tekst gebaseerd protocol gebruikt.

Die JSON library ziet er op het eerste gezicht vrij compact en bruikbaar uit.. maar misschien heeft de cpu die jullie gebruiken toch te weinig geheugen om de library mee te nemen.. Of er wordt tijdens het opbouwen van de JSON string te veel geheugen aangemaakt.

Ik weet daar niet zoveel vanaf, ik veronderstelde dat data die binnenkomt op het modem wel op één of andere manier in een variabele terecht komt die je zou kunnen encoden als json.

voodooless schreef op woensdag 09 mei 2012 @ 17:11:
Ik weet niet hoe vaak je data wil opsturen, maar denk er ook aan dat iedere byte geld kost. JSON is extreem inefficiënt als het om data gaat, en dus misschien wel niet geschikt.

Verder heb je natuurlijk geen library nodig om JSON te gebruiken op je Uc. Aangezien je alleen dingen op gaat sturen kun je af met simpel string plakken.

Voorheen werd de data in een soort van XML verstuurd (soort van, omdat het simpelweg niet-valide XML was doordat niet alle tags even goed gesloten werden). Wat dat betreft is het JSON een enorme besparing aan data.

In een bericht zitten meerdere locatie waardes (lat, lon, time). Met JSON kun je dat mooi nesten, het formaat lost dat mooi op voor je. Met XML kan dat natuurlijk ook, maar heb je een flinke overhead, met een eigen formaat moet je daar iets op verzinnen en dat verzinnen, uitbreiden en hobby-en wil ik nu juist graag vanaf.

[Verwijderd]

Volgens mij bestaat er geen enkel "high level" protocol wat je kan gebruiken om te communiceren met je atmel. De atmel zal waarschijnlijk via UART bytes uitwisselen met de modem die ze inpakt in een tcp pakketje wat jij dan kan ontvangen.
Aan de kant van de atmel zal het dus waarschijnlijk gaan over strings die verstuurd worden. Alle high level protocols zoals json en xml moeten daar nog bovenop gebouwd worden en zorgen dus voor extra geheugen dat nodig is enz.
Het beste lijkt we toch eens na te denken welke data je wilt versturen en toch zelf een klein protocol-tje uit te dokteren. Op die manier heb je alles zelf in handen is de resulterende overhead minimaal.
Is het eigenlijk nodig dat er ook data vanuit je applicatie terug gestuurd moet worden of stuurt de modem alleen maar die gps info enz. naar jouw webapplicatie?

[Soultaker]

Voor dat we allemaal nieuwe protocollen gaan verzinnen: op zich lijkt de eis van de TS dat er geldige JSON gegenereerd moet worden me gewoon reëel. Dus rijst de vraag: wat wordt er precies verstaan onder “syntaxfouten”?

Het enige wat lastig is bij het genereren van JSON data is het escapen van strings, maar zelfs dat is niet zó ingewikkeld. Lijkt me dat je dat prima zonder extreem veel code te genereren kunt implementeren.

[matthijsln]

Je kan ook kijken naar protobuf-c. Het zal misschien wel wat prutsen zijn om aan de praat te krijgen, alhoewel hier wel wat staat over embedded atmel. Server-side kan je dan gewoon protobuf voor je eigen taal gebruiken.

Protobuf ondersteunt ook repeating dingen. Daarnaast is het ook efficient omdat het een binair protocol is, maar wel portable.

Alhoewel de embedded-programmeur ook wel eens na mag gaan denken als ie na non-wellformed XML ook invalide JSON produceert wat hij wel kan.

[voodooless]

matthijsln schreef op woensdag 09 mei 2012 @ 17:48:
Alhoewel de embedded-programmeur ook wel eens na mag gaan denken als ie na non-wellformed XML ook invalide JSON produceert wat hij wel kan.

What's next Verkeerde GPS coördinaten, foute snelheden, afwijkende temperaturen

Met alle respect, als die gast niet eens een paar regels JSON of XML goed voor elkaar kan krijgen, zou ik de rest ook niet vertrouwen.. Je kunt verzinnen wat je wil, als men zich niet houdt aan hetgeen wat afgesproken is, gaat het nooit werken.

Anyway, naast protocolbuffers kun je ook nog kijken naar BSON, als is proto efficiënter. Merk echter op dat protobuf-c gebruik maakt van malloc, iets dat op de Atmel waarschijnlijk niet aanwezig is. Daar moet je dus nog wel redelijk wat aan klussen.

[ Voor 18% gewijzigd door voodooless op 09-05-2012 17:59 ]

[Hydra]

Soultaker schreef op woensdag 09 mei 2012 @ 17:41:
Voor dat we allemaal nieuwe protocollen gaan verzinnen: op zich lijkt de eis van de TS dat er geldige JSON gegenereerd moet worden me gewoon reëel.

En van de andere programmeur dat er geen libraries zijn ook. Oftewel; gewoon samen ff debuggen wat er mis gaat en klaar. Het is geen rocketscience maar die dude heeft waarschijnlijk gewoon wat over 't hoofd gezien.

[orf]

Verwijderd schreef op woensdag 09 mei 2012 @ 17:35:
[...]
Is het eigenlijk nodig dat er ook data vanuit je applicatie terug gestuurd moet worden of stuurt de modem alleen maar die gps info enz. naar jouw webapplicatie?

Ik stuur alleen HTTP statuscodes terug (bijvoorbeeld 400 Bad request), zodat de data opnieuw opgebouwd en verstuurd kan worden, of het modem weet dat de data is verwerkt.

Soultaker schreef op woensdag 09 mei 2012 @ 17:41:
[..]
Dus rijst de vraag: wat wordt er precies verstaan onder “syntaxfouten”?

Het enige wat lastig is bij het genereren van JSON data is het escapen van strings, maar zelfs dat is niet zó ingewikkeld. Lijkt me dat je dat prima zonder extreem veel code te genereren kunt implementeren.

Dat is zelfs geen issue, er hoeft niets ge-escaped te worden, het zijn alleen maar numerieke values, een datumstring of text (a-z).

matthijsln schreef op woensdag 09 mei 2012 @ 17:48:
Je kan ook kijken naar protobuf-c. Het zal misschien wel wat prutsen zijn om aan de praat te krijgen, alhoewel hier wel wat staat over embedded atmel. Server-side kan je dan gewoon protobuf voor je eigen taal gebruiken.

Protobuf ondersteunt ook repeating dingen. Daarnaast is het ook efficient omdat het een binair protocol is, maar wel portable.

Alhoewel de embedded-programmeur ook wel eens na mag gaan denken als ie na non-wellformed XML ook invalide JSON produceert wat hij wel kan.

Protobuf ziet er best interessant uit. Ik weet niet of ik dit kan voorstellen bij de programmeur. Hij is al flink aan de slag gegaan met JSON en de klant heeft (natuurlijk) een snelle deadline.

De JSON die ik nu kreeg bevatte simpelweg veel typo's. Een quote te veel na een text-value, int's met voorloopnullen, een komma teveel na een array met objecten en een ongeldige (zelfbedachte) key.

Edit:

Hydra schreef op woensdag 09 mei 2012 @ 18:12:
[...]En van de andere programmeur dat er geen libraries zijn ook. Oftewel; gewoon samen ff debuggen wat er mis gaat en klaar. Het is geen rocketscience maar die dude heeft waarschijnlijk gewoon wat over 't hoofd gezien.

Mee eens, uiteindelijk is de webservice mijn pakkie an. Ik moest werken met een niet valide XML, waar tijdens het project allerlei uitbreidingen op kwamen. Daarom heb ik juist voorgesteld om eerst eens vast te stellen wat de standaard is, hoe values geformat moeten zijn, wat verplichte values zijn, etc. Nu zie ik met een nieuw format opnieuw syntax errors voorbij komen en ben ik wat bang voor toekomstige uitbreidingen. Als we de data nu netjes welformed krijgen, dan kan dat best breken op het moment dat er een parameter toegevoegd wordt (en er daarin een typo o.i.d. gemaakt wordt).

[ Voor 17% gewijzigd door orf op 09-05-2012 18:19 ]

[voodooless]

orf schreef op woensdag 09 mei 2012 @ 18:14:Als we de data nu netjes welformed krijgen, dan kan dat best breken op het moment dat er een parameter toegevoegd wordt (en er daarin een typo o.i.d. gemaakt wordt).

Je kunt nog 100 json of xml libraries bekijken, als men niet eens bepaalde dingen goed kan typen, dan houdt het toch gewoon op. Afspraken maak je om je eraan te houden. Een library gaat daar niks aan veranderen.

[sig69]

Precies. Volgens mij ligt het probleem aan de andere kant, laat hem het lekker uitzoeken. Maak desnoods een "debug mode" in je service waarin je elk foutief bericht via email naar die prutser stuurt, is voor hem ook makkelijker "debuggen" denk ik.

[epic007]

Misschien heeft je programmeur hier wat aan: http://jsonlint.com/