Skip to main content
V
Vmai.1
Visitor II
August 28, 2021
Solved

External MCU communicate with ST25RU3993-HPEV

  • August 28, 2021
  • 3 replies
  • 891 views

Hi @D.Cedricalban

Based on your guidance on previous topic, i can execute python on raspi to read the tags.

Currently, we would like to take the external MCU (like ESP32) as a host, implement it communicate with ST25RU3993-HPEV over UART. (please refer to my connection diagram : https://docs.google.com/presentation/d/1jLf4-6HVqBwT_gsOJ8EAMHpnaHdpxnHbBglNnPaBvNI/edit?usp=sharing)

So, I would like confirm that is it possible to implement is that way ?

if it is possible, any example can i refer ? i guess we can not use any example for the host in SDK for this case, because i saw example for host is base on POSIX or WIN32..

thanks

Great to hear from you asap.

    This topic has been closed for replies.
    Best answer by Nick K

    Hi,

    sure, for the HPEV/EVAL board it does not matter what the host system is.

    The current FW uses for host communication an UART that is connected to an FT231X USB bridge. 

    The EVAL FW expects commands to be received over the UART and send data back over the same UART.

    If you use the same UART and bypass the FT231X IC for a direct UART connection then no modifications in FW are needed. 

    If you use a different UART on the STM32L4 for connection to your ESP32 you need to change the UART configuration in the FW.

    NOTE: The EVAL FW use 3Mbaud as UART communication speed. This is needed for fast Reader<->TAG communication (eg 640/FM0) to be able to transmit data as fast as the data is collected from the field.

    Lower baud rates are possible if the ESP32 UART does not support this, but then fast link settings between Reader and TAG may collect data faster then it can be transferred and data will be lost.

    For porting the middleware (host side) to ESP32. In general the middleware (and also the demo code) is written in ANSI C and should be possible to compile as is for your target platform with 2 exceptions

    1. The target platform must supports a compiler to compile ANSI C code

    2. The low layer platform dependent UART driver must be adopted for a different target, if not POSIX compatible. 

    This UART driver should be the only part in the middleware that must be modified to work. ST has currently implemented the UART driver for windows and POSIX.

    The implementation can be found in the in middleware files stuhfl_bl_posix.c and stuhfl_bl_win.c. To extent to a another platform simple extent the middleware with a new UART driver implementation following the same interface definition that can be found the files stuhfl_bl_posix.c and stuhfl_bl_win.c.

    BR Nick

    3 replies

    N
    Nick KAnswer
    ST Employee
    September 7, 2021

    Hi,

    sure, for the HPEV/EVAL board it does not matter what the host system is.

    The current FW uses for host communication an UART that is connected to an FT231X USB bridge. 

    The EVAL FW expects commands to be received over the UART and send data back over the same UART.

    If you use the same UART and bypass the FT231X IC for a direct UART connection then no modifications in FW are needed. 

    If you use a different UART on the STM32L4 for connection to your ESP32 you need to change the UART configuration in the FW.

    NOTE: The EVAL FW use 3Mbaud as UART communication speed. This is needed for fast Reader<->TAG communication (eg 640/FM0) to be able to transmit data as fast as the data is collected from the field.

    Lower baud rates are possible if the ESP32 UART does not support this, but then fast link settings between Reader and TAG may collect data faster then it can be transferred and data will be lost.

    For porting the middleware (host side) to ESP32. In general the middleware (and also the demo code) is written in ANSI C and should be possible to compile as is for your target platform with 2 exceptions

    1. The target platform must supports a compiler to compile ANSI C code

    2. The low layer platform dependent UART driver must be adopted for a different target, if not POSIX compatible. 

    This UART driver should be the only part in the middleware that must be modified to work. ST has currently implemented the UART driver for windows and POSIX.

    The implementation can be found in the in middleware files stuhfl_bl_posix.c and stuhfl_bl_win.c. To extent to a another platform simple extent the middleware with a new UART driver implementation following the same interface definition that can be found the files stuhfl_bl_posix.c and stuhfl_bl_win.c.

    BR Nick

    P
    Prabhu1
    Visitor II
    September 20, 2021

    Can we short the UART pins of ESP32 with EVM board. Does it damage the IC and inhibit the communication?

    N
    Nick K
    ST Employee
    September 24, 2021

    Hi,

    if you mean do bypass the HPEV/Eval board onboard USB connector and connect direct to the UART of the STM32L4 on the HPEV/Eval board, then yes, no problem, you can connect to the UART RX/TX/RTS/DTR pins. These pins are accessible via J7. Then you communicate direct to the STM32L4 UART.

    To be sure that the FT231X (U13) not influence the communication please disable it by remove R6 and short C33, this permanent pull the RESET line of U13 to low.

    NOTE: The RTS and DTR lines of the UART are not used for flow control. They are used to control the boot behavior of the board and connected to Reset and Boot0 pins of the STM32L4 and allow to reset the board and startup the board in bootloader mode.

    BR Nick

    Terms & ConditionsAccessibility statement