Hardware Webinterface

[ralphi]

Hallo erst mal,

ich bin ja gespannt ob im Forum auch Microcontroller bewanderte dabei sind. Mich würde es wundern, wenn nicht.

Hat jemand schon ein Webinterface in Hardware (Firmware) programmiert (ähnlich wie bei einem Router)?

Ich möchte gerne einen Datenlogger mit so einem Interface ausstatten.
Die meisten MCU's haben Schnittstellen wie USB, RS232 u.a.
z.B.
http://www.h-tronic.eu/product_info.php?info=p87_8-kanal-usb-datenerfassungs-12-bit---und-steuermodul.html
(hab ich zu Hause) schon mit fertiger Routine.
Bei Lan nehmen die meisten Realtek RTL8019AS (in meinem alten Eusso Router gefunden) oder zB. ENC28J60
http://www.pollin.de/shop/dt/MTQ5OTgxOTk-/Bausaetze_Module/Bausaetze/Bausatz_AVR_NET_IO.html
(möchte ich mir kaufen)
Beide arbeiten mit selbstgebasteltem Handshake zum Datenaustausch mit dem PC, Mac,..

Eine HTML Seite stelle ich mir noch relativ einfach vor. Man sendet einfach das ASCII File über Port 80 an den Browser, der den Rest erledigt - (hab ich noch nicht ausprobiert). Aber was sendet der Browser zurück wenn man was klickt und gibt es einfache Routinen für Microcontroller diese auszuwerten? Alles nur unwissende Vermutungen von mir.

Mit yahoo (google) bin ich zwar auf viele gute Seiten, rund um MCU und FPGA gestoßen:
http://www.mikrocontroller.net
http://www.sprut.de/
aber leider keinen Ansatz für ein Webinterface gefunden. Vielleicht sind die Router alles spezial ASIC's Lösungen.

Kennt jemand Links oder ein 'Kochbuch' für mich?
Lösungvorschläge sollten auf meinem Kenntnisstand aufbauen - Leider sehr alt: Habe mit HC11 und Latice PLD's gearbeitet. Das war die Zeit als Intel und AMD noch an der 100MHz-Hürde knapperten und der Vesa lokal Bus der schnellste war ;)

grüße aus landshut
ralphi

[dedlfix]

Tach!

Eine HTML Seite stelle ich mir noch relativ einfach vor. Man sendet einfach das ASCII File über Port 80 an den Browser, der den Rest erledigt - (hab ich noch nicht ausprobiert). Aber was sendet der Browser zurück wenn man was klickt und gibt es einfache Routinen für Microcontroller diese auszuwerten?

Du möchtest also einen Web-Server bauen. Dazu solltest du dir zunächst HTTP anschauen, das ist das Protokoll zum Kommunizieren zwischen Client und Server. Zudem musst du schauen, wie du in deinem Microcontroller mit dem TCP/IP-Stack arbeiten kannst. Üblicherweise muss man einen Socket zum Lauschen öffnen und ankommende Requests (von denen mehrere parallel kommen können) individuell behandeln.

dedlfix.

[ralphi]

hi dedlfix,

von denen mehrere parallel kommen können) individuell behandeln.

ich denke die meisten Router arbeiten hier mit einer Lightvariante - so ist der Zugriff mehrerer Clients bei meinen Routern gar nicht möglich.

Du hast mich aber auf die Idee gebracht einen Controller mal mit VB6 zu simulieren (also ohne HTTP) - das TCP/IP, socket und Co müsste eigentlich der Netzwerkbaustein, bei dem 'Bausatz_AVR_NET_IO' der ENC28J60 erledigen.

ralphi

[Der Martin]

Hallo,

von denen mehrere parallel kommen können) individuell behandeln.
ich denke die meisten Router arbeiten hier mit einer Lightvariante - so ist der Zugriff mehrerer Clients bei meinen Routern gar nicht möglich.

ich vermute, du bringst hier mehrere logische Schichten durcheinander. Was du meinst, ist vielleicht ein gleichzeitiges Login von mehreren Clients. Mag sein, dass das nicht unterstützt wird - wozu auch?

