Echtzeit Web GUI und Mikrocontroller

[Christoph M. (mchris)]

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:

1. 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


2. Serial-TCP-Bridge auf PC

-- Datenrate gebremst durch serielle Schnittstelle
++ zuverlässig

Was ist am besten, wie sind eure Erfahrungen?

[Niklas G. (erlkoenig)]

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.

[Sebastian R. (sebastian_r569)]

Christoph M. schrieb:
> -- WLAN störanfällig

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.

Christoph M. schrieb:
> -- Datenübertragung bisweilen hackelig

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 (!).

Christoph M. schrieb:
> -- Compilierung langsam

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.

Christoph M. schrieb:
> ++ Web GUI vollständig im Mikrocontroller

Jep. Das einzige, was ein kleiner Nachteil werden kann: Der Bums braucht 
Platz.

Christoph M. schrieb:
> -- Datenrate gebremst durch serielle Schnittstelle

Und selbst da wären heutzutage ein paar MBit/s möglich. Serielle 
Schnittstelle heißt ja nicht 9600bd.

Christoph M. schrieb:
> ++ zuverlässig

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.

[Cyblord -. (cyblord)]

Christoph M. schrieb:
> -- WLAN störanfällig

ja, das wird sich nie durchsetzen. Schon gar nicht im SmartHome.

[Niklas G. (erlkoenig)]

Cyblord -. schrieb:
> Christoph M. schrieb:
>> -- WLAN störanfällig
>
> 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 😉

[Cyblord -. (cyblord)]

Niklas G. schrieb:
> 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.

[Niklas G. (erlkoenig)]

Cyblord -. schrieb:
> 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.

[Cyblord -. (cyblord)]

Niklas G. schrieb:
> Vermutlich müsste ich den
> Fernseher umdrehen damit die Antenne freie Sicht zum Router hat.

q.e.d.

[Sebastian R. (sebastian_r569)]

Niklas G. schrieb:
> Beim Chromecast kann
> man Ethernet via USB nachrüsten

Beim FireTV Stick auch. Der offizielle Adapter kostet 10€.

[Alexander (alecxs)]

Cyblord -. schrieb:
> 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.

[Christoph M. (mchris)]

Niklas G. (erlkoenig) Benutzerseite
>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.

[Norbert (der_norbert)]

Christoph M. schrieb:
> 2. Serial-TCP-Bridge auf PC
>
> -- Datenrate gebremst durch serielle Schnittstelle
> ++ zuverlässig

# [36544.513586] usb 1-1.3.2: new full-speed USB device number 12 using ehci-pci
# [36544.622960] usb 1-1.3.2: New USB device found, idVendor=067b, idProduct=2303, bcdDevice= 3.00
# [36544.622963] usb 1-1.3.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
# [36544.622965] usb 1-1.3.2: Product: USB-Serial Controller
# [36544.622967] usb 1-1.3.2: Manufacturer: Prolific Technology Inc.
# [36544.688175] usbcore: registered new interface driver usbserial_generic
# [36544.688182] usbserial: USB Serial support registered for generic
# [36544.689844] usbcore: registered new interface driver pl2303
# [36544.689851] usbserial: USB Serial support registered for pl2303
# [36544.689875] pl2303 1-1.3.2:1.0: pl2303 converter detected
# [36544.691375] usb 1-1.3.2: pl2303 converter now attached to ttyUSB0

#  50   75   110   134   150   200   300   600
#  1200   1800   2400   4800   9600
#  19.200   38.400   57.600
#  115.200   230.400   460.800   576.000   921.600   1.152.000
#  0.5M   1.0M   1.5M   2.0M   2.5M   3.0M   3.5M   4.0M

Braucht man mehr als 4MBit/s, dann greift man zu FTDI.

[Bruno V. (bruno_v)]

Christoph M. schrieb:
> -- 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.

[Johnny B. (johnnyb)]

Christoph M. schrieb:
> Was ist am besten, wie sind eure Erfahrungen?

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.

[Christoph M. (mchris)]

Johnny B. (johnnyb)
06.10.2025 12:21
>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.

const char* ap_ssid = "PicoW-AP";
const char* ap_password = "123456789";

...


// Send JSON state to clients
void notifyClients() {
  String json = "{";
  json += "\"started\":" + String(started ? 1 : 0) + ",";
  json += "\"muted\":" + String(muted ? 1 : 0) + ",";
  json += "\"powerOn\":" + String(powerOn ? 1 : 0) + ",";
  json += "\"counter\":" + String(counter) + ",";
  json += "\"rand1\":" + String(randVar1) + ",";
  json += "\"rand2\":" + String(randVar2);
  json += "}";
  ws.textAll(json);
}

Die Werte auf der Webpage werden alle 250ms gesendet. Der Graph zeigt 
den Zählerwert der empfangen wurde.

Beobachtung:
- der Status-Update auf der Webseite erfolgt ungleichmässig
- Mit 4 Meter Abstand wird der Status-Update und der Graph unregelmässig 
refreshed.

Wer einen PiPicoW hat, kann das angehängte u2f-File flashen und die 
Experimente selbst machen.

[Vincent H. (vinci)]

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.

[Christoph M. (mchris)]

