Library for MFRC522 ?

[fishpoke]

Hi community,
is there a library which supports a MFRC522 RFID Reader via SPI ?
I couldn't get to work my card because of incompatibilities with Miguel Balboa's library. I have also tested some other libraries without success.

Thanks in advance for any hint !

[madias123]

Tested with PI Pico, using latest https://github.com/miguelbalboa/rfid
Device: "RFID-RC522" -> the standard china blue PCB
Test sketch: "Dump Info"
Connected PIns:
(MFRC522 Module - RP2040)
SDA: GP17 (= CS)
SCK: GP18 (standard SPI0)
MOSI: GP19 (standard SPI0)
MISO: GP16: (standard SPI0)
IRQ: NC (for this sketch not needed)
RST: GP9

Runs fine on first attempt.

Please retry it and post your defined problem (i.e. sketch example)

[SteveJ789]

Hi,

I to am having problems in trying to get an MFRC522 working with Arduino-Pico and a RPi Pico. I have followed Madius123 to the letter and when I try to verify/compile, I just get an 'Exit Status 1' error along with the following error message:

c:\Users\steph\Documents\Arduino\libraries\rfid-master\src\MFRC522Extended.cpp:847:42: error: ordered comparison of pointer with integer zero ('byte*' {aka 'unsigned char*'} and 'int')
847 | if (backData && (backLen > 0)) {

Being a bit of a 'Newbie' with all this, I'm not sure what the above error message is trying to tell me. These sketches verify/compile and run fine on my Arduino Nano/Uno/Mega boards and an ESP32 Wroom. It is only when trying to use the RPi Pico that I get this problem.

I have made sure that the cable connections are good and the Reader and RPi are working correctly. I have noticed elsewhere on the web that this seems to be a problem.

I would be very grateful for any suggestions.

[earlephilhower]

That library is trying to do a signed comparison of a pointer to an integer which is not legal. It may have compiled at some point, but I bet it's a bug given the code around it.

[SteveJ789]

Thanks for your reply. It's a bit confusing as some claim to have this example sketch working and others do not, like myself. I'm not sure where the bug might be, given that the sketch works on a Nano/Uno/Mega and ESP32. There are only really two libraries in use, the MFRC522v2 and SPI.h. Would leave it as something to do with the Pico and Arduino-Pico?

I'm not sure how to proceed from here, so any suggestions would be gratefully received!

[earlephilhower]

AIUI, this illegal operation was initially just a warning (which are, unfortunately, disabled by default in the Arduino IDE!) in earlier GCCs. At GCC 12 it's an error and stops compilation. There's actually an open issue in the library repo referencing this from a couple years ago.

You could try replacing the backLen > 0 bit with something legal like a null check backLen != nullptr in the library code. Can't comment on whether there are other issues with the library.

[SteveJ789]

Thank you for your suggestion, much appreciated. I am also using the MFRC522 library with other boards, such as various Arduino's and ESP32's. The library works fine with them. My concern is that if I alter the library to work on a RPi Pico, will it 'break' the library for these other boards?

[earlephilhower]

The library is broken already. You can't check a pointer for positivity, it doesn't make sense (there is no law against pointers having their MSB set!). I suggest you give the change a try and do some testing. In most (all) cases that comparison will be true just because the memory maps work out that way.

[SteveJ789]

Earle,

It worked! Thank you very much for your suggestion. I modified the library as suggested. It actually needed altering at Line 824 and Line 847. The code now compiles correctly and successfully uploads onto my RPi Pico W's. I connected an MFRC522 reader and the Pico successfully read the card and displayed on the Serial Monitor.

During compiling, you do get a warning that the MFRC522 is not guaranteed to work, but the code compiles nevertheless and certainly seems to work.

Thanks again

[earlephilhower]

Great to hear! You might want to suggest a PR to the library owner. They might not have run into this themselves but you seem to have found a problem and a fix for it...