text: ESPuino mit Ethernet - eine Bestandsaufnahme - Hardware - ESPuino :: Rfid-controlled musicplayer
  ESPuino mit Ethernet - eine Bestandsaufnahme
  biologist 14. September 2021 um 09:00 #1
  Irgendwer hier hatte das Thema Ethernet bei ESPuino mal in den Raum geworfen. Da ich selbst ja auch großer Ethernet-Fan bin, habe ich mir (aufgrund von anderen Tests) mal überlegt, hier ein paar Zeilen zu schreiben.
  In einem Projekt für die Steuerung einer Gartenbewässerung nebst kleiner Wetterstation, habe ich in meinem Gartenhaus einen ESP32, der mit Ethernet angebunden ist und seinerseits Eingänge für ein Relaisboard ansteuert. Das läuft seit knapp drei Jahren. Das Ganze in einem relativ wilden Drahtverhau auf Streifenraster gelötet (damals habe ich noch keine PCBs gemacht) und als Ethernet-Modul ein W5500 verwendet, das mit SPI angebunden ist. Da ich mehr als die Hälfte im Jahr nix bewässern muss, kommt auch hier so eine ähnlich 2stufige Transistorschaltung zum Einsatz, wie ihr die auch vom ESPuino kennt. Damit schalte ich sogar das Ethernet-Modul aus. D.h. alle fünf Minuten schaltet der sich ein, misst die Sensoren und geht wieder in den Deepsleep. Müsste ich jetzt nicht, da es eh an der Steckdose hängt, aber es tut ja auch nicht weh.
  Nachteilig an dieser Variante ist, dass OTA und auch eine Lib, mit der ich serielle Ausgaben auf Syslog schicken kann, nicht funktionieren. Überhaupt ist es zu diesem Thema überhaupt nicht einfach, passende Infos zu kriegen. Wobei das ein Stück weit für Ethernet beim ESP32 grundsätzlich gilt; es wird halt wenig verwendet.
  Nun würde ich gerne den Drahtverhau gerne mal mit einem ordentlichen PCB beseitigen und habe diesen PCB auch schon ewig hier rumliegen. Und da ich gerade eine Lüftersteuerung mit Ethernet für meinen Bruder baue, habe ich diesen PCB jetzt mal ausgekramt und ein paar Versuche gemacht. Inzwischen nicht mehr mit dem W5500 sondern mit LAN8720. Das wird nicht über SPI angebunden sondern über RMII.
  Die Programmierung unterscheidet sich fast gar nicht von WiFi. Interessanterweise arbeitet man tatsächlich mit einem WiFi-Objekt.
  OTA funktioniert
  Syslog funktioniert
  Es braucht erheblich mehr GPIOs; acht an der Zahl.
  Der 50 MHz-Takt eingehend auf GPIO0 ist beim Einschalten problematisch, da der ESP32, wenn man nicht besondere Vorkehrungen trifft, dann in Programming-Mode geht.
  Strombedarf des PCBs liegt mit 100 MBps Ethernet-Verbindung bei etwa 180 mA. Der Webserver, der bei ESPuino verwendet wird, funktioniert auf jeden Fall auch.
  Ich würde vermuten, dass man einen ESPuino mit relativ überschaubaren Code-Änderungen, auch mit Ethernet zum Laufen kriegen würde. Das ginge inzwischen vermutlich auch relativ kompakt, da es ein Develboard dafür gibt (kostet bei Aliexpress so 12eur rum). Man müsste dann allerdings mit Port-Expander arbeiten, da die Anzahl der freien GPIOs dadurch erheblich kleiner wird.
  Ich denke für Kinder ist das eher nix. Aber wenn man zB irgendwo Ethernet (und kein WLAN) hat, dann ist das sicherlich ein Weg, den man gehen könnte.
  Ringer 19. Januar 2022 um 15:01 #2
  Hallo @biologist bisher habe ich gute Erfahrungen gemacht mit wESP32 - wESP32 — Wired ESP32 with PoE Wäre sogar mit POE und könnte man dann ohne Akku und eigener Spannungsversorgung als Webradio oder so verwenden. Wenn man RFID und PortExpander über I2C geht kommt man auch bin den Pins hin. Bin stark am überlegen mein Audio Board so zu gestalten , dass man optional auch dieses Board benutzen kann.
  image378×560 16.3 KB
  biologist 21. Januar 2022 um 11:44 #3
  Diesen PCB gibt's in Sachen Ethernet auch noch habe ich eben durch Zufall gesehen: LILYGO®TTGO T Internet POE ESP32 WROOM LAN8720A Chip Ethernet Adapter Und Downloader Expansion Board Programmierbare Hardware|Circuits| - AliExpress. Ist aber "nur" ein WROOM, d.h. kein PSRAM und auch nur 4MB Speicher. Dafür halt zusätzlich die GPIOs 16+17.
  Ringer 21. Januar 2022 um 13:09 #4
  Es gibt echt schon zu viele Boards Wie schlimm ist eigentlich kein PSRAM für den ESPuinio Code. Was funktioniert nicht so gut bzw. gibt es Performance Einbuße?
  ist sehr ähnlich der alten Version von Wesp32 (dieser hat in der neusten Version Ethernet PHY RTL8201 und 16MB) .
  LILYGO®TTGO T-Internet-POE wäre natürlich günstiger und schon mit SD-Karte aber warum kein UART auf dem Board wenn es eh schon ein USB-C Stecker gibt?
  biologist 21. Januar 2022 um 14:54 #5
  Wie schlimm ist eigentlich kein PSRAM für den ESPuinio Code. Was funktioniert nicht so gut bzw. gibt es Performance Einbuße?
  Also man hat auf einem ESP32 ja für einen Mikrocontroller echt viel Speicher, aber wir machen hier halt auch einiges, was teilweise recht viel Speicher braucht. Heap-Fragmentierung ist auch so ein Punkt. An dieser Stelle kommt PSRAM ins Spiel: Das ist Speicher, der intern über SPI angebunden ist. Das bedeutet, dass dieser (für einen Arbeitsspeicher) nicht super schnell ist, aber im Sinne eines Mikrocontrollers mit 4 oder 8 MB halt riesig. Wo der uns bei ESPuino gar nix bringt ist z.B. als Puffer für den Webtransfer, weil der würde diesen, da er ja selbst nur per SPI angebunden ist, ausbremsen.
  ESPuino nutzt den PSRAM also nur, wenn es Sinn macht. Dort entlastet er aber den normalen Speicher. Beispiel: Du legst eine Karte auf und es wird eine Playlist mit 100 Titeln generiert. Haben wir PSRAM, dann kommt diese Playlist in den PSRAM und entlastet damit den wertvollen Heap. Man verschafft sich also ein Stück weit Reserven.
  Und dann gibt's noch was: Die Audiolib unterstützt ja auch Webstreams. Die Streams schwanken im Durchsatz ja gerne mal und da hat man gerne einen Puffer. Ohne PSRAM ist dieser erheblich kleiner, so dass es potentiell eher zu Pausen kommen kann, wenn dieser leer gelaufen ist. Das muss nicht notwendigerweise ein Nachteil sein, es kann aber - kommt auf den Stream an.
  Bedeutet: Es muss kein Nachteil sein, einen WROOM zu verwenden und es muss auch kein Vorteil sein, einen WROVER zu haben. Es hängt maßgeblich davon ab, wie man den ESPuino verwendet. Es geht auch alles mit einem WROOM und vielleicht spürt man nie einen Unterschied. Aber Fakt ist: Man verschafft sich mit einem WROVER Reserven. Und da sich die Chips selbst preislich wenig unterscheiden, ist "haben ist besser als brauchen" da irgendwie naheliegend, weswegen ich das ein Stück weit auch propagiere. Problem ist nur, dass in Sachen Develboards halt üblicherweise WROOMs verwendet werden, so dass man sich das nicht ganz so frei aussuchen kann.