Aber dennoch muss ein HTTP-Server Requests von beliebigen und beliebig vielen Clients auch "durcheinander" bearbeiten können. Er darf sie zwar in eine Queue stellen und nacheinander bedienen, aber er muss jeden Request beantworten, notfalls mit ein paar Sekunden Reaktionszeit.

Du hast mich aber auf die Idee gebracht einen Controller mal mit VB6 zu simulieren (also ohne HTTP) - das TCP/IP, socket und Co müsste eigentlich der Netzwerkbaustein, bei dem 'Bausatz_AVR_NET_IO' der ENC28J60 erledigen.

Nein. Der kennt nur MAC-Adressen und Ethernet-Datenpakete; der weiß noch nicht mal, was IP überhaupt ist. Der gesamte IP- oder TCP/IP-Protokollstack wird üblicherweise in Software implementiert.
Wobei das heutzutage kaum noch jemand selbst macht; fertige TCP/IP-Implementierungen gibt's für fast jede nur erdenkliche Hardware. Einige davon frei, andere gegen Geld.

Ja, du stehst offensichtlich noch ziemlich am Anfang einer interessanten Reise. Ich will dich nicht davon abhalten, aber bevor du abreist, solltest du dir noch einiges Wissen aneignen. ;-)

Ciao,
 Martin

[ralphi]

Hi Martin,

Nein. Der kennt nur MAC-Adressen und Ethernet-Datenpakete; der weiß noch nicht mal, was IP überhaupt ist. Der gesamte IP- oder TCP/IP-Protokollstack wird üblicherweise in Software implementiert.

bezgl. TCP/IP müsste ich mir eigentlich nur die vorhandene Lösung im
http://www.pollin.de/shop/dt/MTQ5OTgxOTk-/Bausaetze_Module/Bausaetze/Bausatz_AVR_NET_IO.html
ansehen. Die klappt ja.

Was das HTTP (LIGHT :) angeht, hab ich mit VB6 mal gespielt. Der Browser quatscht schon mit mir ;)

In VB6 - Port 80
Winsock1.Accept requestID
x = "<HTML><HEAD><\HEAD><BODY>Hello World<\BODY><\HTML>"
Winsock1.SendData x

Bekommen tu ich:

GET / HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Accept-Language: de-DE
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
UA-CPU: AMD64
Accept-Encoding: gzip, deflate
Host: 192.168.123.10
Connection: Keep-Alive
' und crlf

der browser wartet auf serverantwort

wenn ich die Verbindung bei vb abbreche, schreibt der browser:
<\HEAD>Hello World<\BODY><\HTML>

ralphi

[dedlfix]

Tach!

Was das HTTP (LIGHT :) angeht, hab ich mit VB6 mal gespielt. Der Browser quatscht schon mit mir ;)

In VB6 - Port 80
Winsock1.Accept requestID
x = "<HTML><HEAD><\HEAD><BODY>Hello World<\BODY><\HTML>"
Winsock1.SendData x

Das ist kein HTTP, noch nicht mal light. Das ist nur HTML.

dedlfix.

[Der Martin]

Hi,

In VB6 - Port 80
Winsock1.Accept requestID
x = "<HTML><HEAD><\HEAD><BODY>Hello World<\BODY><\HTML>"
Winsock1.SendData x

Das ist kein HTTP, noch nicht mal light.

yo, *mindestens* einen HTTP-Status-Header sollte man dem Client schon anbieten.

Das ist nur HTML.

Auch das nicht - HTML verwendet keine Backslashes für schließende Tags. Und die Großschreibung tut in den Augen weh.

Ciao,
 Martin

[ralphi]

Auch das nicht - HTML verwendet keine Backslashes für schließende Tags. Und die Großschreibung tut in den Augen weh.

ihr habt ja recht - das ist sehr unhöfflich gegenüber dem Browser - sobald ich das richtige handshake zwischen browser und server gefunden habe - werde ich es einbauen und weiteres ausprobieren. eine idee wo es am einfachsten beschrieben ist?

ABER: umsomehr müsste es euch verwundern, dass wenn man die slashes richtig schreibt und den socket schließt, das dann Hello world da steht!! :)
der quelltext im browser ist: <HTML><HEAD></HEAD><BODY>Hello World</BODY></HTML> - korrekt

ralphi

[Der Martin]

Hi,

