Skip to main content
R
Ricko
Graduate II
October 22, 2024
Solved

Simplest Reader and Reader/Writer ICs?

  • October 22, 2024
  • 1 reply
  • 1989 views

Hi,

as part of an upgrade to a number of products, we are looking at integrating 13.56MHz RFID capabilities into a number of products. Some require only to read an RFID card and others need to read and write such RFID card (no mobile devices or anything else). The RFID card type/protocol we can choose based on the IC (the ISO14443A looks a common one).

In all products the RFID reader/reader-writer ICs will be interfacing with an STM32.

 

Time to market is very important so we are looking at some solutions that already have drivers available for at least the basic functionality which is just to:

- program an RFID card with a person name or just their ID

- read such RFID card details (Unique ID and person name or person ID)

That is it... It is just to display data customised to a user preference in a dispensing system. So it does not need to be secure or have extra checks or have any other special feature. Low cost and quick time to market are more important than features.

 

Ideally we would like to have a driver take care of reading the data automatically when a card is placed in the antenna reading range and then signal the application layer when the data has been read. Nothing more than that.

The devices we are looking at at the moment are:

- ST25R95-VMD5T
- ST25R100-CMET

They seem to be SPI only but if there are other low cost alternatives (perhaps ST25R3918 ?) that meet the requirements that have I2C interface we would prefer them (speed is not important).

Do they have ready-to-use STM32 drivers for the basic functionality?

If not, which ICs do?

If both of the two parts I listed above meet all criteria, is there any advantage in using one over the other specifically for the application I described?

Thank you:)

    This topic has been closed for replies.
    Best answer by Brian TIDAL

    Hi Ricko,

    ST25R3916(B) and ST25R100 are Analog Front Ends (AFE). They manage the RF modulation/demodulation, the bit coding/decoding etc. and need to be controlled by an host that configures the various protocols, read and write the NFC frames from the device FIFO.

    ST25R95/CR95HF has an internal MCU but basically acts as an Analog Front End and need as well to be controlled by an host. The working model is different e.g the host does not read or write directly into the device FIFO but uses a sendReceive command to request the sending of a frame and will receive the tag response as a response to this sendReceive command. At the end, an host MCU is needed to sequence the various commands.

    So even if the ST25R95/CR95HF has an internal MCU, the command/response part of the NFC protocol runs on an host MCU and this is the same code that is used on all ST25R devices. The only difference is the driver part. For ST25R3916(B) or ST25R100 drivers, a light overhead can be foreseen but it has never been an issue for real customer applications.

    Regarding the polling demo, I am sorry about the confusion. In NFC terminology, an NFC reader/writer is called a "poller". The "polling" demo demonstrates the way this poller works: detection of tags for various technologies, collision resolution to retrieve the identity of the various tags being in the operating value, activation of one of the tag and then some basic communication (e.g. to read the content of some blocks of the tag memory). The demo automatically performs all those activities and displays the UID of the tag on the serial console. This "polling" demo is often used by customer as a basis for their own application. 

    Regarding your last request: on https://www.st.com/en/nfc/st25-nfc-readers.html, the overview tab provides a comparison of the various devices from the ST25R NFC reader portfolio based on the output power. The product selector tab provides detailed comparison based on the various features and the various packages.

    If you hesitate between different products, do not hesitate to assess them thanks to the X-NUCLEO-NFC expansion kits.

    Rgds

    BT

    1 reply

    B
    Brian TIDAL
    Technical Moderator
    October 22, 2024

    Hi Ricko,

    All readers from the ST25R family (ST25R95, ST25R100, ST25R3918, etc.)  support the same RF Abstraction Layer library (RFAL) and have their own drivers.

    Expansion kits are available for each of these readers:

    Those expansion kits can be plugged on top of STM32 NUCLEO boards.

    Firmware packages are available for each expansion kit with some ready to use demos on STM32 MCU:

    As the RFAL provides the same API for each reader, the same application can run if you migrate from one reader to another one: the application just needs to be recompiled with the appropriate drivers.

    Regarding the communication interface,

    • ST25R95 supports SPI and UART
    • ST25R3916(B) series devices support SPI and I2C
    • ST25R100 supports SPI.

    I would suggest to prototype your application with one or several of the X-NUCLEO-NFC expansion kits and to assess the performances.

    Rgds

    BT

      R
      RickoAuthor
      Graduate II
      October 22, 2024

      Thank you @Brian TIDAL

      we also just looked at the CR95HF. Is it correct that then comparing the ST25R100 to the CR95HF one major difference is that the ST25R100 needs the micro to do all the communication handling while the CR95HF does it in hardware? in other words the the full stack is implemented in software for the ST25R100 while it is implemented on the transponder IC for the CR95HF?

       

      If so, how can we quantify the amount of overhead taken by the driver?

       

      Also when you say "X-CUBE-NFC9 (ST25R100) / X-CUBE-NF6 (ST25R3916(B) series) that are integrated with STM32CubeMX with a polling demo" why using a polling instead of an interrupt driven demo? And is the polling just checking the IRQ line from the reader IC or checking via software?

       

      Also for future reference, is there a detailed comparison table for all NFC ICs like those mentioned above?

       

      Thank you

      T
      Tesla DeLorean
      Graduate II
      October 22, 2024

      By and large "demos" are provided as an illustration of "look it works", and not commercially deliverable products with all the arguments over "what" and "how" something needs to do it in the real-world application of the technology.

      You are likely going to need to add the "VALUE" or pay for the "VALUE", I'd assume most of this stuff would take a significant amount of engineering effort to be simple.

      Perhaps there's a local sales office or rep for the ST NFC/RFID lines that you can have more specific conversations with, and engineering resources they can direct you too?

        Terms & ConditionsAccessibility statement