Eieiei, jetzt habe ich nfc14443 gefixt und nfc15693 vergessen. Schiebe ich nach.
Die Idee finde ich gut. Allerdings denke ich, dass es für ESP32-Varianten, die keinen PSRAM besitzen, keinen Sinn macht. Weil wir haben ja aktuell eh schon Probleme mit dem Heap.
Jetzt frage ich mich allerdings, wie ich das mit vertretbarem Code-Aufwand nur für PSRAM mache. Weil die ganzen audio. werden ja zu audio->. An jeder Code-Stelle eine Präprozessor-Direktive wäre übel. Hmm, vielleicht kann man da mit einem Makro arbeiten!?
Für die nicht PSRAM-Variante kann man doch auch einfach die gleiche Pointer-Variable nehmen. Bei PSRAM bekommt man dann den Pointer über new und bei Nicht-PSRAM holt man sich den Pointer von der static Variablen.
EDIT:
Zum Beispiel.
void AudioPlayer_Task(void *parameter) {
#ifdef BOARD_HAS_PSRAM
AudioCustom *audio = new AudioCustom();
#else
static Audio audioAsStatic;
Audio *audio = &audioAsStatic;
#endif
...
1 „Gefällt mir“
Mit dem zweiten Fix habe ich mir den ersten wieder kaputt gemacht sehe ich gerade. Das muss ich irgendwie anders lösen.
Problem ist, dass die beiden RFID-Instanzen ja unabhängig voneinander arbeiten. Und so hat mir, während ich mit nfc14443 gearbeitet habe, die nfc15693 fein die lastCardId auf meinen (gestern vorgeschlagenen) Dummy-Wert zurückgesetzt. Und so kam bei der Prüfung am Ende immer ungleich raus und meine Idee war wieder ausgehebelt.
Da habe ich mir echt mal ein schönes Ei ins Nest gelegt, was gar nicht so einfach zu finden war :->
@tueddy Ich habe eben nochmal die Implementierung für PN5180 gefixt. Ich habe nur leider keinen nfc15693 da, um das mal zu testen. Also es geht mir um folgende Sachen:
a) Legt man eine Karte auf, so soll der Event nur einmal geworfen werden. Man kann sie auch beliebig lange auflegen.
b) Nimmt man sie weg und legt sie wieder erneut auf, so soll das als neues Event wahrgenommen werden.
c) Der Wechsel zwischen nfc14443 und nfc15693 soll klappen.
@tuniii Ich habe der State-Machine zwei neue Status spendiert. Und zwar macht es aus meiner Sicht keinen Sinn, wenn man eine Karte aufgelegt hat z.B. für den nfc14443, dann auch noch nach nfc15693 zu suchen (und umgekehrt). D.h. ist 14443 aktiv, dann springe ich direkt auf 1u zurück, anstatt auf 4u zu gehen.
Man gewinnt damit ein bisschen Performance bei der Erkennung, wobei das nicht sonderlich wichtig ist. Der Hauptpunkt ist: Damit erschlage ich das Problem, dass sich nfc14443 und nfc15693 gegenseitig die lastCardId überschreiben, wenn eine Karte aufgelegt wurde (siehe mein Post vorher). Die zusätzliche (auskommentierte) Trigger-Zeile hatte ich zum Debuggen drin und die Queue deaktiviert. Hab’s nur vergessen wieder zu entfernen.
@compactflash Du testest doch gerade den Branch von Tuniii. Funktioniert BT bei dir? Ich habe das gerade getestet und man kommt in den BT-Modus sauber rein+raus, aber für eine Audioverbindung kann ich mich mit meinem Handy nicht drauf verbinden.
Sehe das hier u.a. im Log, aber hat damit ggf nix zu tun:
[E][BluetoothA2DPSink.cpp:724] get_last_connection(): ERROR GETTING NVS BLOB
[E][BluetoothA2DPSink.cpp:725] get_last_connection(): NVS NOT FOUND
Hi @biologist
Hatte ich bisher nicht getestet weil mir erstmal nur OTA wichtig war und bin dann wieder zurück auf Master . Ich bin noch mit Hardware und ein paar kleinen Codeänderungen beschäftigt und verwende deshalb die Master weil ich noch nicht den Überblick des refactoring habe. Gerade mal eingespielt , funktioniert .
VG
Bin parallel noch dabei, für den Sohnemann ein massives Hochbett aus Buche zu schreinern. Deswegen geht es hier aktuell etwas schleppend voran. Sorry 
3 „Gefällt mir“
Hallo, ich muss jetzt einmal ganz blöd fragen. Ich habe den Refractoring branch erneut auf meinen ESPuino versucht zu bringen. Da die LPCD Erkennung irgendwie in beiden Branches Probleme macht habe ich diese Funktion erst einmal ausgeschaltet.
So läuft es jetzt auch. Allerdings startet bei mir die Karte weiter immer wieder neu wenn man sie auflegt.
Das hattest du, @biologist, ja versucht zu beheben.
Was ich mich jetzt frage ist: mache ich vielleicht irgendetwas grundlegend falsch? Die Änderungen des commits sehe ich bei mir im code bei Platformio.
Muss ich noch irgendetwas tun damit auch diese neue Version dann auch verwendet wird?
Ich arbeite halt mit sehr löchrigem Halbwissen. Sorry
Hallo @MusikHexe,
wegen lpcd warte ich noch auf Rückmeldung von @tueddy. Ich selbst habe dafür keinen funktionierenden Testaufbau.
Also den ständigen Neustart hatte ich nur dann, wenn ich die Karte aufgelegt gelassen habe. Bei kurzem Auflegen indes zweimal.
Hmm, schaue morgen nochmal drüber. Aber dachte eigentlich, dass das gefixt war.
Wenn du den Code in Platformio siehst, muss der Code neu kompiliert und hochgeladen werden. Zur Not machst nochmal ein Clean, so dass auch wirklich alles neu kompiliert wird.
Okay, dann spiele ich heute noch einmal auf. Ich bin mir nicht sicher ob ich gecleant hatte.
Mit Lpcd bin ich ehrlich gesagt nicht sicher ob da nicht beim zusammenbauen irgend etwas schief gelaufen ist oder irgend eine Lötstelle nicht perfekt ist. Denn auch im master branch reagiert das LPCD sehr eigenwillig. Weckt teilweise andauernd ohne karte wieder auf. Startet aber Karten nicht unbedingt wenn sie aufliegen oder selbst wenn die Karte zum aufwecken führt . Daher haben wir das jetzt einfach gelassen.
So, ich habe eben nochmal ein bisschen getestet wegen den Problemen mit Webtransfer und FTP-Upload.
Dafür habe ich einerseits die Änderungen von @tuniii eingebracht, um die Heap-Corruption zu fixen. Weiterhin habe ich den Stack für den Audiotask von 11k auf 4k (bei 3k gabs einen Stack-Overflow bei Webradio) eingeschrumpft. Um ehrlich zu sein weiß ich nicht mehr, warum ich den so groß gewählt hatte. Ggf. hatte ich ein Problem falsch zugeordnet oder so. Und am End habe ich dann noch die 8k Json, die zuvor im Heap allokiert worden, nun auf den static RAM verschoben.
Filetransfers haben nun wieder ordentlich geklappt. Per FTP war er allerdings etwas langsam. Aber ich denke so lässt sich erstmal wieder arbeiten 
@alle: Gerne mal testen und Feedback geben!
@Christian / @Harry Seid ihr in Sachen JSON-Umbau schon vorangekommen?
Ja, alerdings war das deutlich komplizierter (für mich) als gedacht.
Ich habe es jetzt so probiert, dass quasi ein Verzeichnis per Websocket angefragt wird und dann in x Websocket-Antworten die einzelnen Dateien als Antwort kommen.
- Der AsyncWebServer mag es nicht, wenn die Antworten (Dateiliste) direkt im Callback vom Request laufen. → Watchdog → Übertragung der Dateiliste läuft nun in einem eigenen Task.
- Der AsyncWebServer hat für Websockets auch einen Buffer . Der ESP ist schnell genug, um diesen zu füllen - weitere Nachrichten werden einfach „gedropt“ → Bei einer Verzeichnisliste uncool. Ich muss mich also um den Buffer kümmern und erst wieder senden, wenn Platz ist. → Erledigt.
- Im Stress-Test viele Abbrüche / Reboots … Bisher besser, wenn ich diesen Fork verwende: ESP32 crashes while using Events · Issue #932 · me-no-dev/ESPAsyncWebServer · GitHub
- Jetzt habe ich noch einen Fehler im Code, wo ich Mist baue mit Pointern - die werden teilweise überschrieben / ungültig und ich weiß noch nicht warum.
- Kein Witz: aktuell dauert der Aufbau von einem Verzeichnis mit 20 Files Mit Chrome und Windows ca. 4 Sekunden / mit iOS / MacOS ca. 400 ms. Da bin ich in Richtung „Delayed ACK“ bei Windows unterwegs. Das Thema hatte ich schon einmal.
Insgesamt - ne echte Herausforderung 
Bleibe aber dran und hoffe am Wochende einen guten Stand zu haben.
Puh, klingt ja wirklich nach Stress.
Ja lass dir ruhig Zeit. Ich denke nachdem ich das von 16 auf 8 kB reduziert habe den JSON-Buffer, der zudem auch noch im static RAM läuft, ist es jetzt wieder gescheit benutzbar. Weil vorher war der Upload quasi komplett unzuverlässig.
Danke auf jeden Fall für deine Mühen!
Habe eben noch einen Bug gefixt: Durch das Entfernen des Tasks von PN5180 wurden ständig neue Events erkannt, wenn man eine Karte aufgelegt gelassen hat. Hat aber nur ein static gefehlt.
Was aktuell bei mir irgendwie nicht klappt ist Bluetooth. Also man kommt in diesen Modus aber mit dem Handy kann ich mich nicht auf den ESPuino verbinden. Kann das jmd. verifzieren?
Ansonsten sind mir (außer LPCD) aktuell keine Bugs bekannt im Refactoring-Branch. Ich denke also mal, dass ich Anfang Juni diesen Branch zum neuen Main-Branch machen werde. Was ich kurzfristig noch einbauen möchte sind zwei Dinge:
a) Das Filecaching, so dass das Starten großer Playlisten schneller geht
b) Für das Audiokit gibt es aktuell GPIO_PA_EN, um die Amp zu aktivieren. Das möchte ich gerne generisch drin haben (auch wenn es normalerweise nicht benutzt wird). Dazu auch nochmal das Gleiche für Headphones und das Ganze soll auch per Port-Expander ansprechbar sein. Damit wird es also (optional) eine Möglichkeit geben, dass der ESP32 selbst steuert, wann jeweils die Verstärker für den Lautsprecher und den Kopfhörer an bzw. aus sind.
Hi @biologist
Finde ich super , das habe ich bei mir schon testweise eingebaut , dazu ein Hinweis . Es gibt ja verschiedene Kopfhörerbuchsen ,
- die von mir im Moment verwendete Cliff hat Ruhekontakt , schaltet also ohne Kopfhörer GND .
- die meisten anderen schalten GND mit gestecktem Kopfhörer .
Das sollte per define schaltbar sein . Dann kann auch der Mosfet auf der Kopfhörerplatine und neuen PCB´s entfallen . Ich habe beide Varianten ausprobiert und ändere das entsprechend in der Audio.cpp.
Ich verwende es ohne Port-Expander mit dem letzten freien Pin . Habe eben meine neuen PCB´s bestellt , hoffentlich ist kein Fehler drauf . Ich wollte es mal von JLCPCB bestücken lassen , aber die wichtigen , kleinen Teile sind alle nicht vorrätig , also werde ich wieder selbst löten .
Ich habe mir noch ein Feature einfallen lassen was ganz hilfreich ist .
Anzeige der Wlan-Feldstärke beim Booten im Monitor , toll würde ich eine Anzeige im WebGui finden ( vielleicht oben in der Kopfzeile , es reicht ja einmalig beim Booten und muss nicht ständig aktualisiert werden … oder ?
Ich weiß im Moment noch nicht wo ich die Zeile im refactoring einfüge , bekomme immer Compilerfehler
Compiling .pio/build/lolin_d32_pro/src/main.cpp.o
src/main.cpp: In function ‚void setup()‘:
src/main.cpp:192:18: error: ‚WiFi‘ was not declared in this scope
Serial.println(WiFi.RSSI());
im master geht es .
Bluetooth geht bei mir , hatte ich dir ja schonmal geschrieben . Allerdings habe ich es noch nicht mit der neuesten Version getestet , werde ich am WE mal machen . Habe im Moment kaum Zeit .
VG
Hallo,
Wir haben auch das Problem
Der Espuino wurde im Bluetooth angezeigt, verbinden geht aber nicht. Spannend ist, das wir seit diesem Versuch einen dauerhaft roten LED Ring haben. Auch erase flash und komplett neu machen hat nichts gebracht. Musik spielt er aber.
Wenn wir versuchen den Bluetooth Modus zu starten sagt er:
[E][BluetoothA2DPSink.cpp:735] get_last_connection(): ERROR GETTING NVS BLOB
[E][BluetoothA2DPSink.cpp:736] get_last_connection(): NVS NOT FOUND
Freier Heap-Speicher nach Setup-Routine: 47972
PSRAM: 0 bytes
Firmware version=4.1
RFID-Tags koennen jetzt gescannt werden…
Er liest dann auch wieder neue Karten ein.
VG
Also mit dem Neopixel habe ich kein Problem. Aber diese Meldungen habe ich auch gesehen.
Das müsste man in die Wlan.cpp hinzufügen. Man kann es auch zyklisch aufrufen und dann wird’s in Log geschrieben. Im Refactoring-Branch gibt es via GUI ein Log-Funktion; da werden die letzten ich glaube 2kB an Log angezeigt. Dort würde es dann auftauchen.
Achso, dass man wahlweise 0 oder 1 schalten möchte für ENABLE, ist natürlich ein valider Punkt.
Dann schließ ich mich mal dem Testaufruf an 
Hab den Refactoring branch jetzt geladen, läuft bisher einwandfrei, inkl. Bluetooth.
Positiv fällt auf, dass der PN5180 gefühlt deutlich besser und schneller auf Karten reagiert.
Update:
Was ebenfalls positiv auffällt: vorher stockte die Musikwiedergabe kurz, wenn ich das Webinterface aufrief und Eingaben dort machte. Jetzt läuft die Musik flüssig weiter!
Update 2:
Hab jetzt ne Weile Musik über Bluetooth gestreamt und mir fallen immer wieder ganz kurze Aussetzer auf. Das war mir zumindest bisher bei dem Master nicht aufgefallen. Um sicherzugehen müsste ich allerings noch mal den master aufspielen.
Update 3:
Mir fehlt in der Button_init für den WAKEUP_BUTTON noch ein pinMode(WAKEUP_BUTTON, INPUT_PULLUP); ansonsten wacht der bei mir ständig unkontrolliert aus dem deep sleep auf.
Update 4:
Hab noch weiter mit Bluetooth getestet, die Aussetzer sind nicht mehr aufgetreten. Hatte daher vermutlich nichts mit dem refactoring zu tun…
1 „Gefällt mir“