ESP32 Port inkl. Webinterface

#141

Ich wäre ja immer noch für einen “normalen” Webserver (http) mit passendem JavaScript.
Dan ln könnte man nicht nur Dateien hochladen sondern auch gleich Playlisten erstellen und Karten anlernen/konfigurieren.
Leider muss ich aber zugeben daß ich davon bisher so gar keine Ahnung habe :roll_eyes:

#142

Aber @Christopher :sunglasses:

Ich finde Webdav oder FTP schon ganz gut, weil ich dann ganze Ordner synchronisieren kann ohne daneben stehen zu müssen. Dann ist die Geschwindigkeit auch nicht so kritisch.
Karten / Playlists konfiguriren wäre natürlich klasse

#143

Ich habe einfach mal mit dem FTP Server auf dem ESP angefangen, weil es die die kleinste Hürde war, bei der man keine zusätzliche Infrastruktur (NAS etc.) braucht. Einfach Filezilla, einen ganzen Ordnerbaum drag-doppen und los geht’s. Bei existierenden Files fragt er nach, was zu tun ist. Wen man dort “überschreiben wenn Größe unterschiedlich” anklickt, geht der Rest automatisch.

HTTP direkt auf dem ESP wäre natürlich nochmal sehr viel eleganter und eliminiert auch die Notwendigkeit einer weiteren FTP Software.
Aber einen Server für den ESP zu schreiben der (mindestens) diesen Komfort bietet, traue ich mir auch nicht zu, dafür kenne ich mich im Webumfeld zu wenig aus.

Ich persönlich werde was “push” angeht erst einmal bei dem FTP bleiben.

Spannend wäre aber noch ein “PULL”, d.h. der ESP versorgt sich selbst mit den neuen Files - das bedingt aber eine externe Quelle, vermutlich i.d.R. ein NAS. Das werde ich mir bei Gelegenheit mal anschauen und einen Proof of Concept hacken. Ob HTTP oder auch FTP muss ich nochmal schauen. Letzteres ist bei den meisten NAS mit einem Klick aktiviert und erfordert keine Skripte. Ich denke damit werde ich mal anfangen.

#144

Ein HTTP Server ist überhaupt kein Problem, das habe ich in einem dev Zweig in meinem Repository schon mal probiert. Den Server gibt es als Library und die nötigen Anpassungen sind minimal.

Das Problem ist jetzt die Anpassung, damit man mehr als eine Datei zur Zeit hochladen kann usw. also der ganze interaktive kram der später im Browser laufen soll/muss.
Mal sehen ob ich dazu Zeit finde.

#145

… genau das meinte ich.
Einzel Dateiupload ist Peanuts. Ich stelle mir eine Sync-Oberfläche, die einen Abgleich oder Upload einer Ordnerstruktur erlaubt schon Anspruchsvoll vor. Oder überschätze ich das?

#146

Kurzes Update:
Ich finde keinen FTP Client Code auf den man einfach aufsetzen könnte.

Der genannte WebDav code setzt auf SD_FAT auf, welche - nach ersten Versuchen - nicht für ESP32 funktioniert. Es wäre also das gesamte File-handling auf die espressif SD Bibliothek umzubauen… Das ist ne Menge und Fehleranfällig…
Oder ich übersehe was…(?)

#147

Schade. Ja, das ist etwas nervig es umzuschreiben bzw. ich wüsste nicht, wie es einfach geht…

#148

Hello,
A big thank you for this evolution on ESP32 which I am making a version with the code in English and a French voice. However, I have a translation problem. I did not find the mp3 file number 600, which is read on line 1147, nor the corresponding text in soundfiles.txt files :

#149

Hi, these files are only for this tonuino version and an Add-On for the color menue. A guy from that forum crated that for me. The number 600 ask “please chose a color”

#150

Thanks for the text! I will be able to generate the corresponding mp3

Another question about the code, about the admin mode.

What does it do, because it does not seem to be used in the code?

Knowing that it is not proposed when creating a new map, how to define a map in admin mode? Is it a specific card that we define in the hard code?

#151

The Admin mode is not used, this was part of the Master version wich i have adapted and expand to work with the esp.

#152

Ok, thanks for the precision.

#153

