Effective use of interrupts

[fabianoriccardi]

Hi everyone,
I was carrying on a project in which multiple RFID readers are involved (i.e. 10) and I need to recognize when the card is removed.
Actually this system work, and to detect the card removal I use the well-known trick of "double read":

bool result1 = mfrc522.PICC_ReadCardSerial();

bool result2 = mfrc522.PICC_ReadCardSerial();

and then I check both the value of result1/2. However my problem is that a single PICC_ReadCardSerial() usually takes 25ms.
So to perform a full loop, of 10 MFRC522 takes about 500ms, making the system not very responsive.

So I started to wonder about interrupt, but it seems that the library do not support this "advanced feature" and interrupts are left to the user code.

Unfortunately, the bottleneck I have highlighted resides at the core of the library (in PCD_TransceiveData()), which takes usually 25ms (and 37ms in the worst case) to return. In this time it basically waits for a predefined timeout while polling the interrupt register of the MFRC522

Is it possible to improve this aspect? Are there reasons to abandon the idea of using interrupts in the library? Are there alternative libraries for rfid making smart use of interrupts? (I had searched but I don't find valid alternatives).

I would ask to the community if anyone has meet or wondered about this problem. In case I may help with the code, it is a pity that such a great library doesn't fully benefits of interrupts.

[Rotzbua]

Are there reasons to abandon the idea of using interrupts in the library?

Interrupts are not easy to manage. They can cause a lot of site effects and problems. The target group of this library are makers and not full stack embedded devs.

To detect presence, rfid is not a good choice. I would recommend to use in addition e.g. light barriers to decrease detection time.

If you implement the interrupt function, you have to fork or make a pr to my fork #522 because I will not add new features to this library.

Best

[fabianoriccardi]

I would recommend to use in addition e.g. light barriers to decrease detection time

This is interesting and for sure I will try, however it think it leads to higher hardware cost (the light sensors), increases the assembly time, and also the case should allow the light flow in. So if a "good" software solution is available, I would prefer it.

In the next days I will look at your fork, thanks.

[srcastor]

Hi everyone, I was carrying on a project in which multiple RFID readers are involved (i.e. 10) and I need to recognize when the card is removed. Actually this system work, and to detect the card removal I use the well-known trick of "double read":

bool result1 = mfrc522.PICC_ReadCardSerial();

bool result2 = mfrc522.PICC_ReadCardSerial();

and then I check both the value of result1/2. However my problem is that a single PICC_ReadCardSerial() usually takes 25ms. So to perform a full loop, of 10 MFRC522 takes about 500ms, making the system not very responsive.

So I started to wonder about interrupt, but it seems that the library do not support this "advanced feature" and interrupts are left to the user code.

Unfortunately, the bottleneck I have highlighted resides at the core of the library (in PCD_TransceiveData()), which takes usually 25ms (and 37ms in the worst case) to return. In this time it basically waits for a predefined timeout while polling the interrupt register of the MFRC522

Is it possible to improve this aspect? Are there reasons to abandon the idea of using interrupts in the library? Are there alternative libraries for rfid making smart use of interrupts? (I had searched but I don't find valid alternatives).

I would ask to the community if anyone has meet or wondered about this problem. In case I may help with the code, it is a pity that such a great library doesn't fully benefits of interrupts.

Hi Fabian, I have exactly the same problem did you make any improvement this time? Also can you give me more info about the "double read" trick? Thanks