Hallo Community, ich Plane einen Webserver auf dem STM32F107 aufzusetzen, bin jedoch ein wenig davon überrascht, dass es weder von ST noch auf sonstigen Seiten Examples hierzu gibt. Für die F2 Serie gibt es das sehr wohl. Daher wollte ich mal eure Meinung dazu hören. Ist der F1 vielleicht doch ein bisschen zu schmalbrüstig ? (Das ganze ist ohne RTOS geplant) Das es für den F2 funktionieren sollte ist in AN3384 beschrieben. Grüße Mathias
Wozu Examples? Entweder macht man es selbst, oder lässt es ganz sein. Man wartet, dass eine Anfrage kommt und schickt dann die richtigen Daten zurück. Was ist so kompliziert daran? Ich habe auch schon Webserver-Code auf 8Bit Atmels gesehen https://www.arduino.cc/en/Tutorial/WebServer Das sind 30 Zeilen Code. Dann sollte ein STM das wohl auch schaffen?
Es kommt ganz drauf an, was für Webseiten du damit erzeugen willst und welche Performance nötig ist. Es gibt zahlreiche Webserver Projekte auf Basis eines ATmega (mit 16 oder 20Mhz) und das kann man ohne gräßliche Verrenkungen ab 32kB Flash und 4kB RAM machen. Für ein Bedienfeld einer Maschine, wo man ein mpaar Knöpfe drücken kann und ein paar Parameter einstellt reicht das locker aus. Falls du allerdings vor hast, Musik zu Streamen, wird's mit dem ATmega schon eng. Dem STM32F1 würde ich es schon eher zutrauen. Für Video reicht der jedoch auch nicht. Schau Dir den µIP oder den lwIP Stack von Adam Dunkels an. µIP kommt mit weniger RAM aus, ist dafür allerdings im Zusammenspiel mit Windows bei TCP langsamer. Oder du verwendest ein Netzwerk-Interface, dass bereits einen IP Stack integriert hat, die findest du unter anderem bei Wiznet und dann gibt natürlich noch die ESP8266 basierten Module. Die Firmware des ESP8266 kannst du übrigens mit Arduino selbst erweitern, dann brauchst du eventuell gar keinen STM. Der hat typischerweise 4 Megabtye Flash speicher. Siehe: http://stefanfrings.de/esp8266/index.html
Danke euch zwei für die schnelle Rückmeldung. Ich schaue mir die genannten Projekte mal an. @PittyJ Das komplizierte daran ist, dass der Controller -was ich aber im ersten Post nicht genannt habe- parallel im I2C Master-Slave Verbund verschiedene Steueraufgaben möglichst ohne Latenzzeit übernehmen soll. Aber sei diese Anforderung erst einmal dahingestellt. Ich muss mich mit den genannten Projekten eh erst wieder auf Stand bringen. Danke :)
Also. Was muss so ein Webserver in diesem Fall tun ?
1) eine GET Anfrage parsen, zB
GET /index.html?mycommand=17&mypara1=11&mypara2=24
nach : mycommand=17
mypara1=11
mypara2=24
2) mach das, was auch immer es bedeutet
3) der Client will die /index.html Seite haben, also sende diese Seite
zurueck
Um caching zu vermeiden, sollte man die angeforderte Seite eher
/index.php nennen.
@Stefanus hat mit mit lwIP auf die -für mich- richtige Fährte gebracht. ST bietet ein Application Note an, welches als Beispiel für einen Webserver mit dem STM32F107 genutzt werden kann. AN3102. Somit bin ich erst einmal mit Arbeit eingedeckt und werde mir die Performance und Funktionsfähigkeit mal anschauen. Danke !
Maze Z. schrieb: > @Stefanus hat mit mit lwIP auf die -für mich- richtige Fährte gebracht. Jaaa... Stefanus ist in Sachen STM32F1 für mich die erste Anlaufstelle - weil auf seiner HP die drei wichtigsten Datenblätter immer so schön schnell erreichbar sind ^^ Gerade wenn man unterwegs ist, ist er immer so die Rettung für mich eh ich mich im ST-Web-Dschungel durchwühle :-D
Schau mal bei Olimex. Die Haben ein Demoboard mit STM32F107 und Ethernet. Schaltplan und Code kann man runterladen.
PittyJ schrieb: > Wozu Examples? Entweder macht man es selbst, oder lässt es ganz sein. > Man wartet, dass eine Anfrage kommt und schickt dann die richtigen Daten > zurück. Was ist so kompliziert daran? > > Ich habe auch schon Webserver-Code auf 8Bit Atmels gesehen > https://www.arduino.cc/en/Tutorial/WebServer > Das sind 30 Zeilen Code. > Dann sollte ein STM das wohl auch schaffen? Naja, ganz so einfach ist es nur in den allersimpelsten Fällen, die in der Praxis sehr schnell nicht mehr praktisch sind... hier ein paar teaser für Dinge, die in den "schnellen Beispielcodes" in der Regel nicht berücksichtigt werden: 1. Ein (virtuelles oder physikalisch unterbautes) Filesystem sollte auf jeden Fall dazu gehören, was u.A. auf den footprint geht. Hardcodierte HTML templates rauben nicht nur Platz im Flash, sondern sind auch nur sehr umständlich erweiterbar. 2. Session Management (im rudimentärsten Fall cookies) gehört in jedem Fall dazu, da per Definition erstmal jeder HTML request komplett autark und zustandsfrei ist, d.h. spätestens in dem Moment, wo Jemand von einem Fenster in ein Anderes klicken will, muss der Server in irgendeiner Form wissen, dass dies nicht ein zweiter Benutzer ist, der von woanders erwartet, auf die Hauptseite zurückzukommen 3. In der Regel werden aus Footprintgründen Webserver als sequentielle Server implementiert, d.h. ein thread (Prozess) wartet auf eine Verbindung, parst den request, verarbeitet und beantwortet ihn und geht wieder ins Warten zurück. "Richtige" Webserver setzen für jeden request einen neuen thread/Prozess ab, um die responsiveness auch für mehrfache Zugriffe zu garantieren (oder machen es noch Anders, aber das führt zu weit). Korollar ist, dass in der "einfachen" Architektur die Abarbeitung eines requests im kritischen Pfad ist, wie schnell der Browser auf weitere requests eine Antwort kriegt. Das ist für Leute, die einen Browser gegen einen "richtigen" Webserver benutzen, zunächst mal gewöhnungsbedürftig. 4. Die "Jeder Version jedes Browsers hat Andere bugs" Falle schlägt auch hier zu, d.h. wer seinen Webserver nur gegen Mozilla 52 testet, darf damit rechnen, von Nutzern von Mozilla 4x, Opera jede Version, IE jede Version und Chrome jede Version andere eigentümliche Verhaltensweisen berichtet zu bekommen. 5. Die Erreichbarkeit des Servers in jedem WAN ist wie bei allen Webservern ohne statische IP Adresse nicht garantiert. Wenn dein Server z.B. DHCP client ist, brauchst Du (soweit deine Netzwerkinfrastruktur eine DNS/DHCP Brücke nicht bereits von Haus aus unterstützt) so etwas wie DynDNS, was Zusatzsoftware erfordert, um dein Gerät mit DNS Namen synchronisieren zu können. Oder Autodiscoveryprotokolle im lokalen Segment. 6. Vom Thema "Sicherheit" brauchen wir hier nicht mal anfangen zu schreiben... Also die Vorstellung "ich schreibe mal eben etwas Code zusammen und kann dann das Gerät im Web wie jeden Server mit demselben Komfort erreichen" ist nicht Realität. Kleine Webserver gibt es auf vielen Embedded Geräten, sie lassen sich auch (bei nicht allzu grossen Anforderungen an den UI Komfort) einigermassen ressourcenarm programmieren, aber das Hauptanwendungsgebiet dabei ist, in einem geschlossenen Netz mit statisch vorgegebener Infrastruktur zu arbeiten (Beispiel: Ein Techniker schliesst seinen laptop direkt peer-to-peer am Gerät an und hat mit einer hardcodierten IP Adresse ein rudimentäres graphisches Serviceinterface). Fast alle Web Server Beispiele in öffentlichen Codebasen sind so rudimentär, dass ein recht grosser Aufwand nötig ist, etwas praktikables draus zu machen.
:
Bearbeitet durch User
Gute Hinweise, nur einen Punkt möchte ich ergänzen:
> "Richtige" Webserver setzen für jeden request einen neuen thread/Prozess ab
Sowohl unter Linux als auch unter Windows gilt das Starten eines Threads
als teure Operation, weswegen Threads in Pools vorgehalten und wieder
verwendet werden.
Mikro-Webserver, die nur in einem Thread arbeiten sind problematisch. Da
kann man mit einer einzigen hängenden Verbindung die Erreichbarkeit des
ganzen Services verhindern. Außerdem läuft der Puffer des Ethernet
COntrollers schnell über, wenn man sie sequentiell abarbeitet.
Multi-Threading wird da ganz schnell sinvoll.
Auf jeden Fall gehören Webserver auf Mikrocontroller definitiv nicht ins
öffentliche Netz. Sie wären hochgradig unsicher - was ja auch z.B. bei
Heise jede Woche moniert wird.
Stefan U. schrieb: > Auf jeden Fall gehören Webserver auf Mikrocontroller definitiv nicht ins > öffentliche Netz. Sie wären hochgradig unsicher - was ja auch z.B. bei > Heise jede Woche moniert wird. Wie kommst du zu dieser Aussage? Ich glaube du verwechselst das mit embedded Linux systemen. Einen Mikrocontroller kann man mit einer MMU (wenn vorhanden) sehr gut gegen eine Übernahme abschotten. Ein STM32f4 Webserver wäre somit sicherer als die meistens anderen Systeme. Man kann ihn vielleicht zum Absturz bringen, aber keinen Code aus dem RAM ausführen.
Ich muss mich korrigieren, der f4 hat nur eine MPU, erfüllt aber den gleichen Zweck.
avr schrieb: > Wie kommst du zu dieser Aussage? Auf einem AVR oder STM32 bekommst du so ohne weiteres kein gebrauchbares TLS hin, also sind die Daten schonmal unverschlüsselt erreichbar. Damit ist jede Form von Authentifizierung unverschlüsselt, kann also für Angreifer als bekannt vorausgesetzt werden, bzw. ist nutzlos. Damit kann ein Angreifer jederzeit alle Daten abgreifen und auch Befehle auslösen. Heizung steuern, Garage aufmachen, Licht an- und ausmachen. "Unsicher" heißt mehr als "Remote Code Execution für Spamschleuder und DDoS".
S. R. schrieb: > avr schrieb: >> Wie kommst du zu dieser Aussage? > > Auf einem AVR oder STM32 bekommst du so ohne weiteres kein gebrauchbares > TLS hin, also sind die Daten schonmal unverschlüsselt erreichbar. das TLS kann man ja am proxy machen der auch direkt von außen erreichbar ist, so hat man dann auch nicht das gehampel mit unterschiedlichen ports für unterschiedliche Dienste sondern kann das über andere Hostnamen oder Pfade abbilden.
Ich habe in übrigens in manchen Kundeninstallationen schon gesehen, dass Raspberry Pis o.Ä. die gesamte Kommunikation übernehmen (also den Webserver mit bestehender Infrastruktur und SW realisieren) und mit dem "richtigen" Controller über ein proprietäres peer-to-peer Interface Daten austauschen. Mit so einer Lösung bleiben einem die blutigen Details der Kommunikationsentwicklung zum großen Teil erspart.
Dirk D. schrieb: > das TLS kann man ja am proxy machen der auch direkt von außen erreichbar > ist, Was bedeutet, dass der Mikrocontroller eben nicht mehr direkt über das Internet erreichbar ist. QED. Ruediger A. schrieb: > [Raspberry als Bridge] Ja, das geht natürlich auch. Der RPi ist hinreichend dick und standardisiert für gewöhnliche Serversoftware, die man dann absichert. Den Controller selbst kann irgendwie anders ansteuern, ohne Sicherheitsanforderungen. Aber dann kann man sich den Webserver auf dem Controller gleich mit sparen und ein simples Befehlsprotokoll über UART, SPI o.ä. nutzen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.