www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Webservice auf einem Mikrocontroller


Autor: S. Heuser (sheuser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: S. Heuser (sheuser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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=/i...

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 :)

Autor: Rik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: S. Heuser (sheuser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. :-)

Autor: S. Heuser (sheuser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: 3356 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab kuerzlich einen Webserver geschrieben, der hat Seiten abgespult 
und inline-skripte ausgefuehrt. Ab einem Mega32 mit serieller Anbindung.

Autor: S. Heuser (sheuser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: 3356 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Datenpackete in einer Gebaeudeautomation sind verschluesselt ? 
Interessant. Und der Nutzen davon ? Das Bastler nicht daran rummachen 
koennen ?

Autor: Rik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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 ;-)

Autor: noname (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich hab's schon mal gemacht. Dh einen HTML Server mit AJAX drauf. 
Das war's dann etwa. Mehr wuerd ich overkill betrachten.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MarioT (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stephan Heuser schrieb:
Datum: 03.06.2008 22:26

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.