Aktuell wird für die meisten externen Bibliotheken immer der aktuellste Stand verwendet.
Dabei kann es aber auch passieren, dass ein Bug in die Bibliothek kommt und damit auch ESPuino nicht mehr funktioniert.
Das bedeutet auch, dass der gleiche Softwarestand von ESPuino vor 3 Tagen und heute sich jeweils anders verhalten.
Genau das ist mir heute mit der PN5180 Bibliothek passiert. Mit der neuesten Version funktioniert der RFID-Scanner nicht mehr. Ich würde daher vorschlagen die Versionen für die Bibliotheken einzufrieren und bewusst, falls notwendig, neue Versionen anzuziehen. Solche Probleme sind ansonsten ziemliche Zeiträuber.
Hmm, ich habe einen neuen optionalen Parameter eingebaut, mit dem man jetzt ein anderes SPI angeben kann, z.B. HSPI. Dürfte abe eigentlich keine Nebenwirkungen haben. Evt. fehlt jetzt ein rfid.begin(); um den SPI Bus zu starten? Wäre hier für Anregungen dankbar um das Problem aus der Welt zu schaffen… @tuniii funktioniert das Demo PN5180-ReadUID bei Dir?
Ja, die Demo geht bei mir. Warum es zusammen mit ESPuino nicht funktioniert, kann ich leider aktuell auch nicht sagen. Aktuell komme ich leider auch nicht dazu, das genauer anzuschauen. In erster Linie ging es mir um die Reproduzierbarkeit der Software.
EDIT:
Der Task hängt sich auf:
// 2. check for an ISO-15693 card
nfc15693.reset();
Serial.println(„2“);
nfc15693.setupRF();
Serial.println(„3“);
Die „2“ sehe ich noch, die „3“ kommt nicht mehr. Manchmal hängt es sich aber auch beim nfc15693.reset() auf.
Bei der neuen Implementierung wird letztendlich das SPI-Objekt kopiert. Damit gibt es dann mehrere Instanzen. Das ist wohl die Ursache des Problems. Durch die Dereferenzierung im Parameter ist das nicht gleich ersichtlich, aber wenn man die Copy Konstruktoren von SPIClass auf private setzt, dann kompiliert das ganze auch nicht mehr.
Mögliche Lösung: Pointer für SPIClass als Klassen-Member verwenden.
