2025-07-13 3:22 PM
Hello,
Despite the mandatory `rfalWorker()` hell
> "It MUST be executed frequently in order to execute the RFAL internal states and perform the requested operations"
... the RFAL is very interesting to have a flexible way to communicate with the ST25R family - current and future (my opinion only :')) Especially for the amount of standards it helps to follow.
But, please, can you consider to make it usable not only for a single chip? It use a lots of unique global variables (gNfcDev, gNfcip, gNfca, etc...), use same timers, communication bus, etc...
All of that make it unusable to control multiple chips, a shame when we now have multi cores ARM :(
2025-07-14 8:28 AM
Hi,
yes carrying an instance pointer would architecturally also be cleaner. But up to now I have not really seen applications employing two (or more) NFC reader chips. Antennas will couple with each other and even if multiple antennas are asked then people look into antenna switches or 2x single ended.
And there is also a cost of having an additional pointer on each and every function.
What is your use case which would require multiple reader chips?
Regards, Ulysses
2025-07-14 9:59 AM
Hi Ulysses!
@Ulysses HERNIOSUS wrote:But up to now I have not really seen applications employing two (or more) NFC reader chips.
As it's impossible with the current RFAL it can be logical ;)
@Ulysses HERNIOSUS wrote:Antennas will couple with each other and even if multiple antennas are asked then people look into antenna switches or 2x single ended.
If antennas on the same PCB (with bad isolation yes), not with external ones - not too near from each others ;)
@Ulysses HERNIOSUS wrote:And there is also a cost of having an additional pointer on each and every function.
Totally agree, but it's nothing now we have very powerfull MCU :), the HAL SPI part for little packets is the real bottleneck.
@Ulysses HERNIOSUS wrote:What is your use case which would require multiple reader chips?
Thank you for reading and consideration :)