ABER: umsomehr müsste es euch verwundern, dass wenn man die slashes richtig schreibt und den socket schließt, das dann Hello world da steht!! :)

es wundert mich tatsächlich, denn per definitionem (HTTP-Spezifikation) fängt eine gültige HTTP-Response mit den Response-Headerzeilen an, von denen zumindest der Status Pflicht ist, und erst nach einer Leerzeile beginnt der eigentliche Nutzinhalt.

der quelltext im browser ist: <HTML><HEAD></HEAD><BODY>Hello World</BODY></HTML> - korrekt

Vermutlich ein Effekt der browser-internen Fehlertoleranz: Er erkennt, dass die erste (und einzige) empfangene Zeile kein gültiger HTTP-Header ist, und geht dann davon aus, dass es sich da wohl schon um den Nutzinhalt handelt.

Wenn du die Antwort deines Servers mit

HTTP/1.0 200 OK

gefolgt von einer Leerzeile beginnen lässt, und dann erst deinen bisherigen Nutzinhalt folgen lässt, hast du immerhin eine korrekte Minimal-Response. Damit sagst du außerdem gleich dem Browser, der ja in HTTP/1.1 angefragt hat, dass du kein 1.1 "sprechen" willst, sondern nur HTTP/1.0 (denn für HTTP/1.1 müsste der Server eine Menge Raffinessen zusätzlich beherrschen).

So long,
 Martin

[ralphi]

Wenn du die Antwort deines Servers mit

HTTP/1.0 200 OK

gefolgt von einer Leerzeile beginnen lässt, und dann erst deinen bisherigen Nutzinhalt folgen lässt,

hmm - hab ich ausprobiert. es kommt keine antwort, darstellen tut er auch nichts mehr.
eine meldung kommt bislang eh nur beim accept

vielleicht hab ich ja mit den zeilen  HTTP/1.0 200 OK + leerzeile den wunsch einer wirklich korrekten komunikation geweckt?! egal ob ich es direkt hintereinander oder zeitversetzt es kommt kein hello world mehr.

ralphi

[dedlfix]

Tach!

Wenn du die Antwort deines Servers mit
HTTP/1.0 200 OK
gefolgt von einer Leerzeile beginnen lässt, und dann erst deinen bisherigen Nutzinhalt folgen lässt,
hmm - hab ich ausprobiert. es kommt keine antwort, darstellen tut er auch nichts mehr.

"gefolgt von einer Leerzeile" heißt, dass die letzte Header-Zeile von einem Zeilenumbruch beendet wird, danach noch einer kommt und nun erst der Content. Und außerdem brichst du dir keinen Zacken ab, wenn du gleich noch einen Content-Type-Header mitsendest, dann muss der Browser nicht raten, was er da bekommt.

vielleicht hab ich ja mit den zeilen  HTTP/1.0 200 OK + leerzeile den wunsch einer wirklich korrekten komunikation geweckt?! egal ob ich es direkt hintereinander oder zeitversetzt es kommt kein hello world mehr.

Du musst nicht die beiden RFCs für HTTP auswendig lernen. Aber wenigstens die elementaren Grundlagen davon solltest du nachlesen, zum Beispiel in der Wikipedia.

dedlfix.

[dedlfix]

Tach!

ABER: umsomehr müsste es euch verwundern, dass wenn man die slashes richtig schreibt und den socket schließt, das dann Hello world da steht!! :)

Nicht wirklich.

es wundert mich tatsächlich, denn per definitionem (HTTP-Spezifikation) fängt eine gültige HTTP-Response mit den Response-Headerzeilen an, von denen zumindest der Status Pflicht ist, und erst nach einer Leerzeile beginnt der eigentliche Nutzinhalt.

Laut RFC1945 für HTTP/1.0 gibt es auch eine Simple Response. Allerdings sollte diese nur auf einen HTTP/0.9-Simple-Request gesendet werden. Da das vermutlich kein Browser heutzutage mehr macht, ist die Simple-Response damit nicht zulässig. In RFC2616 für HTTP/1.1 ist diese Möglichkeit gar nicht mehr erwähnt.

dedlfix.

[Der Martin]

Hallo,

