Aus meiner Sicht ist der jetzige Stand Arduino 2 recht weit und gereift, trotzdem darf es nicht passieren bestehende Anwender mit Fehlern zu überhäufen!
Wenn man bedenkt das der Umstieg jetzt schon über ein Jahr läuft muss dann auch nicht gleich morgen Release sein…
Wenn die 2er Version im Dev-Branch standardmässig aktiv ist können das alle Early-Adapter natürlich gleich mittesten.
Ich würde mich jetzt als Nächstes noch um den Bugfix bei „Umbennen“ von Ordnern kümmern.
Und das Pausieren vom Audio-/LED Task bei Webupload für weniger Schwankungen & bessere Performance. Das wurde weiter oben bereits besprochen.
Sonst scheint mir Alles bekannte soweit gelöst zu sein. Oder war da noch was?
Nichts was mir bekannt ist oder bei mir nicht funktionieren würde. Ich habe auch am Anfang das Problem mit dem Deepsleep gehabt, konnte das aber nach dem einmaligen Power-Off nie wieder auf Arduiono 2 reproduzieren. Wir reden ja auch nicht davon das schon in einem Monat oder so wieder in den master zu bringen. Und selbst wenn können wir in diesem Fall ja auch bei Arduiono 1 bleiben.
Ich sehe durch die Umstellung vor allem eine größere Test-Tiefe, da alle interessierten an neuen Funktionen und motivierte Entwickler ja auf dem dev-Branch aktiv sein werden und wir so schneller noch möglicherweise unbekannte Probleme finden können.
Ich wollte jetzt für den Webupload die Tasks LED, Audio und evt. auch RFID pausieren wie von @Christianvorgeschlagen
Vorteil: Beim Web-Upload hat man ja Feedback im Browser, pausierte Tasks verbrennen keine Rechenzeit und der Upload wird schneller und vor allem gleichmässiger. Wir haben ja mit Arduino 2 noch mit starken Schwankungen zu tun.
Allerdings bekomme ich sobald nach dem Einbau diese Fehlermeldung vom Linker spendiert: region "iram0_0_seg" overflowed by 204 bytes
Sind wir schon am Ende des (statischen?) Speichers oder anders gefragt, wie kann man so einen Fehler beheben?
Ich würde die beiden Tasks nicht durch vTaskSuspend stoppen. Da weißt du nicht, in welchem Status sie sich gerade befinden (zb ob nicht gerade Semaphore für die Queues oder Richtung OS gehalten werden).
Besser wäre das Suspend über ein Binary Semaphore oder TaskNotify zu lösen. Damit können wir immer genau sagen, wann ein Task schlafen gegangen ist.
Der Fehler konnte ich aber nicht nachstellen. Bei mir ist die iram.0 Sektion 125kB groß mit Arduino 2.0.7 (dev Branch mit Arduino 2 & dem vTaskSuspend). Grundsätzlich sind Funktionen im IRAM (Instruction RAM), die entweder Interrupt routinen sind oder schnell sein müssen (wie zB SPI oder UART Transmit Aufrufe und Interrupt Handler). Im User Code sind die mit dem IRAM_ATTR versehen.
Einen Überlauf der Segments habe ich bisher nicht erlebt . Normal läuft die nur über, wenn man a) viele lange und komplizerte Interrupt Handler hat oder b) die Optimierung beim gcc ausgeschaltet (zB auf -O0 gestellt) ist.
Hast du eine Branch, die ich mir anschauen könnte?
Ich hatte das schon mal am Start und es funktionierte fein mit vTaskSuspend. Die Tasks werden ja einfach eingefroren und machen später genau da weiter. Also für den WebUpload wird nur der Webserver- und Storage-Task benötigt. Alles andere wie LED, Audio und RFID verbraucht nur Rechenzeit, Upload-Feedback gibt es ja über den Browser.
Man müsste nur noch schauen das auch im Fall eines fehlgeschlagenen Uploads die Tasks wieder richtig weitergeführt werden.
Den Linkerfehler kann ich mir nicht erklären, vor allem nicht was das mit IRAM zu tun haben sollte.
@tueddy ich habe dein commit ausgecheckt. Bei mir läuft das sowohl mit Arduino 2 als auch 1.0.6 bei allen targets problemlos durch (aktuelles platformIO Core 6.1.0). Kannst du den .pio Ordner löschen und danach neu compilieren, wenn du es nicht schon gemacht hast ? Wenn der Fehler reproduzierbar ist, wird es an einem Zusammenspiel von Platformio liegen.
In PIO Home hast du die Möglichkeit mit Inspect einen genaueren Dump über die Symbole und deren Größen in den einzelnen Sections zu bekommen. Kannst du da schauen, was da so viel verbraucht? Interessant ist die Section .iram0.text (die bei mir mit PSRAM ~125 KB ist).
@laszloh Vielen Dank für die hilfreichen Tipps! Die Inspect-Möglichkeiten kannte ich so noch gar nicht.
Die Meldung war schon strange & mein .iram0.text Speicher war auch im Rahmen.
Klappt jetzt, letztlich geholfen hat das Löschen des PIO Cache Ordners. Bin also wieder online, Danke!
Wie bewertet Ihr denn jetzt das Pausieren der ungenutzten Tasks?
Bei mir erreiche definitiv bessere und gleichmäßigere HTTP-Uploadgeschwindigkeiten.
Wenn das OK ist würde ich das jetzt noch ein wenig ausarbeiten…
OK, ich habe jetzt einen PR für den DEV-Branch erstellt.
Das Pausieren/Wiederaufnahme habe ich in den Upload-Task verschoben. Damit werden die pausierten Tasks auch im Fall eines Abbruchs/Timeout wieder fortgeführt.
Eine kleine Erweiterung ist noch mit reingerutscht: Multiselect Delete - Über das Kontextmenu „Löschen“ kann man alle selektierten Dateien löschen. Bisher konnte jeweils nur eine Datei (focused Node) gelöscht werden.
@tueddy Jetzt haben wir ein kleines Problem: @Joe91 hat die Led.cpp überarbeitet, ich hab’s gemerged und das ist jetzt nicht mehr mit dem PR kompatibel.
Das ist ganz normal wenn mehrere Personen gemeinsam am Quellcode arbeiten.
Für solche Fälle bietet git und die Tools drumherum (VSCode, etc.) ja zum Glück alles was notwendig ist um Konflikte möglichst komfortabel zu lösen.
Ein neuer PR ist gar nicht unbedingt notwendig. Einfach den bestehenden Feature-Branch auf den aktuellen Dev rebasen, ggf. Konflikte lösen und dann einen Force-Push durchführen.
Das weiß ich. Da ich selbst jedoch gerade nicht entwickele und wegen anderen Themen auch gerade keine Zeit habe, mich in die PRs einzudenken, macht es keinen Sinn, dass ich da selbst was anpasse.
Lasst uns den Aufwand für @biologist doch so gering wie möglich halten, er hat ja nun schon reichlich Arbeit reingesteckt.
Ist jetzt drin im Dev-Branch, würde mich freuen wenn es dazu Feedback hier gibt. Vor allem die Upload-Geschindigkeit, Stabilität wäre interessant. Ich schaffe hier dauerhaft 300-400KB/s mit Arduino 2 und nicht mehr solche Ausreißer mit 80KB/s wie zuvor. Danke nochmal an @Christian , das war seine Idee!
Passt. Es ist sowieso unüblich, dass der Maintainer eines Projekts, in diesem Fall Torsten, diese Arbeit macht und die Konflikte löst. Ich kenne es eher so wie es in diesem Fall war: der Maintainer weist den Ersteller de PRs auf den Konflikt hin und der kümmert sich dann darum das alles wieder zusammen passt.
Habe gerade den aktuellen DEV vom 21.03. geflasht.
Was mir sofort aufgefallen ist: meine Webradioplaylist.m3u enthalt 13 Einträge. Wenn Eintrag 1 gespielt wird und ich drücke den PREV_Button wird nicht Ende signalisiert sondern es toggled bei jedem Tastendruck zwischen Eintrag 1 und 2 hin und her. Am Ende bei 13 passiert das nicht.
. Normal läuft die nur über, wenn man a) viele lange und komplizerte Interrupt Handler hat oder b) die Optimierung beim gcc ausgeschaltet (zB auf 
