Der Build läuft leider nicht mehr durch, mal wieder am Ende der Fahnenstange?
/home/runner/.platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: .pio/build/esp32-a1s/firmware.elf section `.iram0.text' will not fit in region `iram0_0_seg'
/home/runner/.platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: IRAM0 segment data does not fit.
/home/runner/.platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: region `iram0_0_seg' overflowed by 12 bytes
collect2: error: ld returned 1 exit status
*** [.pio/build/esp32-a1s/firmware.elf] Error 1
========================= [FAILED] Took 196.81 seconds =========================
Ich komme aktuell leider nicht dazu hier ausführliche Tests mit dem „Arduino als Kompetente“ bezüglich dem Kopfhörer-Problem durchzuführen.
Für mich ist aber das deutlich schlechtere akustische Verhalten über Kopfhörer aktuell ein KO-Kriterium für die Umstellung.
Wurde zwar gesagt, dass das auf den neuen Boards nicht mehr Auftritt, diese haben aber glaub die wenigsten und es kann meiner Meinung nach nicht nur Hardware sein, da der Unterschied wirklich massiv zwischen den Versionen ist. Wenn wir dafür eine funktionierende Lösung finden (muss ja irgendeinen Grund dafür geben) sollte der Umstieg gar kein Problem sein, zumal das ja ganz grundsätzlich ziemlich intensiv schon getestet wurde.
Hoffe aber hier bald wieder mehr Zeit für zu finden.
Habe im FastLED noch zwei IRAM_ATTR entfernt um einige IRAM-Bytes Platz zu schaffen.
Damit kompiliert Alles & die o.g. Bugfixes sind jetzt verfügbar. Auf mittler Sicht ist das aber keine gute Lösung, dann hilft nur „Arduino als Komponente“
Warten wir nochmal mal ab, es kündigt sich für diese Woche noch ein letztes Bugfix Release Arduino 2.0.12 an, es basiert dann auf IDF 4.4.5
Bin doch deutlich schneller als gedacht weitergekommen:
Kann so erstmal mit rein genommen werden und wenn es dann gar nicht mehr anders geht aktiviert werden (und bis dahin von allen interessierten getestet und verbessert werden …)
Ich habe heute meine alte Hardware mit SD_SPI hervorgekramt. Da mit SD_SPI die div. Knistergeräusche nicht auftreten wollte ich es mal testen.
Aktuelle DEV mit Arduino als Komponente (Was immer das auch heißt?).
SD_SPI funktioniert nicht.
define SD_MMC_1BIT_MODE = ok
define SINGLE_SPI_ENABLE = SD wird nicht gefunden
beide deaktiviert , läuft ohne SD
Deaktiviere ich die Änderung vom 7.7.2023 in SD.cpp, also Zeile 18-21 ausklammern , dann geht SD_SPI.
Ich komme mit SD_MMC auf konstante 550 KB/s (ihr habt ja z.T. höhere Übertragungsraten), mit SD_SPI auf 450 KB/s. Das ist recht ordentlich.
@tueddy kannst du das bitte mal testen , mache ich was falsch ?
Mir ist noch aufgefallen das die Monitorausgabe beim Einschalten oder Restart erst sehr spät erfolgt.
Die ersten 40-50 Zeilen sehe ich fast nie.
Bist du auf dem aktuellen Dev-Branch? Und zu deinem Kommentar am Anfang: hast du in der Plattformio.ini Arduino als Komponente aktiviert oder bist auf auf dem stand vom dev-branch?
Dann verstehe ich das verhalten absolut nicht .
Ob du die Zeilen auskommentierst oder nicht sollte eigentlich bei einem normalen compiler keinen Unterschied machen, sobald eines der beiden defines existiert.
Aber vielleicht sieht ja jemand anderes den Grund für dieses Verhalten. Sorry.
Das ist genau der Punkt. Welche Hardware benutzt du und kannst du SD_SPI testen ?
Bisher war es so das SD_SPI per default funktioniert , d.h. keiner der beiden defines ist gesetzt.
define SINGLE_SPI_ENABLE hat bei mir noch nie funktioniert und hat Torsten ja auch so kommentiert.
Ich habe diese Einstellung auch immer so verstanden das es nur erforderlich ist wenn man Cardreader und SD-Card an einem Bus betreibt. Wir haben aber 2 .
Bei dem Verhalten das du beschreibst ist die entsprechende Verknüpfung vermutlich wirklich falsch. Also warten wir am besten bis @tueddy aus seinem wohlverdienten Urlaub zurück ist und das bei sich nochmal testen kann, sollte er eine passende Hardware haben … Auf meiner Hardware geht das soweit ich weiß nicht, habe es aber auch noch nicht ausprobiert (die letze Version vor dem 4L-Board).
Vor 12 Tagen hat die DEV-Version noch bis auf diesen Fehler funktioniert.
Ich habe gerade ein weiteres Board geflasht und habe den Fehler das die Wiedergabe ganz langsam ist und „eiert“. Bei Musik von SD und auch bei Webradio. Getestet mit 2 verschiedenen Hardwaren. Egal ob mit oder ohne Arduino als Komponente. Hat das noch jemand? Der Code hat sich doch nicht geändert, liegt es evtl. an einer geänderten Library .
Nachtrag:
Da sich bisher niemand mit diesem Problem gemeldet hat habe ich heute nochmal mit der aktuellen DEV vom 25.09.2023 probiert. Ich weiß leider nicht warum , aber es funktioniert wieder.
Mein MAC hatte ein Update auf Sonoma und VSCode ist aktualisiert. ???
Hi, melde mich aus einem erholsamen Urlaub zurück, war ja recht ruhig hier.
Zu den gemeldeten Problemen:
SD_SPI funktioniert nicht
Ich hab’s einfach mit dem Lolin D32 Pro integrierten SD Slot getestet, der läuft ja mit SD-SPI.
Relativ neu ist ja die Möglichkeit den ESPuino auch komplett ohne SD zu betreiben, z.B. für einen reinen Webplayer. Evt. ist das komplette Deaktivieren von SD noch etwas unglücklich an die Compilerbedingung SINGLE_SPI_ENABLE geknüpft, gern Vorschläge dazu.
Mir ist noch aufgefallen das die Monitorausgabe beim Einschalten oder Restart erst sehr spät erfolgt.
Die ersten 40-50 Zeilen sehe ich fast nie
Ja das habe ich auch & es scheint mit PlatformIO zusammenzuhängen. Vor allem nach dem Upload oder neuen Monitor hakt die Ausgabe.
Ansonsten gibt es im DEV-Branch nur kleine Änderungen:
Aktualisierte Bluetooth- und FTP Bibliothek für z,B. dieses Problem…
Log-Ausgebe erweitert
Bugfix für DONT_ACCEPT_SAME_RFID_TWICE, danke an @Joe91 !
Buffer-overflow beim NVS Upload einer ungültigen Datei behoben
Es gibt jetzt ein neues Define NO_SDCARD (z.B. für Webplayer ohne SD-Karte) unabhängig von SINGLE_SPI_ENABLE. @compactflash Kannst Du einmal schauen ob damit der Konflikt mit SINGLE_SPI_ENABLE gelöst ist?
Im seriellen Monitor kann man jetzt unterscheiden zwischen Arduino- und unseren Meldungen (runde/eckige Klammern):
E (589) esp_core_dump_flash: No core dump partition found!
I [92] Maximale Inaktivitätszeit wurde aus NVS geladen: 10 Minuten
D [143] RFID-Tags koennen jetzt gescannt werden...
D [144] Port-expander gefunden
D [146] Interrupt für Port-Expander aktiviert
Beim Aufegen einer unbekannten Karte gab es eine Meldung „NVS entry not found“, das wird jetzt kürzer angezeigt.
…)
.
… Auf meiner Hardware geht das soweit ich weiß nicht, habe es aber auch noch nicht ausprobiert (die letze Version vor dem 4L-Board).
