Esp32-s3

Ich habe mir gedacht, dass ich zum S3 mal einen Thread hier aufmache, damit man verschiedene Infos zusammentragen kann. Von Wemos gibt es ein S3-Board, von dem auch der Schaltplan publiziert ist.

Dokumente / Links:

Varianten / Modelle:


Man hat beim ESP32 die Möglichkeit, ihn als Chip oder als Modul zu verwenden. Da die Verwendung von Modulen einiges an Annehmlichkeiten mit sich bringt und für uns hinreichend ist, verwendet ESPuino ausschließlich solche.

  • Die Module werden grundsätzlich (siehe Bild) in N und U unterteilt. Hierbei entspricht N mit integrierter Antenne und U eben ohne. ESPuino setzt immer die Variante N ein.
  • Es gibt drei ESP32-Chips: ESP32-S3, ESP32-S3R2 und ESP32-S3R8. Erstgenannter ist immer ohne PSRAM. R2 besitzt 2 MB PSRAM und R8 entsprechend 8 MB PSRAM. Alle Modul-Varianten teilen die Eigenschaft, dass man sie mit 4, 8 und 16 MB Flash kriegt. Für ESPuino-Zwecke sollten N8R2 bzw. N16R2 am besten passen.

Allgemeine Gedanken / Fakten

  • Der aus meiner Sicht größte Vorteil eines ESP32-S3 ggü. einem ESP32 ist, dass mehr GPIOs vorhanden sind. Vielleicht ermöglicht uns das, dass wir langfristig wieder auf einen Port-Expander verzichten können.
  • Weiterhin kann SDMMC zu beliebigen GPIOs geroutet werden (statt 2, 14 und 15 beim ESP32). Für SDMMC gibt es, wie auch beim ESP32, Modi mit 1 und 4 Bit. Letztgenanntes hätte den SD-Transfer vermutlich ein bisschen schneller gemacht, jedoch war der „Preis“ mit drei zusätzlichen GPIOs zu hoch, so dass ich das nie getestet habe.
  • Es gibt wieder eine ganze Reihe von ADC-Eingängen. Wenn ich die Doku richtig verstehe, dann sollte man, wenn man WLAN nutzt (und das tun wir ja), nur die ADC1-Eingänge (GPIO1 bis GPIO10) nutzen.
  • Mit USB-OTG kann man nun offenbar ohne einen USB-seriell-Adapter des ESP32 flashen und hat auch eine serielle Konsole. Das Ganze für wohl zu etwas mehr Speicherverbrauch. Muss man mal schauen, ob man das nutzen möchte. Vorgesehen sind dafür die GPIOs 19 + 20; ggf. hat man mehr davon, wenn man diese beiden GPIOs anderweitig nutzen kann und stattdessen weiterhin z.B. einen CH340 verbaut. Wird sich zeigen.

„USB-JTAG: GPIO 19 and 20 are used by USB-JTAG by default. In order to use them as GPIOs, USB-JTAG will be disabled by the drivers.“

  • Strapping-Pins sind 0, 3, 45 und 46.
  • WROVER-Varianten scheint man abgeschafft zu haben. D.h., dass es, je nach Modell, im WROOM-Modul PSRAM gibt.
  • I2C und I2S kann man zu beliebigen GPIOs routen.
  • GPIOs 0 bis 21 sind RTC-fähig (können also zum Aufwecken aus dem Deepsleep verwendet werden).
  • GPIOs 26 bis 32 werden für interne Zwecke verwendet und können/sollten nicht anderweitig benutzt werden. 35, 36 und 37 müssten jedoch für das Modul „ESP32-S3-WROOM-1-N8R2“ nutzbar sein. Hier wird der Chip „ESP32-S3R2“ verwendet mit 8 MB Flash und 2 MB PSRAM (angebunden über Quad-SPI).

„SPI0/1: GPIO26-32 are usually used for SPI flash and PSRAM and not recommended for other uses. When using Octal Flash or Octal PSRAM or both, GPIO33~37 are connected to SPIIO4 ~ SPIIO7 and SPIDQS. Therefore, on boards embedded with ESP32-S3R8 / ESP32-S3R8V chip, GPIO33~37 are also not recommended for other uses.“

