Normalerweise nutze ich eine serielle Verbindung und Python oder Java zur Darstellung von Signalen aus dem Mikrocontroller.
Ich überlege, ob eine Web GUI nicht sinnvoller wäre, weil die Browser mit relativ hoher Geschwindigkeit rendern und das rein- und raus Zoomen mit dem Scrollrad der Maus recht praktisch ist.
Es gibt verschieden Alternativen, wie man die Datenübertragung realisieren könnte:
Einen Mikrocontroller mit WLAN wie z.B. PiPico W
-- WLAN störanfällig
-- Datenübertragung bisweilen hackelig
-- Compilierung langsam
++ Web GUI vollständig im Mikrocontroller
Serial-TCP-Bridge auf PC
-- Datenrate gebremst durch serielle Schnittstelle
++ zuverlässig
Mit einer nativen USB-Verbindung (ohne Umwandlung auf Serial) bekommst du eine schnelle, stabile Verbindung und kannst in einer beliebigen Programmiersprache für den PC eine Anwendung zur effizienten Darstellung implementieren. Die muss man aber natürlich installieren, während ein Browser immer vorhanden ist, und es ist halt Kabel-gebunden.
Nicht wirklich. Ich will nicht wissen, wie viele Millionen ESP8266 und ESP32 sich weltweit für irgendwelche Smart-Home-Anwendungen im Dauerbetrieb befinden.
Anekdotische Evidenz: Man hört selten von Ausfällen und auch in kommerziellen Projekten findet der ESP Anwendung.
Scheint mir auch mehr Angst als Fakt zu sein. Gigabit über WLAN kannst du beim PiPico oder ESP sicher nicht erwarten, aber wenn du ein paar kBytes an Messwerten alle paar Millisekunden übertragen möchtest, dann wird da sicher nichts haken, wenn du es richtig machst (!).
Ist doch auch eigentlich egal, ob das Projekt nun 30 oder 40 Sekunden braucht. Moderne Compiler machen ja auch selten einen "clean build". Und als Anwender merkst du davon auch nichts mehr.
Naja, da da ein paar unnötige Wandlungen drin sind und es am Ende eh irgendwie über USB geht, trifft das auch nicht mehr zu. RS232 war in den 80ern vielleicht der heiße Scheiß.
Es gibt für WLAN- und Netzwerkfähige Mikrocontroller bereits viele Projekte und Bibliotheken, die WebGUIs anbieten und dabei erstaunlich zuverlässig arbeiten. Es braucht keine weitere Software, das Ganze ist unabhängig vom Betriebssystem, dank AJAX und co. fühlt es sich auch genau so fluffig an, wie z.B. eine Handy-App.
Du kannst deinen Mikrocontroller auch MQTT beibringen und dann z.B. zur Visualisierung einen Raspberry Pi mit Node-RED (komplett webbasiert!) nutzen, dann ist das Programm auf dem Controller etwas schlanker.
Ansonsten haben viele Mikrocontroller heutzutage auch eine USB-Schnittstelle in Hardware, mit der sich schnell und zuverlässig Daten übertragen lassen. Ganz lustige Kanditaten können sogar ein Netzwerkinterface über USB darstellen, dann kannst du über USB die Webseite auf dem Controller aufrufen.
ja, das wird sich nie durchsetzen. Schon gar nicht im SmartHome.
Ich denke mal das Hauptproblem wird die schwankende Latenz und Datenrate sein. Auch wenn es grundsätzlich funktioniert, hat man vermutlich gelegentliche "Hänger". Zum Anzeige der Temperatur im Wohnzimmer ist da sicherlich irrelevant, aber wenn man komplexere Messwerte in Echtzeit ohne "Ruckler" darstellen und aufzeichnen möchte kann das anders aussehen.
Btw: Meine WLAN-basierten Medien-Streaming-Geräte funktionieren so gut dass ich jetzt ein Ethernet-Kabel im Wohnzimmer habe 😉
Btw: Meine WLAN-basierten Medien-Streaming-Geräte funktionieren so gut
dass ich jetzt ein Ethernet-Kabel im Wohnzimmer habe 😉
FireTV und Co. haben seit Ewigkeiten nicht mal mehr einen Ethernet Anschluss und das funktioniert ganz hervorragend.
WLAN Probleme liegen meistens daran dass das WLAN von DAUs installiert wird. Mit HW vom Grabbeltisch.
WLAN Probleme liegen meistens daran dass das WLAN von DAUs installiert
wird. Mit HW vom Grabbeltisch.
Kannst ja vorbei kommen und diagnostizieren. Vermutlich müsste ich den Fernseher umdrehen damit die Antenne freie Sicht zum Router hat. Dann können die Spinnen auf der Wand Netflix schauen! Beim Chromecast kann man Ethernet via USB nachrüsten. Aktuelle JBL Smart Speaker haben nativ Ethernet.
WLAN Probleme liegen meistens daran dass das WLAN von DAUs installiert
wird. Mit HW vom Grabbeltisch.
Das 802.11g Band ist nicht nur im IoT Bereich noch weit verbreitet und hoffnungslos verseucht. Nicht jeder kann sich das Rivermind Lux Abo leisten und von der hervorragenden Netzabdeckung profitieren.
Btw: Meine WLAN-basierten Medien-Streaming-Geräte funktionieren so gut
dass ich jetzt ein Ethernet-Kabel im Wohnzimmer habe 😉
Das funktioniert nur deshalb so gut, weil mehrere Sekunden Streamingbuffer dazwischen sind.
Hier wäre interessant, mal die Echtzeitgamer zu fragen, ob die Interaktion über das WLAN die notwendige Reaktionszeit erlaubt.
-- Datenrate gebremst durch serielle Schnittstelle
Du kannst mit Standard-Uarts am PC heute 1MBaud und mehr fahren. Und im µC innerhalb von µs reagieren.
100 Byte Anfrage und 10kByte Antwort brauchen 0,1s zur Übertragung.
Im Labor funktioniert das ohne besondere Maßnahmen, im Feld musst Du die Signale halt verlässlich gestalten. Für wenige m reichen weiterhin 3 Leitungen (Rx/Tx/Gnd), ab etwa 20 m kannst Du auch auf 2 x Differentiell wechseln.
Eine Web GUI würde ich heutzutage auch bevorzugen. Dann braucht man auf dem Zielsystem keine Applikation zu installieren, was ja im Geschäftsumfeld auch immer schwieriger wird (Firmen-Policies, Zertifikate, keine Admin-Rechte, etc.)
Ich habe sehr gute Erfahrungen gemacht mit STM32H7 Mikrocontrollern, auf denen man z.B. CycloneTCP laufen lässt als TCP/IP stack und da sind auch Module dabei für HTTP, HTTPS, Websocket, etc.
Die sind meist genügend performant um alles mit demselben Mikrocontroller zu erledigen.
Für WLAN würde ich, wie schon andere geschrieben haben, wohl auch eher auf ESP32 gehen.
Für WLAN würde ich, wie schon andere geschrieben haben, wohl auch eher
auf ESP32 gehen.
Im Moment mache ich alles mit dem PiPico. Die Frage wäre, ob ein ESP32 bezüglich WLAN geeigneter wäre.
Im Anhang mein Testprogramm. Als Elemente gibt es Zahleneingaben, Buttons und einen Check-Button. Die GUI wird im PiPicoW gehosted und damit ist das System autonom ohne weiter Softwareerfordernisse.
Der PiPicoW zieht einen Accesspoint auf, so dass man auch keinen Routerzugang benötigt.
Ich hab in letzter Zeit eine quelloffene Modellbahn-Zentrale entwickelt die eine Flutter Web-App auf einen ESP32 packt:
https://openremise.at/Frontend/demo/
Daten die zeitnah hin- und her geschickt werden müssen pack ich dort in einen WebSocket. Man muss etwas aufpassen dass man den ESP32 nicht mit Requests flutet, aber sonst funktioniert das ganz gut.
Man sollte aber halt nicht vergessen dass der Aufwand imho schon ungleich höher is als ein paar Bytes über eine serielle zu jagen.
Ich hab in letzter Zeit eine quelloffene Modellbahn-Zentrale entwickelt
die eine Flutter Web-App auf einen ESP32 packt:
https://openremise.at/Frontend/demo/
Ich sehe, dass die Werte etwa jede Sekunde ein Update erfahren. Es Scheint sehr stabil, allerdings muss man auch sagen, dass die Werte hier ja über das LAN auf meinem Bildschirm erscheinen.
Christoph M. schrieb:
-- Datenübertragung bisweilen hackelig
Sebastian R. (sebastian_r569)
06.10.2025 07:55
Scheint mir auch mehr Angst als Fakt zu sein. Gigabit über WLAN kannst
du beim PiPico oder ESP sicher nicht erwarten, aber wenn du ein paar
kBytes an Messwerten alle paar Millisekunden übertragen möchtest, dann
wird da sicher nichts haken, wenn du es richtig machst (!).
Eine Streaming-Anwendung ohne merkbare Unterbrechung zu machen ist eher Standard und einfach ( zumindest der Buffer im Mikrocontroller bei hohen kontinuierlichen Datenraten nicht zu klein wird und überläuft) . Eine Anwendung mit hoher "Schwubzidität", also Knopf drücken und sofort sichtbares Ergebnis schon eher nicht. Da hängt dann viel von den Bedingungen im WLAN ab.
Ich sehe, dass die Werte etwa jede Sekunde ein Update erfahren. Es
Scheint sehr stabil, allerdings muss man auch sagen, dass die Werte hier
ja über das LAN auf meinem Bildschirm erscheinen.
Die Werte in dieser Demo kommen auch nur von gefakten Services die einfach ein kurzes Delay abwarten um ein Gefühl für das zu erzeugen was sich auf der Hardware abspielt.
Meine Hardware besitzt aber aktuell auch nur WLAN und es fühlt sich recht "snappy" an wie man wohl dazu sagen würde.
Problematisch bei Flutter ist sicherlich die Bundlegröße. Die absolut minimalste App hat ~1MB.
-- Datenrate gebremst durch serielle Schnittstelle
Was denkst du, wieviel MByte pro Sekunde ein Nutzer über ein Web-Interface aufnehmen kann? Bei vernünftiger Programmierung soll doch der Browser die Darstellung machen, so dass relativ wenig Daten über die Schnittstelle laufen müssen.
Einen Mikrocontroller mit WLAN wie z.B. PiPico W
-- WLAN störanfällig
-- Datenübertragung bisweilen hackelig
-- Compilierung langsam
++ Web GUI vollständig im Mikrocontroller
Serial-TCP-Bridge auf PC
-- Datenrate gebremst durch serielle Schnittstelle
++ zuverlässig
Was ist am besten, wie sind eure Erfahrungen?
Ich habe damit zwar (noch) keine Erfahrung, würde aber folgendes
ausprobieren:
Mikrocontroller mit Ethernet
++ nicht störanfällig
++ keine anwendungsspezifische Software auf dem PC erforderlich (der
Webserver auf dem Mikrocontroller kommuniziert direkt mit dem
Webbrowser auf dem PC)
++ schnelle Datenübertragung (abhängig natürlich von dem
Ethernet-Interface des Mikrocontrollers)
Mikrocontroller mit Ethernet over USB (wenn er kein Ethernet, aber
USB hat, wie bspw. der RP2040)
++ nicht störanfällig
++ keine anwendungsspezifische Software auf dem PC erforderlich (der
Webserver auf dem Mikrocontroller kommuniziert direkt mit dem
Webbrowser auf dem PC)
oo Übertragungsgeschwindigkeit (beim RP2040) durch USB (Full Speed)
auf 12 MBit/s minus Overhead begrenzt
Einen Mikrocontroller mit WLAN wie z.B. PiPico W
...
-- Compilierung langsam
Langsamer als bei anderen Mikrocontrollern bei vergleichbarem Quellcode?
Ist mir noch nie aufgefallen und bin deswegen auch noch nie ungeduldig
geworden.
Ich benutze zum Beispiel eine einmalig ausgelieferte HTML mit Ajax.
Die Requests und Daten als Json bleiben dann minimal.
Wozu denn Requests? Für solche Anwendungsfälle gibt es Server-Sent Events und -- sofern ein Rückkanal notwendig ist -- Websockets. Für beide Varianten gibt es die Möglichkeit der Kompression, was dann die 6,4 MBit relativiert. Dabei ist allerdings zu bedenken, daß Kompression beiderseits Rechenleistung kostet und deswegen beiderseits sowohl Last als auch Latenz erzeugt.
Abgesehen davon habe ich das Gefühl, daß der Terminus "Echtzeit" in diesem Thread inkorrekt benutzt wird. Der Volksmund verwendet den Begriff so, daß etwas "so schnell wie möglich" oder gar "sofort" stattfinden soll. Korrekt geht es jedoch nur darum, daß etwas zuverlässig innerhalb einer definierten Zeit geschieht -- und diese Zeit kann durchaus mehrere Stunden betragen.
Aus diesem Grund fehlt mir in diesem Thread eine Definition zum Zeitfenster, das zwischen dem serverseitigen Anfallen und der clientseitigen Darstellung der Daten benötigt werden darf.
Mikrocontroller mit Ethernet over USB (wenn er kein Ethernet, aber
USB hat, wie bspw. der RP2040)
Hast du da einen konkreten Adapter im Blick? Da wäre die Frage, ob so ein Adapter eine beliebige Webseite weiterleiten kann und keine Installationsaufwand benötigt wird.
Ein T. (ein_typ)
Wie viel kann so ein menschliches Auge eigentlich aufnehmen /
verarbeiten?
Kein Ahnung. Welche Bandbreite benötigt der Internet Anschluss an deinem Fernseher? Wie schnell ist die Update-Rate moderner Digitaloszilloskope und welche Auflösung hat die Graphik?
Das war sicherlich anders rum gedacht - der Controller wird per USB mit dem PC verbunden und registriert sich als Ethernet-Adapter und tut so, als wäre am anderen Ende des Ethernet-Kabels ein Computer mit Webserver angeschlossen.
Das braucht dann halt einen kompletten IP-Stack und Webserver auf dem Controller, und man muss sich Gedanken um IP-Konfiguration und Firewalls machen.
Wenn man natürlich einen echten Webserver haben möchte muss man sich
anderweitig umschauen.
Ich hab einen ESP32 als http Accesspoint im Auto laufen, Task mit niedriger Priorität und delay(100); mit nur einem Client und Browser überhaupt kein Problem. Ich würde allerdings zu MQTT raten, dann hat man kein Gefummel mit https.
Wer mit MQTT etwas machen möchte, hier habe ich ein kleines Projekt zum Test. Incl. Quellcode und fertige Binaries (PC) veröffentlicht:
Beitrag "Ein MQTT Client"
Das war sicherlich anders rum gedacht - der Controller wird per USB mit
dem PC verbunden und registriert sich als Ethernet-Adapter und tut so,
als wäre am anderen Ende des Ethernet-Kabels ein Computer mit Webserver
angeschlossen.
Ja, genau so war das gemeint. Für den RP2040 (und viele andere
Mikrocontroller) gibt es die TinyUSB-Bibliothek, die mehrere Protokolle
für Ethernet-over-USB unterstützt. Darunter ist auch ECM, das als Teil
der USB-Device-Klasse CDC standardisiert ist und damit von den meisten
PC-Betriebssysteme out-of-the-box unterstützt wird.
Das braucht dann halt einen kompletten IP-Stack und Webserver auf dem
Controller, und man muss sich Gedanken um IP-Konfiguration und Firewalls
machen.
Als IP-Stack bietet sich lwIP an. TinyUSB und lwIP sind beide
Bestandteil des Pico-SDK. Man kann also sofort loslegen.
Wie bereits oben geschrieben, habe ich selber keine Erfahrung damit. Es
gibt aber sicher Beispiele im Netz, auf die man aufbauen kann.
Wie viel kann so ein menschliches Auge eigentlich aufnehmen /
verarbeiten?
Kein Ahnung. Welche Bandbreite benötigt der Internet Anschluss an deinem
Fernseher? Wie schnell ist die Update-Rate moderner Digitaloszilloskope
und welche Auflösung hat die Graphik?
Du stellst Dich gerne ein bisschen dumm, nicht wahr? Ein Fernseher ist kein Oszilloskop, und sogar bei den teuersten und besten digitalen Oszilloskopen besteht ein zeitlicher Abstand zwischen Abtastung und Darstellung.
Davon abgesehen ist es aber immer noch vollkommen sinnlos, die Daten schneller darzustellen, als Dein Auge sie wahrnehmen und verarbeiten kann.
Du stellst Dich gerne ein bisschen dumm, nicht wahr? Ein Fernseher ist
kein Oszilloskop, und sogar bei den teuersten und besten digitalen
Oszilloskopen besteht ein zeitlicher Abstand zwischen Abtastung und
Darstellung.
Davon abgesehen ist es aber immer noch vollkommen sinnlos, die Daten
schneller darzustellen, als Dein Auge sie wahrnehmen und verarbeiten
kann.
Ich sehe in deiner Argumentation keinerlei Daten oder Zahlen. Also kurz zusammengefasst: Du hast keine Ahnung.
