Ich würde mich freuen, wenn sich der Ein oder Andere mit Tests anschließen würde. Es ist aber auf jeden Fall Beta. D.h. es ist nicht unwahrscheinlich, dass manche Dinge fehlerhaft sind. Was aktuell z.B. nicht funktioniert, ist der Dateiupload via Webtransfer oder FTP. Also oberflächlich funktioniert er, aber die Dateien sind im Anschluss nicht da und man sieht auch eine Fehlermeldung beim Start des Transfers.
Ausblick:
Sobald wir da einen guten Stand erreicht haben, wird der umgebaute Code der neue Master-Branch werden.
Für diejenigen, die sich fragen, was es mit dem Refactoring auf sich hat:
Es ist so, dass ich im Oktober 2019 dieses Projekt gestartet hatte und nie geplant habe, dass es mal so groß wird. Im Laufe der Zeit kamen immer mehr Features dazu, was sich natürlich auch in der Länge des Quellcodes widerspiegelt. Infolgedessen wurde die main.cpp immer länger und damit auch unübersichtlicher. @tuniii hat das Ganze nun in zahlreiche Module gesplittet. Es sind jetzt also viele Dateien, diese sind jedoch übersichtlicher/kürzer.
Hi mal eine Frage eines Ahnungslosen . Ist das für den Compiler und das fertige Programm auch „übersichtlicher“ ? .
Auch von mir vielen Dank an euch beide
Geht nur um bessere Lesbarkeit. Dem Compiler ist es wurscht, wobei ich insgesamt vermute, dass das Kompilat geringfügig größer wird, da es nun sicher bisschen mehr Zeilen sind, als vorher.
@tuniii Hast du auf einem WROVER oder WROOM getestet?
Ich teste hier gerade auf einem Lolin32 mit PN5180 - einem WROOM also. In den Settings habe ich so ziemlich alles (außer Port Expander) aktiviert, was Speicher frisst (z.B. auch MQTT).
Folgende Probleme:
a) Wenn bereits ein Webstream läuft und ich öffne die Webgui, dann werden mir dort keine Files im Browser angezeigt.
b) Läuft keine Musik und ich lade via Webgui ein File hoch, dann klappt das vordergründig ohne Fehler. Die Datei ist allerdings 0 Bytes groß. Dementsprechend kann man sie nicht mehr abspielen.
c) Läuft keine Musik und ich lade via FTP ein File auch, so passiert das Gleiche, wie bei der Webgui.
Ich teste aktuell auch auf einem Lolin32 mit PN5180 - also auch WROOM. Szenario b) und c) funktionieren bei mir. Ich kann die Datei danach abspielen. Szenario a) habe ich noch nicht ausprobiert. Wie viel Heap hast du denn nach dem Start zur Verfügung (bei mir sind es ca. 130k) und wie viel im Fehlerfall? Kannst du deine settings.h zur Verfügung stellen? Eventuell kannst du dir folgenden Commit holen, damit du per /info im Browser die Heap-Auslastung siehst.
In meinem Fork habe ich das Firmware-Update über HTTP implementiert. Auch das braucht auf einen Schlag 40k RAM während des Updates und funktioniert bisher bestens.
Kann die Anzahl der Dateien auf der SD-Karte eine Auswirkung haben? Meine ist aktuell ziemlich leer.
Oh, da warst ja fleißig Hätte ich vorher bei dir mal reinschauen müssen, dann hätte ich den Fix für FTP/MQTT übernehmen können.
Zu deinen Fragen: Offenbar war tatsächlich die Karte voll. Eieiei Sorry. Wegen dem Rest muss ich heute Abend mal schauen. Web/FTP-Transfer waren allerdings vom Durchsatz relativ langsam.
Webupdate muss ich mir mal anschauen. Klingt interessant.
Web-Update geht beim 4MB Flash aber nur ohne Bluetooth, da es ansonsten zu groß ist. Ich werde dem Update noch einen Ladebalken verpassen und zusätzlich noch einen Recovery-Mode einbauen. Damit man auch eine fehlerhafte Software erneut über Web flashen kann. Der Recovery-Mode hat sich in einem anderen Projekt schon bewährt.
Bei mir im Fork habe ich noch die Partitionierung angepasst, da SPIFFS ja überhaupt nicht verwendet wird.
Im übrigen könnte man auch die HTML-Seiten als gzip im Flash ablegen. Damit würde man auch noch ein paar KB Flash sparen oder man überlegt, ob man den angezogenen Java-Code und Style-Sheets wie z.B. Bootstrap und Co. noch mit in den Flash legt. Dann hätte man auch Bootstrap im Recovery und AP Mode.
Ich werde in nächster Zeit in meinem Fork arbeiten. Falls irgendetwas für die Allgemeinheit interessant sein könnte, dann kann man es ja hochholen.
Im Endeffekt ist die Frage, ob man das alles dauerhaft im Flash halten möchte oder es halt nicht einfach von SD holt. Damit verknüpft sind aus meiner Sicht zwei Dinge:
a) Die Webgui wird aktuell zweisprachig geführt. Das war am Anfang ok, zwischenzeitlich, als es jedoch viele Änderungen gab, einigermaßen nervig. Mario hat mal eine Js-Library getestet für i18n (Achtung, uralter Stand: GitHub - mariolukas/Tonuino-ESP32-I2S at feature/i18n). Das wäre ein Grund, einfach alles auf SD zu legen.
b) Damit greife ich deinen Punkt auf mit Bootstrap lokal: Mittels Webpack könnte man die ganzen Abhängigkeiten einsammeln und in ein File stecken, welches auf SD lebt. Die Idee stammt auch von Mario. Finde ich ehrlich gesagt nicht schlecht, aber habe mich damit noch nicht befasst.
SD-Karte wäre natürlich auch eine Option. Man muss nur aufpassen, dass das Frontend dann auch immer zum Backend passt. Es erhöht damit etwas die Komplexität bei der Einrichtung oder der ESP müsste sich dann darum kümmern, dass die richtigen Dateien auf der SD-Karte liegen.
Richtung Webpack wäre ich jetzt auch gegangen. Ich schaue gerade, ob ich aus dem aktuellen Web-Interface eine Vue App mache und dann alles in eine Datei gegossen wird.
Das ist genau der Punkt, weswegen ich das noch nicht gemacht habe.
Im Endeffekt war der Leidensdruck bisher auch nicht sonderlich groß, diesen Weg dann wirklich zu gehen. Weil das Flash ist bisher nicht zu klein und Web einfach mitzuflashen funktioniert recht komfortabel. Und nachdem sich die GUI aktuell (hinsichtlich Änderungen) einigermaßen stabilisiert hat, sind die Anpassungen dort für zwei Sprachen jetzt auch nicht sooo groß (obgleich es natürlich dennoch besser ist, Struktur von Inhalt zu trennen; das ist mir schon klar).
Im Endeffekt habe ich da ne ganze Reihe von Punkten auf der Agenda, die mir wichtiger sind. Und nicht zuletzt, da möchte ich keinen Hehl draus machen: Ich habe schon hunderte Stunden in ESPuino investiert… ich muss da auch nicht (mehr) jeden Abend dransitzen
Sei es drum: Für mich ist jetzt noch der Punkt offen, dass der Transfer via Web und FTP recht langsam war.
Ich baue mal einen Log ein, damit man die durchschnittliche Upload-Geschwindkeit angezeigt bekommt und das dann vergleichen kann. Zumindest für Upload über Web.
Jeweils mit MMC über Web und einer 100MB Datei getestet. Kommt aber nicht an die 372 kB/s, welche auf Github stehen, ran.
master: 286 kB/s
refactoring: 301 kB/s
Selbst wenn ich das eigentliche Schreiben auslasse und die Callback ohne Code aufgerufen wird, ändert das nichts groß an der Zeit.
Meine Vermutung: Eine der angezogenen Libs braucht nun mehr CPU-Zeit.
Wie ich ja zuvor mal erwähnt habe, kann sich durch ein Update der angezogenen Libs das Systemverhalten verändern. Dadurch ist die Software aktuell nicht reproduzierbar. Heute kann man etwas anderes bekommen als vor 2 Wochen, obwohl sich ESPuino nicht geändert hat. Quasi wie ein Pull Request durch die Hintertür
Ich werde in meinem Fork die Versionen festpinnen und nur bei Bedarf updaten.
.
Sorry. Wegen dem Rest muss ich heute Abend mal schauen. Web/FTP-Transfer waren allerdings vom Durchsatz relativ langsam.
.
