Yes, correct. That was the standard connection.In the first of those two diagrams, the one connecting the RC522 to SPI0, the 3.3V pin on the RC522 is connected to a 3.3V pin on the Pi - pin 17. Note that this pin is connected to the 3.3V power rail, not to any GPIO.
As per Pi documentation output current on a GPIO pin is 10mA. This seems not to be enough to power up RC522 but I tried at my risk and it worked. Of course, my pi power supply has enough to do all and for the final configuration, I’ll use another pin configuration perhaps using a parallel bar (I remember that touch screen connector uses first 26 pins).In the second diagram, the one aimed at SPI1, the 3.3V pin is connected to GPIO13. GPIOs, even when they are outputs driving high, can't source enough current to power much more than an LED, and trying to do so could damage your Pi. You are going to have to use pin 17 or pin 2 instead.
I can agree.I can see that even in the original configuration the IRQ line was tied to GND - a detail you've preserved. However, I think it's unnecessary - it's an output from the RF522 and can be left disconnected if we don't care about the IRQ signal.
Official documentation talk about then we have No reference to RST which, if I'm not wrong, means it is not defined per default and of course it could be both GPIO25 or GPIO26. Again, if I’m not wrong, RST is used to reset the module using the pin hight value. Am I wrong?I've remembered an old tutorial I that includes wiring for SPI0 and SPI1: https://github.com/raspberrypi/linux/issues/2613
Comparing this to yours made me realise that you may also need to update your software to tell it that the RST signal has moved from GPIO25 to GPIO26.
Then, when you talk about software, what are you referring to? The RC522 libraries do not carry references to RST. Where can I find it?
If I'm not mistaken, I have already tried this solution with a single chip enabled and it produced no different results. I'll check it again asap.Finally, it seems that your RC522 is wired up to use spidev1.0. Unless you are planning to run multiple devices on SPI1, there is no reason to configure GPIOs 6 and 12 as CS1 and CS2 - use this instead:
I therefore switched to the solution with 3 chips enabled because I hypothesized a conflict at some level between spidev1.1 and spidev0.1 (that of the graphics function of the touch screen) or between 1.0 and 0.0.
It seemed to me that leaving 1.0 and 1.1 free and moving to 1.2 directly could be a solution but that wasn't the case. So then I left it like that.
Statistics: Posted by PiscoM — Fri Mar 08, 2024 4:53 pm