Hi,
hat jemand schonmal probiert, einen Webservice auf einem Mikrocontroller
laufen zu lassen? Also komplett mit XML-RPC oder SOAP und evtl. sogar
Registrierung beim Broker... als Hardware wollte ich einen Atmega 644
auf dem Board von Ullrich Radig verwenden.
Ist das Overkill oder machbar, und auch halbwegs flott?
Zum Hintergrund: ich will die I/O Pins des Atmegas über das Netzwerk
steuern. Letztendlich soll es darauf hinauslaufen, das ich
beispielsweise alle Lampen im Zimmer vom Rechner aus der Ferne schalten
kann. Um das ganze dynamisch erweitern zu können bräuchte ich nen
Webservice auf jedem Atmega. So nach dem Motto ich hänge einen zweiten
Atmega in das Netzwerk, der irgendwas steuert, und der meldet dann
selbstständig den Webservice zum Steuern beim Broker an. Der Broker
selbst läuft auf einem Via Epia Board. Der Broker wiederrum generiert
aus der WSDL die GUI (mittels SWT oder wiederrum einem Webserver) zum
schalten, das ganze passiert in Java.
SOAP wird etwas haarig, wegen dem nötigen XML-Parser incl. XML-Namespace
Support...
Evtl kann man etwas tricksen, und statt nem XML-Parser ne handvoll
Regexp verwenden... Schön ist das dann aber nichtmehr.
Ich würd eher ein kleines eigenes Protokoll für die einzelnen Devices
nehmen, und die Umsetzung auf einen Webservice zentral machen.
Registrierung neuer Devices könnte man am DHCP-Server abziehen, wenn die
sich dort eine IP holen.
Hallo,
die Idee ist nachvollziehbar. Ist natuerlich totaler Overkill um ein
paar Lampen zu steuern, quasi mit Wasserstoffbomben auf Spatzen
geschossen, aber einen Aspekt finde ich interessant: Ist es moeglich
(bzw. gibt es das schon?) einen Xml-Parser auf einem AVR zu
implementieren. Also: Na klar, wenn man genug RAM dran haengt und
Rechenzeit egal ist, dann natuerlich. Aber ich meinte eine brauchbare
Loesung. Stephan, wenn du dich sowieso gerade mit dem Thema befasst,
dann untersuch das doch mal. Wuerde mich wirklich interessieren.
Gruss!
Rik
Einen DOM-Parser kann man wohl vergessen, wg. der nötigen dynamischen
Speicherverwaltung.
Ein abgespeckter SAX-Parser könnte jedoch passen, hätte auch den Vorteil
dass man nie das gesamte Dokument im Ram braucht, weder den Source noch
den Parse-Tree. Man könnte also Stückchenweise, wie die TCP-Pakete
kommen, parsen.
Auswertung dann über State-Machine an den SAX-Callbacks, die sich die
nötigen Werte in Variablen rauszieht...
Ja, für ein paar Lampen schalten ist ein XML Webservice definitiv
absoluter Overkill. Hierfür würde ich eher vorschlagen ein eigenes
Protokoll basierend auf UDP zu verwenden und auf dem Mikrocontroller
einen UDP-Server laufen zu lassen, der die empfangenen Daten analysiert
und dementsprechend die Ausgänge schaltet. Alternativ kann man das aber
auch per HTTP-POST machen.
Bei meinem Webserver:
Beitrag "ENC28J60 (Mikro-)Web-Server die Nächste"
wird beim Klick auf den Absenden Button der Beispielapplikation ein
HTTP-POST Request vom Browser losgeschickt der die Ausgänge setzt. Sowas
lässt sich auch sehr leicht mit curl (Kommandozeile) machen.
http://curl.haxx.se/
Mir ist klar das es für ein paar Lämpchen übertrieben ist... es geht
darum, eine Proof-of-Concept Implementierung zu bauen. Es soll also
wirklich ein Webservice laufen, alles andere wäre zu trivial...
Ich hab ein Paper gefunden zu dem Thema, aber hier gehts (nur) um SOAP:
http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/9203/29178/01316691.pdf?arnumber=1316691
sobald ich durch bin werde ich mal eine Zusammenfassung posten.
@Ernst: Ich stimme zu, ein SAX Parser sollte machbar sein.
@Simon: Ich werd mir deinen Webserver mal genauer anschaun, grade das
uip bei dir läuft gefällt mir :)
> es geht darum, eine Proof-of-Concept Implementierung zu bauen
Pioniergeist finde ich gut!
Wenn du das mit einem AVR hinbekommst, dann ziehe ich meine saemtlichen
Huete vor dir :-) Mit etwas groesseren Mikrocontrollern (waren glaube
ich 16-Bitter von Fujitsu) hab ich soetwas schonmal in einer
Dissertation gesehen.
Rik wrote:
>> es geht darum, eine Proof-of-Concept Implementierung zu bauen>> Pioniergeist finde ich gut!>> Wenn du das mit einem AVR hinbekommst, dann ziehe ich meine saemtlichen> Huete vor dir :-) Mit etwas groesseren Mikrocontrollern (waren glaube> ich 16-Bitter von Fujitsu) hab ich soetwas schonmal in einer> Dissertation gesehen.
Hast du die Dissertation zufällig noch irgendwo? Bisher habe ich nur mit
den Atmegas gearbeitet, aber das wäre schonmal ein Anfang.
Stephan Heuser wrote:
> Mir ist klar das es für ein paar Lämpchen übertrieben ist... es geht> darum, eine Proof-of-Concept Implementierung zu bauen. Es soll also> wirklich ein Webservice laufen, alles andere wäre zu trivial...
Sag das doch gleich! Würde mich auch mal interessieren ob so etwas mit
dem AVR möglich ist. :-)
Ich hab jetzt zwei Papers überflogen, die beide der Meinung sind, es
wäre so nicht sinnvoll.
Beide argumentieren mit der Komplexität. Die einen schlagen ein Gateway
vor, das zischen SOAP und beispielsweise CAN Bus übersetzt. Die
Mikrocontroller kommen dann an den CAN Bus.
Die anderen definieren ein XML-Unterformat und parsen das mit Regular
Expressions. Letztendlich steht wieder irgendwo ein Rechner, der die
WSDL entsprechend erzeugt und die Registrierung am Broker für den
Mikrocontroller vornimmt.
Edit: XML parsen mit Regular Expressions:
http://www.cs.sfu.ca/~cameron/REX.html
Hi!
Ich finde den Titel der Arbeit leider nicht mehr. :-/
Zur Frage der *Sinnhaftigkeit*: Es ist doch wohl eher eine Frage der
Zeit, bis die Geraete, die heute noch ueber alle moeglichen
verschiedenen Kommunikationssysteme verbunden sind, sich alle ins Web
eingliedern werden. Die Protokolle der Computernetze finden immer
weiteren Einzg in kleine Mikrocontrollersysteme. Das sieht man doch
schon hier im Forum: Mit einem 8-Bitter und einem einzigen weiteren
hochintegrierten IC kann sich jeder seinen eigenen Webserver basteln.
Guck mal in die Industrie: Werkzeugmaschinen und Roboter haben schon
alle LAN und falls es die Umgebung irgendwie zulaesst sogar WLAN
(Siemens bietet ihr "industrielles WLAN" jetzt sogar mit
Verschluesselung an g )
Wegen "Verwendung von XML-Untermengen": Meiner Meinung nach ein fauler
Kompromiss. Der Sinn von Standards ist, dass jeder mit jedem kann. So
braucht man dann doch wieder einen Protokolluebersetzer dazwischen.
Rik wrote:
> Zur Frage der *Sinnhaftigkeit*: Es ist doch wohl eher eine Frage der> Zeit, bis die Geraete, die heute noch ueber alle moeglichen> verschiedenen Kommunikationssysteme verbunden sind, sich alle ins Web> eingliedern werden. Die Protokolle der Computernetze finden immer> weiteren Einzg in kleine Mikrocontrollersysteme. Das sieht man doch> schon hier im Forum: Mit einem 8-Bitter und einem einzigen weiteren> hochintegrierten IC kann sich jeder seinen eigenen Webserver basteln.> Guck mal in die Industrie: Werkzeugmaschinen und Roboter haben schon> alle LAN und falls es die Umgebung irgendwie zulaesst sogar WLAN> (Siemens bietet ihr "industrielles WLAN" jetzt sogar mit> Verschluesselung an g )
Ich stimme voll zu.
>> Wegen "Verwendung von XML-Untermengen": Meiner Meinung nach ein fauler> Kompromiss. Der Sinn von Standards ist, dass jeder mit jedem kann. So> braucht man dann doch wieder einen Protokolluebersetzer dazwischen.
Die Frage ist letztendlich, ob es machbar ist und schnell genug auf
einem "kleinen" Atmega laufen wird. Spätestens wenn die Kommunikation
gesichert werden soll kommt man eh an die Grenzen denke ich. Insofern
würde ich als Selbstbastel-Insellösung, die dann auch auf einem Atmega
laufen soll fast, zu der abgespeckten-XML Variante tendieren. Ein
Rechner läuft eh als Broker, der könnte dann auch die Registrierung der
Nodes übernehmen. Und die Kommunikation per SOAP würde dann nach außen
auch korrekt funktionieren, da die Requests und Replies ja SOAP
entsprechen.
Wenn man an das große Ganze denkt ist das natürlich nicht so richtig
top.
>Die Frage ist letztendlich, ob es machbar ist und schnell genug auf
einem "kleinen" Atmega laufen wird. Spätestens wenn die Kommunikation
gesichert werden soll kommt man eh an die Grenzen denke ich.
Ja das stimmt. Ich habe einen Webserver fuer Steuerungsaufgaben in der
Gebauedeautomation mit einem ATmega32 gebaut. Dazu habe ich auch ein
kryptographisches Protokoll entworfen und implementiert. Das Protokoll
verwendet den Data Encryption Standard. Fuer kurze Befehlssequenzen von
einigen Bytes reicht der Durchsatz von Verschluesselung und
Protokollhandshakes gerade noch so. Aber wenn ich mir vorstelle, dass
der AVR "nebenbei" noch eine XML-Datei in einen Baum parsen soll
(fehlendes RAM einmal ignoriert)... Fuer solche Aufgaben sind, um bei
Atmel zu bleiben, wohl AT91SAM7XC512'er besser geeignet.
> Die Datenpackete in einer Gebaeudeautomation sind verschluesselt ?
Interessant. Und der Nutzen davon ? Das Bastler nicht daran rummachen
koennen ?
Naja, "Bastler" im weitesten Sinne. Mein System verwendet als
Kommunikationssystem die in einem Gebaeude bereits vorhandene
LAN-Infrastruktur. "Gebaeude" sind dabei nicht nur Wohn- sondern auch
Nutzbauten. Du hast also ein Netzwerk mit potentiell einigen hundert
Usern, die alle mit einem PC im selben Netz haengen wie das
Automationssystem. Die Versuchung beim verhassten Kollegen im Buero
nebenan die Klimaanlage voll aufzudrehen ist da gross ;-)
Stephan Heuser schrieb:> Ist das Overkill oder machbar, und auch halbwegs flott?
Prinzipiell ist das auch nicht "schwieriger" als eine HTML Seite
auszuliefern, solange du auf alzu strickte Prüfungen und ein einfaches
Dokumentenmodell setzt ist der Parser auch nicht weiter tragisch.
Stephan Heuser schrieb:> Ich hab jetzt zwei Papers überflogen, die beide der Meinung sind, es> wäre so nicht sinnvoll.>> Beide argumentieren mit der Komplexität. Die einen schlagen ein Gateway> vor, das zischen SOAP und beispielsweise CAN Bus übersetzt. Die> Mikrocontroller kommen dann an den CAN Bus.>> Die anderen definieren ein XML-Unterformat und parsen das mit Regular> Expressions. Letztendlich steht wieder irgendwo ein Rechner, der die> WSDL entsprechend erzeugt und die Registrierung am Broker für den> Mikrocontroller vornimmt.
Von den Kosten her ist es fast egal, ob Du Dich auf einem Mega644
abmühst oder zwei Nummern größer beispielsweise auf einem PIC32MX695
einsteigst. Ein Mgea644p kostet bei Farnell 8.32€, ein PIC32MX695H
kostet 11.32€ und ist um Zehnerpotenzen leistungsfähiger.
Also: Was soll der Geiz?
fchk
Thread beobachten
Seitenaufteilung abschalten