Skip to main content
S
SDesa.1
Visitor II
May 11, 2020
Solved

Is it possible to use non-blocking SPI drivers to setup RFID comms using the ST25R3911B and STM32L496 MCU

  • May 11, 2020
  • 1 reply
  • 935 views

Hardware Setup: MCU: STM32L496ZG (Nucleo- L496ZG board) connected to ST25R3911B over SPI, tag is ISO15693 compliant

 Software: Using the rfal library and the iso15693 APIs in en.STSW-ST25RFAL001 (V2.1.2)

IDE: Atollic TrueStudio V9.3.0

Is it possible to use non-blocking SPI drivers to create an RFID comms interface using the ST25r3911B and STM32L496 MCU?

So far I have successfully implemented RFID comms using blocking drivers that involve using the `spiTxRx` function in the platform.h file and calling the `st25r3911Isr()` in the ISR for the INT pin of the STM32L496.

But what happens if I have non-blocking SPI drivers that implement a state machine to handle SPI transactions and is not a single function call like `spiTxRx`? How do I modify the `platform.h` file and use the rfal in that case?

Does the ST25R3911B support RFID comms using non-blocking SPI drivers?

    This topic has been closed for replies.
    Best answer by Ulysses HERNIOSUS

    Hi,

    of course you can do in spiTxRx() what ever you want to, e.g. sleep while the SPI transfer is going on. However on exiting the function the calling code expects the operation to be finished and data to be returned.

    Typically the SPI would be running at something like 2-4MHz and the typical transfers in there are two or three bytes most of the time. So the actual SPI time for 2 bytes is something in the 2us area. Hardly worth to perform any other tasks in the meantime or make use of ISR/DMA. This is why we have refrained from breaking this into smaller (state machine) parts.

    Regards, Ulysses

    1 reply

    U
    Ulysses HERNIOSUSAnswer
    Technical Moderator
    May 12, 2020

    Hi,

    of course you can do in spiTxRx() what ever you want to, e.g. sleep while the SPI transfer is going on. However on exiting the function the calling code expects the operation to be finished and data to be returned.

    Typically the SPI would be running at something like 2-4MHz and the typical transfers in there are two or three bytes most of the time. So the actual SPI time for 2 bytes is something in the 2us area. Hardly worth to perform any other tasks in the meantime or make use of ISR/DMA. This is why we have refrained from breaking this into smaller (state machine) parts.

    Regards, Ulysses

    Terms & ConditionsAccessibility statement