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.
:
Gesperrt durch User
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.
Ich hab kuerzlich einen Webserver geschrieben, der hat Seiten abgespult und inline-skripte ausgefuehrt. Ab einem Mega32 mit serieller Anbindung.
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 ?
> 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 ;-)
Also ich hab's schon mal gemacht. Dh einen HTML Server mit AJAX drauf. Das war's dann etwa. Mehr wuerd ich overkill betrachten.
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