Support for esp32-s3

[Jona2892]

Hallo,

ich arbeite mit einem esp32-s3 (esp-idf) und dem BT815 und laufe hier in einige Probleme. Um überhaupt auf dem esp32-s3 die lib zum laufen zu bringen musste ich eigentlich nur die HOST_ID auf SPI2_HOST setzen.
Allerdings bekomme ich immer einen Watchdog Trigger, den ich nicht richtig verstehe.
Ich lasse die touch Kalibrierung laufen und die Funktionspi_device_polling_transmit(EVE_spi_device_simple, &trans); endet immer im WDT.
Noch bin ich auf der Suche nach der Ursache, aber ich möchte heir schon mal fragen, warum zwei spi_devices angelegt werden? Und wieso die unterschiedlichen Frequenzen?

FT800-FT813/EVE_target.c

Lines 383 to 389 in aa717f3

	spi_bus_initialize(HSPI_HOST, &buscfg, 2);
	spi_bus_add_device(HSPI_HOST, &devcfg, &EVE_spi_device);
	devcfg.address_bits = 0;
	devcfg.post_cb = 0;
	devcfg.clock_speed_hz = 10 * 1000 * 1000; //Clock = 10 MHz
	spi_bus_add_device(HSPI_HOST, &devcfg, &EVE_spi_device_simple);

Liebe Grüße

[RudolphRiedel]

Moin,

der SPI wird mit und ohne DMA genutzt. Für so einfache Sachen wie etwa Abfragen ob der Co-Prozessor beschäftigt ist oder welches Objekt berührt wurde, da lohnt sich DMA einfach nicht, zum einen ist da der Overhead, zum anderen braucht man das Ergebnis ohnehin direkt. DMA ist für das Display-Update, also wenn es darum geht mehr als nur ein paar Bytes zu schicken, das was richtig lange aufhalten würde, wenn man da drauf warten würde.
Die unterschiedlichen Geschwindigkeiten kommen zum einen daher, dass meiner Erfahrung nach deutlich schneller geschrieben als gelesen werden kann, zum anderen muss die Initialisierung ohnehin mit weniger als 11MHz erfolgen.

Viel gemacht habe ich mit den ESP32 jetzt nicht wirklich, ich mag die Dinger eigentlich nicht so, mir ist die Dokumentation zu dünn und man ist im Grunde genommen dem ESP-IDF ausgeliefert. Und dessen Performance beeindruckt mich nicht so.
Aber vor allem hatten ich bisher noch keine Verwendung für WLAN.

Was den Watchdog angeht, ich habe rtc_wdt_feed() und vPortVield() am Ende von meiner Hauptschleife:
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/examples/EVE_Test_ESP32_PlatformIO/src/main.c

Warum das überhaupt notwendig ist habe ich nie ergründet, gerade mit DMA läuft die Schleife ja nun nicht wirklich lange und wenn da schon ein RTOS drunter ist sollte das sich eigentlich um sowas kümmern.

[dstulken]

[Google translated] I haven't really done much with the ESP32, I don't really like those things, the documentation is too thin for me and you're basically at the mercy of the ESP-IDF. And its performance doesn't impress me that much.
But most importantly, I haven't had any use for WiFi yet.

The ESP32 has been wonderful in my experience. Via Arduino, the abstraction is such that you basically don't have to care about ESP-IDF or FreeRTOS at all, but the expanded capabilities are available if/when you do, so porting existing code to or away from the Espressif chips is a snap. Having two cores is great, and Wi-Fi is fantastic for OTA updating of "sealed" products without externally accessible maintenance ports. The ESP32s are cheap, plentiful, and unlike other chips (STM32, etc), they weathered the chip shortage extremely well, which was a blessing for those of us who used them in commercial products.

I know you've been doing a ton of DMA work to squeeze the most out of these chips with your library - and perhaps have been disappointed with their SPI performance relative to other chips. But my experiences of them, with your library, have been nothing but positive.

[RudolphRiedel]

Well yes, I had to work with ESP-IDF since the ESP32 Arduino SPI class does not support DMA.
And I was not at all impressed with the performance.
But most importantly I do not use WLAN, I mostly need CAN-FD and so the ESP32 is just not for me.
So yes, the chip shortage is no fun for me but then I am not selling any hardware.

[RudolphRiedel]

Ich habe endlich ein Board mit ESP32-S3 auf dem Tisch und bisher kommt hier gar nichts aus dem SPI raus.

Das rtc_wdt_feed() musste ich auskommentieren, damit gab es Fehler beim Compilieren durch das Include.
HSPI_HOST habe ich durch SPI2_HOST ersetzt, da werde ich noch einen einstellbaren Parameter erstellen.

