Nee hab ich dann nicht mehr gemacht. Was auf jeden Fall zu Schwankungen führt, ist ein „Delay“ im Async-Webserver. Wir füllen den RingBuffer ja mit bis 1000ms delay (falls der RingBuffer nicht frei ist). Sobald dort zu lange gewartet wird, fangen die Schwankungen an, Der Async-Webserver fängt dann scheinbar an dem Sender mitzuteilen, dass er die Daten langsamer senden soll. Macht ja auch Sinn. Ich habe versucht einen Kompromiss zu finden um den Async-Webserver nicht zu blockieren. Das kann aber stark abweisen in anderen (WLAN-)Umgebungen.
Also es scheint wohl durch Verkleinern der i2c-PullUps deutlich besser zu werden. Ich habe zu den beiden 4.7k direkt am PE zusätzlich hinten am externen i2c-Konnektor nochmal je 10k dazugelötet, was dann rechnerisch als Parallelschaltung 3.2k bedeutet. Dann habe ich ein File abgespielt, welches etwa 74min lang war. Da hatte ich zwischendrin mal ein Event nach 17min.
Passieren tut dann Folgendes:
Normalerweise ist Port 0 auf 255 und Port 1 auf 127. In diesem Falle springt Port 0 auf 70, was Folgendes bedeutet:
Das führt dann dazu, dass Port 1 sich von 127 auf 126 ändert, da der Kopfhörer deaktiviert wird (108 geht von 1 auf 0).
Das passt dann insgesamt zu meiner Vermutung, dass mehrere Buttons gedrückt werden und zudem kurz der Kopfhörer „erkannt“ wird.
Ich werde es mal testen, in dem ich 4,7k dazulöte, so dass sich 2,35k insgesamt ergeben. Ansonsten mal schauen, ob man das vielleicht auch sinnvoll debouncen kann, so dass einzelne Ausreißer nichts „anrichten“.
Ich habe als Workaround mal einen rudimentären Debounce eingefügt, der einzelne Events „übersieht“. Der greift nach 10s Uptime.
Zum Test muss der aktuelle Code von Port_ExpanderHandler() durch mein Code-Snippet ersetzt werden. Bei mir lokal funktioniert das. D.h. statt „Ghost-Events“ sieht man jetzt nur noch „Verify set!“ im Logging.
Vielleicht können das mal 2-3 Leute verifizieren, die vorher von dem Problem betroffen waren.
Ich habe seit Arduino >1.0.6 Probleme und leider bin ich wahrscheinlich der Einzige auf der Welt. Das liegt an dem auf meinen Boards verwendetem ON/OFF-Controller LTC2954-1. Trotzdem müßte es eigentlich bei allen Boards passieren nur merkt man es nicht.
Zur Erklärung:
Mit dem LTC2954-1 schalte ich den LDO Ein/Aus.
Das geschieht mittels ROTARYENCODER_Button auf Pin PB des LTC2954-1. Die Ansprechzeiten sind mittels Kondensatoren einstellbar.
Zum Einschalten muss man den Button ca. 0,5 Sek. festhalten, zum Ausschalten ca. 4,5 Sek. Das Ausschalten funktioniert normalerweise durch Software mit GPIO POWER auf Pin KILL des LTC2954-1. Sollte der ESP mal „hängen“ kann man dann trotzdem durch langes betätigen des ROTARYENCODER_Button das Board Zwangsausschalten. Das hat alles bis vor etwa einem Jahr perfekt funktioniert.
Mit irgendeiner SW-Version hat mein Board nicht mehr gebootet. Das lag daran weil auf GPIO POWER beim Einschalten nach ca. 2 Sekunden ein LOW-Impuls auftrat und damit den LTC2954-1 abgeschaltet hat. @biologist hat mir empfohlen die Power.cpp im Setup zu deaktivieren und den GPIO POWER wieder im Setup zu schalten. Das hat geklappt…bis zum Sommer 2022. Dann passierte es wieder. Ich habe dann das Aktivieren GPIO POWER direkt als erstes in der Main.cpp ausgeführt. Hat geholfen und sogar der Aufruf der Power.cpp ging damit wieder. Ja, und jetzt mit neuer Arduino ist der Fehler wieder da und ich habe keine Idee mehr.
Ich bitte euch mal zu prüfen ( mit den Boards von Torsten) ob die Spannung an der Peripherie, also RFID, SD-Karte, Audio usw. etwa 2 Sekunden nach Einschalten kurz für 1 Sekunde aus geht. Kann man am Flackern der LED auf dem RC-522 sehen.
Ich benutze zum Abschalten im Moment den Pin KILL nicht mehr, habe es anders gelöst. Ich bin aber trotzdem sehr interessiert ob das bei euch auch so auftritt.
ich hab das jetzt auch mal getestet und es sieht eigentlich alles besser aus als mit Arduino-1… Nur eine Kleinigkeit ist mir bisher aufgefallen: Ich nutze DONT_ACCEPT_SAME_RFID_TWICE und prinzipiell funktioniert es zwar, aber wenn ich ne Karte auf dem Reader liegen lasse, dann greift sie irgendwann doch und zwar mit dieser Log:
Also die ersten 4 mal hat er sie abgelehnt, aber dann kam dieser getString() fehler und ab da hat er sie dann wieder akzeptiert und das aktuelle Lied von vorne gestartet.
Er hat zwischendrin offenbar die Karte mal „anders“ erkannt. Das kann leider vorkommen.
Hast du meinen Fix mit dem Port-Expander eigentlich laufen gehabt? Weil das würde mich mal interessieren.
Ja, also mit Arduino-1 ist mir das nie aufgefallen. Erst seit dem Umstieg auf Arduino-2 ist das reproduzierbar nach 3 bis 5 Lesezyklen. Hatte das allerdings jetzt auch nicht wirklich lange mit Arduino-1 am Laufen, nur ein paar Tage.
Hmm, ich bin mir nicht sicher was Du mit Port-Expander Fix meinst, bin noch relativ neu hier… Zumindest hab ich da nicht explizit was eingespielt. Das hier ist der Code-Stand den ich aktuell laufen hab: GitHub - mzanetti/ESPuino at bbox
EDIT: Sehe erst jetzt, dass ja oben die ganze Zeit um besagten Port-Expander Fix ging . Ich dachte von dem Problem nicht betroffen zu sein, so hatte ich die entsprechenden Beiträge zum Thema nur überflogen. Ich habe den Patch jetzt eingespielt und tatsächlich wird dadurch auch dieses Problem behoben.
Es scheinen sich ja nach und nach die Probleme mit der 2er Version lösen zu lassen, das ist schon mal fein!
Bzgl. schwankende Web-Uploadrate experimentiere ich hier weiter. Die 500 KB/s von @Christian konnte ich zwar noch nicht erreichen, aber der Gedanke das es an der Lastverteilung der Tasks liegt teile ich mittlerweile auch. Zuvor hatte ich die Probleme immer im Arduino 2.x Wifi-Durchsatz verortet…
Die Idee während des Web-Uploads (und evt. später auch FTP-Uplaod) den Audio/LED Task zu pausieren finde ich logisch. Ich benötige keine Audio/LED Ausgabe wenn ich ein Hörspiel möglichst schnell hochladen möchte. Feedback habe ich eh über den Fortschrittsbalken im Browser.
Wie steht Eure Meinung dazu diese Tasks während Web-Upload zu pausieren?
Finde ich eine sehr gute Idee, da es so wie so kaum mehr nutzbar ist in diesem Zeitraum. Man kann ja trotzdem ein bestimmtes statisches Muster (z.B. das Pause -Muster) auf den LEDs anzeigen.
Ist die feste Zuweisung des Cores für IP jetzt schon mit drin oder nicht?
Alle weiteren Änderungen sollten ja möglichst keine (negativen) Auswirkungen auf die offizielle Version Arduino 1.0.6 haben
Ist die feste Zuweisung des Cores für IP jetzt schon mit drin oder nicht?
Nein, das ist noch nicht drin, könnte aber absolut nicht schaden. @biologist kannst Du das gelegentlich übernehmen in platform.ini, Danke dafür geht meines Wissens an @tuniii ?
D.h. meine Anpassungen helfen bei Dir nicht? Hast Du meinen Branch mal installiert? Wie hast Du den Upload gemacht? Über das Webinterface? Ich hatte zum Testen die Uploads irgendwann mit CURL gemacht, weil das einfacher ist.
Leider noch kein Durchbruch, 500 KB/s wäre ja mal mal eine Ansage! Ich teste hier mit Win11 & MS-Edge Browser, glaube aber nicht das dies der springende Punkt ist. Werde das weiter testen…
Also ich habe jetzt nur den aktuellen Master genommen, die beiden Build-Flags integriert (Commit von gestern) und habe es dann mal mit Arduino 1 bzw. 2 getestet. Sonst habe ich keine Anpassungen vorgenommen. Also nix an Ringbuffer geändert, den Fileupload nicht verschoben und auch nix pausiert. Hätte ich vielleicht dazusagen sollen.
Ah okay - vielleicht magst Du das bei Dir dann bei Gelegenheit mal mit den Änderungen testen. Denn dann passt das jetzige Verhalten ja komplett ins Bild.
. Ich dachte von dem Problem nicht betroffen zu sein, so hatte ich die entsprechenden Beiträge zum Thema nur überflogen. Ich habe den Patch jetzt eingespielt und tatsächlich wird dadurch auch dieses Problem behoben.