Wenn die Tasks korrekt gestartet werden und konfiguriert sind sollte das RTOS automatisch dafür sorgen dass jeder Task entsprechend Zeit auf dem Prozessor bekommt. Anders als bei anderen Betriebssystemen ist es ja gerade beim RTOS so dass die Tasks NICHT kooperieren müssen (also “die Kontrolle abgeben”) sondern das RTOS die Zeit in “Scheiben” aufteilt und die unter den Tasks verteilt. Aber auch wenn das Warten auf das Freiwerden des Buffers richtig gemacht ist (was ich bei einer Library jetzt mal hoffen würde) sollte das funktionieren. Man muss aber natürlich die parallel laufenden Aufgaben schon jeweils in einen separaten Task packen, sonst gehts natürlich nicht.

#154

Leider ist die Library nicht richtig gemacht. Die Library verbraucht so viel Zeit wie sie bekommt in einer while Schleife.
Wenn der Thread jetzt auch noch eine hohe Porträt hat (damit die Widergabe nicht stockt) wird eine Menge Zeit sinnlos gebraten.

#155

Welche Library benutzt ihr denn genau?

#156

Die Library bummelt im loop und wartet auf das Freiwerden des Puffers. Ich hab das bei mir etwas optimiert (zusätzlich delay) und es klappt so ganz gut. Generell glaube ich inzwischen, dass man nicht zu viel vom rtos erwarten sollte :wink: bzw. auch die Tasks gut steuern muss.

#157

Also das Problem ist ja diese Funktion hier:

inline void await_data_request() const
{
  while ( !digitalRead ( dreq_pin ) )
  {
    NOP() ; // Very short delay
  }
}

Eine einfache Möglichkeit wäre sicher an Stelle des NOP() ein delay() einzusetzen, dass gerade so lange ist dass man auf jeden Fall den Puffer noch füllen kann bevor die Wiedergabe unterbricht.

Eleganter wäre es aber

  • den dreq_pin auf einen Interrupt zu legen
  • Funktion die den Puffer füllt in einem hoch priorisierten Task an einer Semaphore warten zu lassen
  • Im Interrupthandler diese Semaphore freizugeben

Im Ablauf wäre das dann so:

  • Auch während der Wiedergabe kümmert sich der Prozessor die meiste Zeit um die weniger wichtigen Sachen (in einem oder mehreren niedrig priorisierten Tasks, z.B. Tastendrücke, Webinterface).
  • Sobald am dreq_pin die Flanke erkannt wird, startet der Interrupthandler, gibt die Semaphore frei, und beendet sich gleich wieder.
  • Da der am höchsten priorisierte Task (der den Puffer füllt, und nur das) jetzt an der Semaphore weitermachen kann, wird dieser nach dem Interrupthandler als erster ausgeführt und füllt sofort den Puffer.
  • Danach sperrt er die Semaphore wieder und die niedrig priorisierten Tasks bekommen wieder Ausführungszeit.

Und dann funktioniert dass auch mit dem RTOS :wink:

So wie das aktuell implementiert ist bekommst Du quasi jeden Prozessor oder Betriebssystem ausgelastet. Es scheint mir so dass die Library eher auf den Betrieb auf deutlich schwächeren Prozessoren ausgelegt ist, bei denen man ohnehin nicht davon ausgeht dass man parallel etwas anderes macht.

Das kann an auch irgendwo nachlesen, (ich dachte eigentlich in der Adafruit Doku), aber finde grade nur den Link für die Arduinoversion (die genau diesen “Fehler” macht).

#158

Genau das (mit dem Semaphore) habe ich auch noch geplant, aber irgendwie fehlt mir gerade die Zeit dazu. Wenn dann würde ich die Library komplett überarbeiten und auch solche Dinge wie die MP3 Streams rausschmeißen (Single Responsibility Prinzip). Das muss eine eigene Klasse übernehmen.

Außerdem habe ich vor ein paar Tagen entdeckt, das es eine Lib von Adafruit gibt, evtl. ist die besser aufgebaut.

Das Problem bei der “schnellen” Lösung ist ja auch, das der Buffer sich (je nach BitRate) unterschiedlich schnell leert.

#159

Das mit dem Interrupt ist in jedem Fall die eleganteste und zuverlässigste Lösung.

In der Lib von Adafruit ist es soweit ich das gesehen hab ähnlich schlecht gelöst…

#160

So ist es aktuell bei mir.

Mir fehlt aktuell leider auch die Zeit, aber hört sich nicht zu aufwändig an.
Wie wartet der Buffer-Task denn? Ist das nicht auch wieder ein loop?
Hast Du ein Beispiel, Links ?

Grundsätzlich würde ich die Library ruhig erweitern. Am Ende ist es ein MP3 Player und keine Flugzeugsteuerung :wink: