­čôŚ Welche Vorteile bietet ein ESP32-WROVER gegen├╝ber einem ESP32-WROOM beim ESPuino?

An verschiedenen Stellen wurde bereits erw├Ąhnt, dass ein ESP32-WROVER Vorteile haben kann gegen├╝ber eine ESP32-WROOM. Um das Ganze transparenter zu machen f├╝r eine etwaige Kaufentscheidung, habe ich mich dazu entschlossen, hierzu mal ein paar Dinge auf einen Blick zusammen zu schreiben.

Arbeitsspeicher

Bei einem Mikrocontroller ist der vorhandene Speicher oft nicht so ├╝ppig, wie man ihn gerne h├Ątte. Zwar ist der ESP32 eh schon sehr gut ausgestattet, jedoch ist das ESPuino-Projekt inzwischen so umfangreich, dass es hier und da durchaus eng werden kann. Hier kommt der PSRAM ins Spiel. Wenn der interne Speicher (statischer RAM oder Heap) knapp wird, kann alternativ PSRAM benutzt werden. Angebunden wird er ├╝ber SPI. Das ist insofern wichtig zu wissen, weil dies langsamer ist, als die regul├Ąre Speicheranbindung. F├╝r die meisten Zwecke ist das egal, aber beispielsweise f├╝r den FTP-Server des ESPuinos macht dies keinen Sinn, da der SPI-Flaschenhals hier bremsend wirkt. Der PSRAM ist entweder 4 MB oder 8 MB gro├č, was im Kontrast zu den ├╝blichen Speicherverh├Ąltnissen ÔÇ×f├╝rstlichÔÇť ist. Genau genommen wei├č ich beim ESPuino gar nicht, wo ich mit so viel Speicher hin soll :joy: .

Flashspeicher

Beim WROOM hat man 4 MB Flashspeicher - beim WROVER bis zu 16 MB. Der Vorteil eines gro├čen Flashspeichers ist, dass man OTA-Feature nutzen kann (was ESPuino aktuell jedoch noch nicht tut aber bald tun wird). Hier l├Ąsst sich ein Firmware-Image auch per WLAN aufspielen. Hintergrund ist, dass das Image zuerst zwischengespeichert werden muss. Das geht grunds├Ątzlich nat├╝rlich auch mit dem WROOM, jedoch ist das Firmware-Image des ESPuino inzwischen zu gro├č daf├╝r, um doppelt in den Flashspeicher zu passen.

An welchen Stellen wird PSRAM von ESPuino genutzt?

Achtung, jetzt wird es technisch :slight_smile:

  1. Der Datenaustausch zwischen WebGUI und ESPuino erfolgt ├╝ber JSON. D.h. wenn der Dateibrowser Dateien angezeigt, dann m├╝ssen diese in den Speicher des JSON-Objektes passen. Nachdem es verschiedene Probleme mit dem verbleibenden Heap-Speicher gab, werden beim WROOM inzwischen 8 kBytes an statischem Speicher allokiert. Reicht dieser Speicher nicht, dann kommt es zu Problemen bei der Anzeige. Ist PSRAM verf├╝gbar, so werden hier 64 kB aus dem PSRAM allokiert und das k├Ânnte man auch noch betr├Ąchtlich vergr├Â├čern bei Bedarf.

  2. Wird eine Karte aufgelegt, so wird eine Playlist generiert (zweidimensionales Array). Der Speicher daf├╝r wird normalerweise dynamisch aus dem Heap allokiert, weswegen viele Dateien auch problematisch werden k├Ânnten. Beim WROVER wird PSRAM benutzt - hier kann man aus dem Vollen sch├Âpfen.

  3. Die Instanz, die sich um das Abspielen der Musik k├╝mmert, wird normalerweise aus dem statischen Speicher allokiert. Ist PSRAM verf├╝gbar, so wird dieser anstelle dessen benutzt. Mehr noch: Ist PSRAM verf├╝gbar, so legt die verwendete Lib beim Abspielen eines Webstreams automatisch einen gr├Â├čeren Puffer an, der dazu f├╝hren kann, dass es weniger Aussetzer durch Leerlaufen des Puffers gibt.

  4. ├ťber die WebGUI gibt es ein Log, welches Ausgaben anzeigt, die man sonst nur in der seriellen Konsole liegt. Die L├Ąnge des Logs ist normalerweise 2 kB. Ist PSRAM verf├╝gbar sind es 10 kB und kann bei Bedarf vergr├Â├čert werden. Steuerbar ist dies via platformio.ini ├╝ber die Direktive DLOG_BUFFER_SIZE.

  5. Es gibt noch verschiedene kleinere Sachen, f├╝r die ebenfalls fakultativ PSRAM (statt Heap) benutzt wird. Um den Code hier einfacher zu halten, gibt es daf├╝r Funktionen, die die Unterscheidung ├╝bernehmen.

  6. Die Liste wird k├╝nftig sicherlich noch l├Ąnger werdenÔÇŽ

Hat ein ESP32-WROVER auch Nachteile?

Mir ist nur einer bekannt: Durch die SPI-Anbindung des PSRAMs hat man zwei GPIOs (Nummer 16+17) weniger zur Verf├╝gung.

Warum nicht einfach immer WROVER benutzen?

Die meisten Projekte sind nicht so gro├č, dass sie PSRAM ben├Âtigen. Da WROOMs zudem etwas g├╝nstiger sind vermute ich, dass die Develboard-Hersteller hier einfach auf die Kosten achten und eben die g├╝nstigere Variante verbauen, um konkurrenzf├Ąhiger sein zu k├Ânnen. Grunds├Ątzlich ist es so, dass WROVER-Boards eher d├╝nn ges├Ąt sind im Vergleich.
Beispiele w├Ąren:

Ist die Nutzung eines WROOMs problematisch?

Nein. Ein ESPuino funktioniert auch damit gut und ist tats├Ąchlich die Plattform, die ich haupts├Ąchlich selbst nutze. Nur kann es bei Wechsel zwischen Webradio und z.B. Playlists mit vielen Dateien, zu Neustarts kommen, da der Speicher nicht ausreicht. Generell ist man im Handling mit vielen Dateien, auch was den Dateibrowser betrifft, hier etwas limitiert und im Gegenzug mit PSRAM auf der eher sicheren Seite. Zumindest theoretisch :joy: .