Ich habe dieses Board hier: https://bpi-steam.com/Leaf_S3_doc/en/
https://github.com/BPI-STEAM/BPI-Leaf-S3-Doc/blob/main/sch/BPI-Leaf-S3-Chip-V0.1A.pdf
Und es nervt schwer, angefangen damit das der USB-C stecker nur in einer Position gesteckt funktioniert.
Vielleicht war das auch noch falsch auf dem V0.1.1 Board das ich erhalten habe.

Ich habe GPIO10 bis GPIO14 konfiguriert und hänge da mit dem Logic-Analyzer drauf, PD an 14 funktioniert scheinbar, CS am 10 sieht sehr seltsam aus und auf SCK = 12, MOSI = 11 sowie MISO = 13 passiert gar nichts.
CS ist nicht unter der Kontrolle meines Programms, der Pin wackelt auch wenn ich TFT_touch() auskommentiere.
Und zwar geht der alle 430ms für 41ms auf low.
Im Moment glaube ich nicht mal, dass da meine Software drauf läuft.

Also zumindest in PlatformIO ist das alles noch etwas merkwürdig.
Die Anzahl der Boards mit dem ESP32-S3 ist noch sehr klein, wobei PlatformIO nicht mal alle Boards listet die mit Espressif 32 in Version 5.1.1 installiert werden.
Und bei allen Boards steht für RAM 320 KiB obwohl die ESP32-S3 laut Datenblatt 512 KiB haben.

[RudolphRiedel]

Ok, gefunden und gefixt.

spi_bus_initialize(HSPI_HOST, &buscfg, 2);
-> spi_bus_initialize(SPI2_HOST, &buscfg, SPI_DMA_CH_AUTO);

Auf das SPI2_HOST kommt man ja praktisch automatisch.
Aber das "2" für den ESP32-S2 nicht mehr SPI DMA Channel 2 auswählt, sondern DMA abschaltet, bzw. den SPI ganz abschiesst - fies.
Zum Glück funktioniert aber sowohl SPI2_HOST als auch SPI_DMA_CH_AUTO ebenfalls mit dem ESP32 ohne -S3.

[jblazeg]

Hi Rudolph, das heißt, man ist nach wie vor auf die ESP-IDF angewiesen, wenn man DMA nutzen will am ESP32-S3?

Gerade gefunden:

reworked the ESP32 support code to no longer use ESP-IDF for DMA transfers, this is slower and blocking but Arduino-ESP32 got siginificantly faster by now and using only the SPI class allows other SPI devices more easily

Sehr gut!

[RudolphRiedel]

Ja, bisher ist das leider so, wie bei den meisten anderen Arduino Cores auch, entweder geht man an der SPI Klasse vorbei und ist entsprechend dazu nicht mehr kompatibel, oder man bekommt kein DMA.

[jblazeg]

Hast du evtl ein Beispiel. Mein Idee war den Eve mit einem eigenen SPI anzusprechen und anderen SPI Geräte über einen zweiten.

[RudolphRiedel]

Ich habe DMA per ESP-IDF ja gerade wieder eingebaut, aktiviert über das vorhandensein von EVE_USE_ESP_IDF.
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/EVE_target/EVE_target_Arduino_ESP32.h
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/EVE_cpp_target.cpp

Eigentlich wäre das Makro um DMA zu aktivieren EVE_DMA, beim ESP32 nutze ich das allerdings um alles was zwischen EVE_start_cmd_burst() und EVE_end_cmd_burst() in einen Puffer zu schreiben und entweder wird dieser Puffer per Arduino API übertragen, oder über DMA mit ESP-IDF wenn EVE_USE_ESP_IDF vorhanden ist.
Die Übertragung als Puffer ist mit Arduino SPI Klasse schneller als würde man in 32 Bit Happen oder gar einzelne Bytes übertragen - was ja jetzt nicht so richtig überraschend ist.
Wobei der Arduino-ESP32 core noch die offizielle Arduino API erweitert hat und etwa SPI.writeBytes(ptr, count) anbietet.

Ich würde gerne für normale Transfers die Arduino SPI Klasse verwenden, da diese inzwischen schneller ist als ESP-IDF, so im Gegensatz zu dem vorherigen Stand als die Arduino Klasse das ESP-IDF verwendet hat.
Aber in ersten Versuchen hat die SPI Klasse gar keine Tranfers gemacht, wenn ich den SPI über ESP-IDF konfiguriert habe.

Ausprobiert habe ich das mit einem ESP32-S3.

Ah, um ESP-IDF zu nutzen muss auch EVE_init_spi() aufgerufen werden, ich muss wohl auch mal wieder die Beispiele aktualisieren.