Vincent H. (vinci)
06.10.2025 14:43

>Ich hab in letzter Zeit eine quelloffene Modellbahn-Zentrale entwickelt
>die eine Flutter Web-App auf einen ESP32 packt:
>https://openremise.at/Frontend/demo/

Sieht nett aus. Flutter kannte ich noch nicht
https://flutter.dev/

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.

[Vincent H. (vinci)]

Christoph M. schrieb:
> Sieht nett aus. Flutter kannte ich noch nicht
> https://flutter.dev/
>
> 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.

[Niklas G. (erlkoenig)]

Christoph M. schrieb:
> Sieht nett aus. Flutter kannte ich noch nicht

Echt?! Das ist so ziemlich der Standard für Cross-Platform GUIs...

[Rainer W. (rawi)]

Christoph M. schrieb:
> -- 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.

[Christoph M. (mchris)]

Rainer W. (rawi)
>Was denkst du, wieviel MByte pro Sekunde ein Nutzer über ein
>Web-Interface aufnehmen kann?

Ich nehme mal einen Graphen mit 4 Kurven, 50Hz update, 1000 Punkte, 
Float:

fs = 50
punkte = 1000
kurven = 4
bytes = 4
fs*punkte*kurven*bytes
ans = 800000

Also 0.8MByte/sec * 8Bit = 6.4 MBit/sec für einen Graphen wie er auf 
einen Oszilloskope zu finden ist.

[Nemopuk (nemopuk)]

Christoph M. schrieb:
> Hier wäre interessant, mal die Echtzeitgamer zu fragen, ob die
> Interaktion über das WLAN die notwendige Reaktionszeit erlaubt.

Mein Sohn besteht auf Kabel, eben deswegen.

[Yalu X. (yalu) (Moderator)]

Christoph M. schrieb:
> 1. 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
>
> 2. 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:

3. 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)

4. 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

Christoph M. schrieb:
> Also 0.8MByte/sec * 8Bit = 6.4 MBit/sec für einen Graphen

Könnte mit (4) hinkommen, wobei ich die 50 Hz Updaterate etwas
übertrieben finde.

Christoph M. schrieb:
> 1. 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.

[Frank K. (fchk)]

Ich würde auch zuerst an Ethernet denken.
* Es gibt einen Haufen an Prozessoren mit Ethernet MAC sowie einie 
wenige mit MAC+PHY eingebaut. Diverse ARM und MIPSe
* Es gibt zahlreiche Ethernet-Controller mit SPI-Interface.
* Ethernet an sich ist relativ einfach und gut dokumentiert.
* Aus Ethernet WLAN zu machen ist relativ einfach. Dafür gibts fertige 
Access Points.

fchk

[Philipp K. (philipp_k59)]

Der ESP32/s3/c6 ist da im Moment nicht wegzudenken.

2*240mhz wobei 1 Core Built-In mit WLAN beschäftigt ist.

Bei mir läuft das ganz gut und stabil.

Wenn man natürlich einen echten Webserver haben möchte muss man sich 
anderweitig umschauen.

Ich benutze zum Beispiel eine einmalig ausgelieferte HTML mit Ajax.

Die Requests und Daten als Json bleiben dann minimal.

[Ein T. (ein_typ)]

Christoph M. schrieb:
> Also 0.8MByte/sec * 8Bit = 6.4 MBit/sec für einen Graphen wie er auf
> einen Oszilloskope zu finden ist.

Wie viel kann so ein menschliches Auge eigentlich aufnehmen / 
verarbeiten?

[Ein T. (ein_typ)]

Philipp K. schrieb:
> 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.

[Christoph M. (mchris)]

Yalu X. (yalu) (Moderator)
06.10.2025 17:52
>4. 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?

[Niklas G. (erlkoenig)]

Christoph M. schrieb:
> Hast du da einen konkreten Adapter im Blick?

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.

[900ss (900ss)]

ESP32 bekommt man auch mit LAN Interface. Funktioniert gut.

https://www.roboter-bausatz.de/p/wt32-eth01-esp32-modul-mit-ethernet-bluetooth-wifi

Gibt's in China auch günstiger.

[Alexander (alecxs)]

Philipp K. schrieb:
> 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.

[900ss (900ss)]

Alexander schrieb:
> Ich würde allerdings zu MQTT raten,

Ist für den Zweck auch eine sehr gute Alternative....

[Cyblord -. (cyblord)]

Alexander schrieb:
> Ich würde allerdings zu MQTT raten, dann hat man
> kein Gefummel mit https.

Der Nachteil ist, bei MQTT braucht man immer ein extra Tool. Bei einem 
Web GUI reicht der Browser.

[Markus M. (Firma: EleLa - www.elela.de) (mmvisual)]

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"

[900ss (900ss)]

Cyblord -. schrieb:
> Der Nachteil ist, bei MQTT braucht man immer ein extra Tool.

Es hängt dann eher von den speziellen Gegebenheiten und Wünschen ab, ob 
MQTT oder gleich ein Weeb-Server geeigneter sind.

[Yalu X. (yalu) (Moderator)]

Niklas G. schrieb:
> Christoph M. schrieb:
>> Hast du da einen konkreten Adapter im Blick?
>
> 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.