Hallo,
ich bin gerade auf der Suche nach einem AVR Ethernet-Modul.
Es gab viele Suchergebnisse bei Google, von allen fand ich das
Webserver-Modul von tuxgraphics.com
(http://shop.tuxgraphics.org/electronic/detail_avrwebserver_smd4.html)
und das Ethernut-Modul (http://www.ethernut.de/en/hardware/index.html)
am besten.
Warum ich hier poste? Ich moechte sicher gehen, dass diese Module auch
wirklich zwei meiner wichtigsten "Anforderungen" erfuellen (soweit ich
der Websites entnehmen konnte, tun sie das, aber bevor ich eines der
Module bestelle, moechte ich es gerne noch mal von euch bestaetigen
lassen):
1. Aufgrund von Zeitgruenden haette ich gerne ein Ready-to-Go-Modul. Das
heisst, ich kann mit wenigen initialisierenden Handgriffen direkt mit
dem Endziel fuer mein Projekt starten, naemlich diverse HTTP-Anfragen zu
machen: Deswegen ist es fuer mich wichtig, dass auf den gelieferten
Modulen schon HTTP und alles was dafuer benoetigt wird schon
implementiert ist. Soweit ich es verstanden habe erfuellen die beiden
Module diese Anforderung. Ist das korrekt?
2. Guter Support: Wie gaengig sind die beiden Module? Wenn ich ne Frage
haben werde, werden sich mehr Leute mit tuxgraphics oder mit Ethernut
auskennen und mir netterweise dazu Tipps geben? Ich glaube eher
Ethernut, oder?
Vielen Dank und einen frohen 2. Weihnachtsfeiertag!
J!M!
Was sind für Dich genau die diversen HTTP-Anfragen?
Sollen nur statische Webseiten geliefert werden oder auch SSI?
Was ist mit der Formularauswertung?
Was ist genau Dein Endziel?
Sorry, meine Kristallkugel ist über Weihnachten beim Polieren.
Hallo!
Naja, ich meine vor allem damit GET-Anfragen an einen Web-Server im
Internet.
SSI nicht, aber PHP durchaus... Macht das einen Unterschied zu rein
statischen HTML-Seiten?
Beste Gruesse, J!M!
PHP auf nem Microcontroller? Das kannst Du vergessen. PHP ist Speicher-
und Ressourcenmäßig ein ziemlich dicker Brocken. Ich glaube noch nicht
mal auf den OpenWRTs (und das ist immerhin nen MIPS mit 16 bis 32 MB RAM
unter Linux) ist PHP mit dabei.
Wenn Du PHP wirklich brauchst, schau Dich am besten nach nem Atom-PC um.
Im AVR-Bereich wirst Du es nicht einfach haben eine Skriptsprache zu
finden. Die Logik hinter der Webseite (also das, was Deine GET-Anfragen
nach nach dynamischen Seiten entgegennimmt) sollte am besten in C
gemacht sein. Evtl. kannst Du das mit Client-Seitiger Logik in
Javascript kombinieren.
anonymous schrieb:
> PHP auf nem Microcontroller? Das kannst Du vergessen. PHP ist Speicher-> und Ressourcenmäßig ein ziemlich dicker Brocken. Ich glaube noch nicht> mal auf den OpenWRTs (und das ist immerhin nen MIPS mit 16 bis 32 MB RAM> unter Linux) ist PHP mit dabei.
So wie ich das verstehe, will er HTML Anfragen abschicken. Von daher
macht es kein Unterschied ob der Server ein PHP Script ausführt oder
nicht.
Aber wo willst du die angefragte HTML Seite denn darstellen? Display?
Oder willst du einfach nur Daten per HTTP PUT schicken?
>Ich glaube noch nicht>mal auf den OpenWRTs (und das ist immerhin nen MIPS mit 16 bis 32 MB RAM>unter Linux) ist PHP mit dabei.>Wenn Du PHP wirklich brauchst, schau Dich am besten nach nem Atom-PC um.
Nee, das läuft unter anderen auch ohne Probleme auf dem NGW100, auch auf
WRTs, hier z.b. http://www.macsat.com/OpenWRT/lighttpd.php
Hallo!
Ja, es ist wie Simon sagt, dass ich nur HTTP-Seiten aufrufen möchte, und
evtl. auch ein paar Daten an einen Web-Server schicken werde, aber nicht
etwa einen Webserver auf dem Ethernet-Modul mit PHP und pipapo laufen
lassen möchte.
Die Darstellung erfolgt auf einem LC-Display, ja.
Ich hoffe, dass ich mehr oder minder nachvollziehbar dargestellt habe,
was ich gerne machen möchte. Erfüllt das Ethernut-Modul (Ethernut 1.3)
diese Anforderung, ohne dass ich noch Vieles an Vorarbeit leisten muss?
J!M!
anonymous schrieb:
> PHP auf nem Microcontroller? Das kannst Du vergessen. PHP ist Speicher-> und Ressourcenmäßig ein ziemlich dicker Brocken. Ich glaube noch nicht> mal auf den OpenWRTs (und das ist immerhin nen MIPS mit 16 bis 32 MB RAM> unter Linux) ist PHP mit dabei.
Doch, ist dabei und funktioniert auch einwandfrei.
Diese Info ist aber hinfällig, da nur ein HTTP-Client benötigt wird,
also lediglich eine TCP-Verbindung öffnen und Daten hin- und
herschicken.
Leider kenne ich o.g. Implementationen nicht, kann mir aber gut
vorstellen, dass das geht. Es könnte aber sein, dass GET und RESPONSE
jeweils in ein TCP-Packet passen müssen. Ich erinnere mich an einen
Stack, der keine größeren Datenmengen übertragen konnte.
Okay, aber dieses Problem lässt sich umgehen ...
Also, ich tendiere jetzt zu Ethernut statt tuxgraphics. Da ich mir auch
ziemlich sicher bin mittlerweile, dass eben HTTP schon implementiert
ist, bin ich auch kurz davor es mir zu bestellen. Nur eine Sache noch
bezüglich evtl. Fragen in der Zukunft: Besitzt jemand schon ein
Ethernut-Modul und hat Erfahrungen damit gemacht/kennt sich damit aus?
J!M!
Ethernut 1.3.
In Euro, so an die 140 €.
Nö, parsen mach ich schon. Aber dass die gelieferte API mir schon
Funktionen bietet wie Verbindung zum Server aufbauen, Anfrage senden,
Antwort entgegennehmen etc.
Ach so. Ja das können eigentlich so gut wie alle. Zumindest eine
Verbindung aufbauen. HTTP Unterstützung braucht man dafür ja eigentlich
nicht. Einfach TCP Verbindung öffnen und die Headerdaten raushauen. Beim
Empfangen dann auf die zwei \r\n warten, danach kommen die Nutzdaten.
Ein großes Problem ist aber immer, dass (mangels Puffer) man keinen
"Stream" an HTTP Daten hat, sondern die Daten immer paketweise
verarbeitet werden müssen. Und da muss man beim parsen halt drauf
achten, dass ein Tag auch über zwei Pakete sich erstrecken kann.
@Simon K.
Nee, das ist nicht bei allen Projekten so das man keinen Stream hat. Ich
selber habe bei meinem Projekt [1] alles komplett entkoppelt, so das man
einen Byteweisen Stream bekommt. Das was auf der Netzwerkschicht
passiert bekommt man nicht zu sehen, darum kümmert sich der Stack. Und
nebenbei zerlegt er einem noch den GET-Request in seine Bestandteile und
hat ein definiertes CGI-BIN Interface wo man alles vorgekaut bekommt und
sich nur noch das raussuchen muss was man braucht.
CA Dirk
[1] http://wiki.neo-guerillaz.de
