LOLIN D32 Pro und RFID-Reader

Hallo,
ich habe hier einen LOLIN D32 Pro im Breadboard-Aufbau und sowohl de RC522 als auch den PN5180 zur Verfügung. Ich bekomme aber weder den einen noch den anderen zum Laufen.
Für die Pins nutze ich die settings-lolin_d32_pro.h.

Beim RC522 kann ich mir die Firmware (2.0) anzeigen lassen, aber die Karten werden nicht erkannt. PICC_IsNewCardPresent() liefert false zurück obwohl eine Karte vorhande ist.
Der Reader selber läuft an einem Arduino ohne Probleme.

Beim PN5180 wird gar keine Firmware-Version angezeigt. Der Task scheint gar nicht so weit zu laufen.
Zudem habe ich das Problem, dass der Inhalt der SD-Karte nicht mehr gelesen werden kann, sobald das #define RFID_READER_TYPE_PN5180 gesetzt ist. Die Pins sind aber unabhängig und der Fehler besteht auch wenn ich den Reader nicht angeschloßen habe und nur das #define gesetzt habe.

Habt ihr Ideen was an meinem Aufbau falsch sein könnte?
Danke

Hi,

hast du die Config 1:1 übernommen oder Anpassungen gemacht?

Den Pin RFID_IRQ habe ich auf 5 gesetzt da er ansonsten mit dem Rotary Encoder kollidiert. Betrifft aber nur den PN5180.
Ansonsten habe ich MQTT & NEOPIXEL nicht aktiv.

Welchen RFID hast du eigentlich dran? Für rc522 braucht es nur cs, mosi, miso, sck

Ich hatte erst den RC522 getestet, danach den PN5180. Ging bei beiden nicht.

Die Kontaktierung mit Breadboard ist so eine Sache. Besser ist es, das alles aufzulöten. Hab auch einen PCB für den Lolin d32 pro. Ist gerade im Zulauf. Bei Interesse - melden.

Danke für das Angebot.
Ich probiere es die Tage mal ohne Breadboard aus und gebe dann nochmal Rückmeldung.

So, habe es jetzt ohne Breadboard getestet.
Der RC522 funktioniert ohne Probleme.
Der PN5180 macht mir noch Probleme. So nutzt er in der PN5180.cpp die Standard-SPI Pins und nicht Pins aus der Konfiguration. Das erklärt auch weshalb der Inhalt der SD-Karte nicht angezeigt wurde.
Nach der Änderung der Pins wird der PN5180 auch mit der richtigen Firmware erkannt.
Bei meinem ersten Test wurden die Karten noch nicht gelesen, jetzt scheint es zu laufen. Meine aktuelle Vermutung sind Probleme mit dem Deepsleep bei mir. Ich beobachte es mal.

Unter Plattformio gibt es links oben Project Tasks. Hast du dort den Lolin d32 pro gewählt? Weil den muss man passend selektieren.
Dass Pin-Konfigurationen ignoriert werden ist mir jedenfalls nicht bekannt.

In den Project Tasks ist lolin_d32_pro ausgewählt.
Die PN5180 Bibliothek nutzt im PN5180::begin() den SPI mit SPI.begin() ohne Angabe der Pins. Bei diesem Board ist das aber der SPI an dem die SD-Karte hängt.
Um das zu beheben reicht es im setup() die richtigen Pins zu übergeben:

Diese Zeile ist aber in dieser Konfiguration nicht aktiv.

Da hast du natürlich Recht. Ich hatte hinten dran auch mal einen Kommentar gemacht, dass das vielleicht besser der Default-Case sein sollte.
Ich passe das an.

1 „Gefällt mir“

Danke.

Leider ist das in der PN5180-Library noch nicht gefixt.
CS, BUSY und RST kann man festlegen, die anderen Pins sind fix:

@tueddy du wirst gebraucht! :smiley:

Das sollte machbar sein, wird aber aufgrund Zeitmangels 1-2 Tage dauern.
Sage Euch hier Bescheid sobald verfügbar…

1 „Gefällt mir“

Als Vorschlag für die PN5180-Library würde ich eher ein SPI-Objekt übergeben anstatt der Pins. Ähnlich wie der SD-Klasse für den ESP32. Dort wird auch im begin(…) optional eine Referenz auf den SPI übergeben.
So vermeidet man Probleme mit anderen Bibliotheken welche ebenfalls den SPI nutzen. Dann kann man auf einen anderen SPI ausweichen.

1 „Gefällt mir“

Ich teste das hier später mal:

Kannst Du mir auch als PR senden, ich übernehme das dann!
Schöne Grüße
tueddy

Danke @tyllmoritz , habe das jetzt mal so eingecheckt. Es gab ein Problem mit dem Demo PN5180-ReadUID.ino , es hakte weil sowohl ISO-14443 als auch ISO-15693 ein begin() bekommen müssen.
Habe jetzt nicht verstanden warum das so sein muss, aber eine andere SPI Konfiguration sollte jetzt möglich sein.
Schöne Grüße
Dirk

1 „Gefällt mir“

Danke.
Ich war mir noch nicht sicher, ob es Nebenwirkungen gibt, deshalb gab es noch keinen PR.
Warum begin() doppelt vorkommen muss, verstehe ich auch nicht ganz.

@tueddy
sorry fürs ausgraben des threads.
Aber irgendwie habe ich noch nicht ganz verstanden wie das verändern Ports nach dem Update funktionieren soll.
Meine C++ kenntnisse sind etwas eingerostet von daher evtl. die Verwirrung
Ich kann zwar jetzt ein eigenes SPIClass Object im Konstruktor Übergeben.
Jedoch ist begin() nicht virtual deklariert und deshalb wird jedes mal begin() der parent Klasse aufgerufen egal was für ein Objekt ich übergebe. Wie kann ich also SpiClass.begin hier überladen und die anderen Ports übergeben?

Viele Grüße
GBird