Verstehe ich das richtig, dass sich das Problem damit quasi selbst gefixt hat?
Ja genau,durch Woodoo oder Magie oder Fix in irgendwas.
Daher würde ich Euch bitten das durch eine 2. Meinung zu bestätigen…
OH NEIN, mein Fehler! Kein Woodoo, sondern fehlendes „Clean“ + „Build“.
In der Weboberfläche unter Info bekomme ich ESP-IDF version: v3.3.5-1-g85c43024c.
Sorry, Alles auf Anfang…
War wohl zu spät gestern 
Bin das Umlautproblem heute in Ruhe nochmal angegangen und aus meiner Sicht reichen diese Zeilen in Common.h für den Bugfix:
inline void convertUtf8ToAscii(String utf8String, char *asciiString) {
#if ESP_ARDUINO_VERSION_MAJOR >= 2
strncpy(asciiString, (char *) utf8String.c_str(), utf8String.length() / sizeof(asciiString[0]));
asciiString[utf8String.length()] = 0;
return;
#endif
...
Dateinamen sind in Arduino1 UTF-8 kodiert und in Arduino2 direkt Unicode. Ob der obige Code jetzt so optimal ist - Da muss noch ein C-Experte drüberschauen. Die Funktion ist dann etwas unglücklich benannt, evt. hier lieber convertFileToAscii ?
Auf jeden Fall kann ich jetzt Dateien und Ordner mit Umlauten über Web-UI abspielen.
Es gibt noch Problem wenn CACHED_PLAYLIST_ENABLE aktiviert ist:
„playlistcache.csv“ erzeugt mit Arduino1 ist nicht kompatibel mit Arduino2.
Beim Wechsel auf 2 müssten einmalig alle playlistcache.csv gelöscht oder eine Versionierung eingebaut werden. Wie könnte man das lösen?
1 „Gefällt mir“
Ein kleiner Header könnte helfen. Wenn der header fehlt: löschen und neu erstellen.
Wäre was für den dev-branch. Oder?
Sollen wir dort den aktuellen Stand von Arduino 2 einbauen?
Ja Header-Zeile „Version#2“ ist eine gute Idee! Damit könnte man wieder beliebig zwischen Arduino 1/2 umschalten ohne Probleme.
Wäre was für den dev-branch. Oder?
Tja das ist mir recht wurscht. @biologist, in welches Schweinerl hätten Sie’s denn gern?
Könnte dafür einen PR erstellen so oder so. Aus meiner Sicht kann das auch in den Master da alle Änderungen über einen Compiler-Schalter laufen (also nichts kaputt machen können). Das ist hier auch kein neues Feature sondern die Zukunft…
Das ist für mich ok, wenn du dafür einen PR für den Master machst.
1 „Gefällt mir“
Technisch gesehen ist es trotzdem ein Feature 
Hm, spontan würde ich sagen das ist nicht wirklich sinnvoll bei jeder Änderung zu überlegen ob sie in Dev oder Master kommt.
Zudem macht es die Entwicklung grundsätzlich schwieriger. Z. B. arbeite ich an dem KConfig Feature-Branch und synchronisiere diesen (durch Rebase) mit dem Dev-Branch. Wenn jetzt parallel im Master eine neue Build-Option hinzugefügt wird gibt es einen Konflikt beim Sync von Dev und Master (beim nächsten Release). Oder ich muss sehr aufwendig beim Arbeiten am Feature-Branch Dev und Master beobachten und Commits aus dem Master manuell in meinem Feature-Branch mitführen.
Lange Rede, kurzer Sinn: Meiner Meinung nach sollten alle PRs (außer eventuell kritische Bugfixes) gegen den Dev-Branch erstellt werden.
2 „Gefällt mir“
So ich habe zu den Umlautproblemen ein Bugfix erstellt:
Für die Playlistcache-Datei habe ich auf einen zus. Header für die Versionierung verzichtet sondern verwende für Arduino 2 einen neuen Dateinamen, das ist wesentlich einfacher und funktioniert fein.
Einziger Nachteil, beim Umschalten 1/2 liegen dann zwei Cache-Dateien im Ordner von der nur eine verwendet wird…
Beim Testen ist mir noch ein kleiner Bug aufgefallen der so jetzt auch im aktuellen Master schlummert:
Beim Umbennenen eines Verzeichnis unterhalb des Root wird die Playlistcache-Datei nicht gelöscht. Das klappt nur für Umbennenen von Dateien. Kann das jemand so nachvollziehen?
2 „Gefällt mir“
Hallo an alle
Auf diesen Beitrag von mir hat bisher niemand geantwortet. Mir ist eben eingefallen dass die meisten ja Torsten Boards benutzen und dort mit einem LOW die Spannung geschaltet wird mit HIGH aus. Dabei fällt das Problem nicht auf . Bei mir ist es umgekehrt.
Hiermit bitte ich nochmals ob das jemand nachstellen kann.
Ich habe Arduino v2 noch nicht ausprobiert, aber ich probiere mich trotzdem mal an dem Problem.
Ich glaube ich erwähnte das bereits, aber der POWER pin wird von fast niemandem für etwas anderes als die Peripherie verwendet.
Als ich damals die Power.cpp erstellt habe, war das auch das Verhalten. Power.cpp is ja grundsätzlich recht kurz gehalten.
Dann fiel mir auf, dass ich einen schöneren Start (sprich kein Knacken im Lautsprecher) erhalte, wenn ich Verstärker und Co. erst mit Strom versorge, wenn alle Initialisierungen durch sind. Ich kann mir vorstellen, dass hier deine Probleme begonnen haben.
In Power_Init() wird der POWER pin auf output gesetzt, aber nicht geschaltet. Oft heißt das er wird auf 0 gesetzt, aber vielleicht ist das auch Verhalten, was sich zwischen den Versionen geändert hat. Oder je nach Chip, Pin variiert. Die Idee ist aber, dass er hier erstmal aus bleibt. (Wobei ich mir gar nicht sicher bin ob das noch so ist. Du schreibst ja richtig dass bei den meisten LOW=An, also geht er hier vielleicht schon an und das Knacken wurde wo anders behoben. Nur für dich eben nicht, da LOW=Aus. Vielleicht ist der Pin beim ESP32 dann auch einfach undefiniert).
Du wirst meiner Ansicht nach mit dem POWER pin immer Probleme haben, da dieser für einen anderen Zweck gedacht ist und für niemanden in der Startphase wirklich kritisch ist. Du wirst immer mit Regressionen kämpfen müssen.
Als Lösung solltest du einen weiteren pin definieren (meinetwegen MAIN_POWER) und POWER einfach nicht mehr benutzen. Der POWER pin hört sich zwar so an als sei er für die Stromzufuhr, ist aber eher ein pin für den deepsleep.
Deinen MAIN_POWER pin schaltest du dann einfach als erstes in der main bzw. über neue Funktionen in der Power.cpp (wenn es reicht den erst nach dem port-expander) zu setzen.
PS: @biologist du hattest ja beim übernehmen der Power.cpp das ausschalten in power_init gelöscht. Weißt du noch warum?
Hi
danke für die ausführliche Antwort. Ich benötige den Pin ja nie zum Einschalten, das macht der LTC2954. Leider wird dieser dann durch das „Fehlverhalten“ direkt wieder ausgeschaltet ( siehe Datenblatt). Das hatte aber bis Anfang 2022 einwandfrei funktioniert.
Ich habe das jetzt mit einer Hardwareänderung umgangen. Ich führe den Power_Pin über eine Diode parallel zum Rotaryencoder_Button und bilde einen langen Tastendruck nach (Änderung in der System.cpp). Der Pin Kill am LTC2954 ist jetzt unbenutzt. Das klappt gut aber trotzdem würde es mich interessieren woran das liegt.
Es geht ja auch nicht wenn ich deine Power.cpp deaktiviere, hat also damit nichts zu tun. Ich hatte für Power_Pin GPIO13 ausgewählt und damit trat es zuerst auf. Ich habe dann verschiedene GPIO´s probiert, weil das Verhalten der GPIO´s nach Reset unterschiedlich ist. Mit GPIO 21 hat es dann wieder einige Zeit funktioniert …bis zu Arduino >1.6. Ich habe das auch mit einem Scope gemessen. Ist schon komisch.
Das habe ich schon gemacht und es hat anfangs auch geholfen.
VG
Hast du einen link zu den genannten Änderungen?
Folgendes würde mich interessieren: Ändert sich das Verhalten mit Arduino-Version oder hängt es an ESPuino Änderungen? Je nachdem gehört es nicht in diesen Thread.
Und wie „deaktivierst“ du die Power.cpp?
Nee , ist nicht viel. In main.cpp im Setup Power_Init und Power_PeripherialOn deaktiviert und stattdessen GPIO21 direkt auf HIGH geschaltet.
Später GPIO21 am Anfang von Setup geschaltet.
Seitdem das nicht mehr funktioniert die Hardwareänderung und in
System.cpp
220 Power_PeripheralOff();
delay(5000);
Die Zeit ist so lang damit es länger ist als die Abschaltzeit des LTC2954 , eingestellt mit einem Kondensator. Ich habe die Zeit damals auf etwa 4,5 Sek. eingestellt damit man das Board im Fehlerfall, falls die SW hängt und der Power-Pin nicht mehr funktioniert , immer noch mittels langem Tastendruck auf den Rotaryencoder_Button das Board ausschalten kann (quasi ein Reset). Bei mir geht der ESP nie in Deep-Sleep.
Schaltungen zund etwas Info hier
Hi Zusammen,
um mal wieder auf das Thema zurückzukommen:
ich wäre dafür auf dem Dev-Branch arduino 2 (platform = espressif32@<=6.1.0) einzuchecken.
auf die Art kommen vielleicht noch mehr Dinge ans Licht die wir noch nicht auf dem Schirm haben und es wäre ein konkreter Schritt zur Umstellung wenn wir es voll am laufen haben.
Wie ist eure Meinung dazu?
1 „Gefällt mir“
Kurze Frage noch zu der Zeile:
platformio/framework-arduinoespressif32 @ https://github.com/espressif/arduino-esp32.git#1.0.6 in den platform-packages:
Kann die drin bleiben, oder sollte die entsprechend auskommentiert werden? Bin nicht so fit in den platformio-files…
Das brauchen wir für Arduino1.
Ah sorry, hatte den commit falsch gelesen und meine Frage vielleicht falsch gestellt:
Mein Vorschlag wäre auf dem dev-Branch in der platfomio.ino auf Arduiono 2 umzustellen.
Dazu hat mich eure Meinung interessiert
1 „Gefällt mir“
Also wenn es nur im dev-Branch bleibt, dann wäre mir das egal. Aber dass man den Master auf Arduino2 umstellt, das sehe ich so schnell nicht.
Das Problem ist, dass es mit Deepsleep gerne mal Probleme gibt. Mit der neuen mini 4L nicht mehr, aber mit der Vorgängerin doch öfter (oft?) schon. Die wird echt viel benutzt. Das möchte ich den ganzen Benutzern ehrlich gesagt nicht aufbürden.