GPIOs


1 „Gefällt mir“

Was auch spannend wäre: Kann man an den USB-OTG Port direkt einen USB-Stick anschließen und spart sich damit den ganzen SD Slot?

link da las…

Vlt. kann sich da was abgucken… :smiley:

Ich habe am Wochenende ein Board auf Basis des Unexpected Maker ProS3 erstellt. Neben dem ProS3 benötigt man nur einen einzigen Widerstand. Das Board hat einen zweiten LDO, welcher im Sleep Mode automatisch abschaltet. Laut Video-Versuch von UM verbraucht das Board im Batterie-Betrieb während dem Standby unter 30 uA. 4 IOs wären noch übrig.

Die Software kompiliert und läuft auf dem ESP32-S3-DevKitC-1 (ohne Peripherie) zumindest mal. Serielle Ausgabe über USB-OTG funktioniert auch. Nun warte ich auf die Platine und das Board.

Die Nutzung von OTG könnte ich mir so vorstellen, dass ein Mass Storage emuliert wird, welcher wiederum auf die SD-Karte zugreift. So könnte man die Box einfach an den PC anschließen und Dateien hochladen.

Ich muss zugeben, dass mir gar nicht klar war, dass der Schaltplan dazu online ist. Ich verlinke ihn mal: https://raw.githubusercontent.com/UnexpectedMaker/esp32s3/main/schematics/schematic-pros3.pdf.

D.h. du hast jetzt auch wieder unser klassisches „Sandwich-Design“ mit Develboard und Carrier-PCB verwendet?

Was hast so an Features eingebaut? Ohne Port-Expander?

Gut, wäre natürlich auch nicht schlecht, wenn man ohne CH340 auskäme. Wenn das also alles so geht - umso besser.

Was mich ja brennend interessiert ist der SD-Durchsatz beim S3. Dazu habe ich bisher leider noch nix gefunden.

Ja genau, das wäre perfekt. Noch nicht probiert, aber so könnte es gehen:

1 „Gefällt mir“

Genau. Der ProS3 lässt sich wahlweise per Stiftleiste oder direkt als SMD per „castellated holes“ löten.

Ja, ohne Port-Expander.

  • MAX98357a
  • PN5180 (ohne IRQ/Wakeup)
  • SD-Card über SPI
  • 3 Buttons
  • Neopixel
  • Drehencoder
  • Anschluss für Kopfhörer-Platine

Werde ich berichten, sobald die Hardware da ist.

2 „Gefällt mir“

Du bist aber mutig :rofl:.
Aber gut, dann haben wir gleich jmd., der auf einem s3 testen kann, ob das da auch „doof“ ist :slight_smile:
Cool!

Aufgrund des flexiblen IO-Mappings ist man ja nicht auf SPI beschränkt und kann immer noch MMC verwenden. Ich werde mir den Unterschied anschauen.

@tuniii Weißt du eigentlich, ob wir irgendwie global einen Parameter haben (ohne ihn selbst definieren zu müssen), anhand dessen der Compiler „weiß“: ESP32S3?
Ich vermute mal, dass es hier und da eh spezifische Anpassungen geben wird in Abgrenzung zum ESP32, aber was ich auf jeden Fall jetzt schon sehe, ist eine GPIO-Obergrenze von 47 statt 39. Da würde ich in die Port.h ein abhängiges #define reinmachen, das MAX_GPIO auf 39 bzw. 47 setzt. Und alle 39 im Code gegen MAX_GPIO austauschen.

Ja, über den Präprozessor:

  • CONFIG_IDF_TARGET_ESP32 → ESP32
  • CONFIG_IDF_TARGET_ESP32S3 → ESP32-S3
1 „Gefällt mir“