Laut RFC1945 für HTTP/1.0 gibt es auch eine Simple Response. Allerdings sollte diese nur auf einen HTTP/0.9-Simple-Request gesendet werden.

hoppla, diesen Absatz habe ich doch glatt überlesen. Und nicht gewusst, dass es diese Form von Simple Request/Simple Response gibt bzw. mal gegeben hat.

Da das vermutlich kein Browser heutzutage mehr macht, ist die Simple-Response damit nicht zulässig. In RFC2616 für HTTP/1.1 ist diese Möglichkeit gar nicht mehr erwähnt.

Gut so. :-)

Ciao,
 Martin

[unknown]

Hat jemand schon ein Webinterface in Hardware (Firmware) programmiert (ähnlich wie bei einem Router)?

Vor vielen Jahren hatte ich mal uIP auf einer selbstgebastelten Platine mit einem 8051 laufen gehabt.

Bei Lan nehmen die meisten Realtek RTL8019AS (in meinem alten Eusso Router gefunden) oder zB. ENC28J60

Das hätte ich auch gerne untergebracht, hab ich mir allerdings nicht mehr zugetraut per Hand zu löten. Der Chip war schon bestellt und liegt noch immer in einer Kiste. Ich habs dann über SLIP per RS323 laufen lassen, allerdings fehlte dann der serielle Port für Debugausgaben. Die hab ich dann über IO-Pins des µC auf die parallele Schnittstelle des Druckers ausgegeben, mit nem angepassten Treiber für WinXP (oder Win2000?).

Vor nicht allzulanger Zeit hab ich das ganze dann auch noch auf dem at90USBKey über LUFA als RNDIS zum Laufen bekommen.

aber leider keinen Ansatz für ein Webinterface gefunden. Vielleicht sind die Router alles spezial ASIC's Lösungen.

Für viele Router kannst du irgendein openWRT

[Der Martin]

Hallo,

Bei Lan nehmen die meisten Realtek RTL8019AS (in meinem alten Eusso Router gefunden) oder zB. ENC28J60
Das hätte ich auch gerne untergebracht, hab ich mir allerdings nicht mehr zugetraut per Hand zu löten.

warum nicht? - Gut, SMD-Bauteile erfordern einen feinen Lötkolben, feines Lot und eine ruhige Hand. Und natürlich etwas Übung. Man sollte vielleicht nicht die ersten Versuche mit Fine-Pitch-Bauteilen machen. Anfangs hatte ich da auch ziemlichen Respekt, aber mittlerweile schrecken mich SOIC mit 1.27mm Pitch oder TQFP mit 1.0mm nicht mehr ab.

aber leider keinen Ansatz für ein Webinterface gefunden. Vielleicht sind die Router alles spezial ASIC's Lösungen.

Nein. Die meisten Router im Consumer-Bereich basieren zwar auf irgendwelchen RISC-CPUs, aber sie werden herstellerseitig "ganz normal" programmiert. Für manche Produktreihen sind ja sogar schon alternative Firmware-Lösungen im Umlauf, wie etwa Freetz für die AVM-Router.

Für viele Router kannst du irgendein openWRT

... verwenden, wolltest du sagen. ;-)
Zumindest könnte das ein sehr interessanter Startpunkt sein.

Ciao,
 Martin

[unknown]

warum nicht? - Gut, SMD-Bauteile erfordern einen feinen Lötkolben, feines Lot und eine ruhige Hand. Und natürlich etwas Übung. Man sollte vielleicht nicht die ersten Versuche mit Fine-Pitch-Bauteilen machen. Anfangs hatte ich da auch ziemlichen Respekt, aber mittlerweile schrecken mich SOIC mit 1.27mm Pitch oder TQFP mit 1.0mm nicht mehr ab.

Das ist nichts mehr für mich, seit die ganzen interessanten Bauteile kaum noch als 2,54 DIP zu haben sind, hab ich die Hardwarebastelei aufgegeben.

Für viele Router kannst du irgendein openWRT

... verwenden, wolltest du sagen. ;-)

Ja, da waren die Finger wieder langsammer als der Kopf.

Zumindest könnte das ein sehr interessanter Startpunkt sein.

Bei mir läuft ein Edimax mit MIDGE als Miniserver und ein ASUS WL 500g Premium mit dd-WRT als Bridge