Meinst du ESPuino?
Habe das eben mal versucht und bin in verschiedene Probleme beim Kompilieren gelaufen.

  • Dog-Feed in web.cpp
  • ESP32Encoder-Library; nach nem Update ging’s, aber danach lief das Abspielen von SD auf dem ESP32 nicht mehr gescheit.
  • Bluetooth

Weiter habe ich es jetzt noch nicht probiert.

Ja, ich hab mal meinen aktuellen Stand gepusht:

Bluetooth habe ich erst mal deaktiviert. Müsste man sich erst genauer anschauen. Ich habe eigentlich für die Zukunft die Hoffnung, dass Wifi und BLE parallel funktionieren und man keinen speziellen Bluetooth-Mode braucht.

Update:
Der S3 unterstützt kein Classic Bluetooth und damit kein A2DP Sink.

Irgendwas ist halt echt immer.

Schade, denn dann fällt A2DP-Source auch weg (Bluetooth Kopfhörer).

Heute ist endlich das S3-Board eingetroffen. Hier nun die ersten Ergebnisse (Arduino 2.0.5):

  • SD-Karte: SD und MMC jeweils 182 kbyte/s per Web-Upload → Da beides gleich langsam ist, gehe ich davon aus, das etwas anderes der limitierende Faktor sein muss. Vermutung: Wifi-Durchsatz.

  • Audio: Funktioniert

  • Neo-Pixel: Funktioniert

  • PN5180: SPI-Pins können mit der aktuellen Lib nicht frei gewählt werden → Lib gepatch → Funktioniert

  • Drehencoder: Funktioniert noch nicht sauber

2 „Gefällt mir“

Grummel. Da hatte ich mir echt mehr versprochen :woman_shrugging:.
Danke für’s Testen!

SD-Karte: SD und MMC jeweils 182 kbyte/s per Web-Upload → Da beides gleich langsam ist, gehe ich davon aus, das etwas anderes der limitierende Faktor sein muss. Vermutung: Wifi-Durchsatz.

Hmm da stimmt etwas nicht. Wir haben mit 2.0.5 kanpp 400KB/s erreicht…

Na das ist ja jetzt echter Zufall, ich habe vor einigen Minuten einen Pull-request in die PN5180 Bibliothek übernommen der aus dem April diesen Jahres stammt. Ich hatte das schlicht übersehen.
Ein eigener Versuch die SPI Klasse konfigurierbar zu machen war damals kläglich gescheitert.

Also unabhängig von S3-Thema hier, kannst Du Deinen Patch mit der aktuellen PN5180 Version vergleichen und mitteilen ob Alles so passt?

Danke @tuniii

Ja, in der Tat. Die reine Wifi-Durchsatzrate beim Upload beträgt 752 KB/s.
Ich hab ein Issue bezüglich MMC und S3 auf Github gefunden. Die gleichen Meldungen bekomme ich auch im Log. Wurde wohl im IDF bereits behoben, allerdings soll das erst mit Arduino 3.0 kommen.

Ja, funktioniert einwandfrei. Damit kann man das SPI-Objekt übergeben und die benötigten Pins zuvor selbst setzen.

1 „Gefällt mir“

Ich hab ein Issue bezüglich MMC und S3 auf Github gefunden. Die gleichen Meldungen bekomme ich auch im Log. Wurde wohl im IDF bereits behoben, allerdings soll das erst mit Arduino 3.0 kommen.

Ich habe einen jetzt mal einen Lolin-S3 SD-MMC Benchmark durchgeführt und mit der Geschwindigkeit des Lolin-D32-Pro verglichen: Die Lese-/Schreibgeschwindigkeit ist auf beiden Systemen exakt gleich.
So sieht der Testaufbau aus:

Initialisierung habe ich so durchgeführt:

    pinMode(2, INPUT_PULLUP);
    // clk, cmd, do
    SD_MMC.setPins(14, 15, 2);

Platformi.ini:

[env:lolin_s3]
platform = espressif32
board = lolin_s3
;board = lolin_d32_pro
framework = arduino
monitor_speed = 115200

Also mit SD-MMC (1Bit Modus) kann ich keine Probleme erkennen…