S32K3 RTD 5.0.0 - LPUART - Distinguishing between TX and RX when 'end transfer' indicated?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

S32K3 RTD 5.0.0 - LPUART - Distinguishing between TX and RX when 'end transfer' indicated?

Jump to solution
480 Views
BStout
Contributor I

I'm coding up some board support software for a S32K344 processor, working with S32K3 RTD 5.0.0 and specifically using the Lpuart_Uart_Ip for full-duplex asynchronous (interrupt-driven) transmit and receive operations.

The problem: It seems there is no direct way to distinguish, when receiving a callback with event LPUART_UART_IP_EVENT_END_TRANSFER, whether the callback is associated with an outstanding TX or an outstanding RX operation.  (This event is generated by both.)

After examining the Lpuart_Uart_Ip.c implementation, I've determined a somewhat convoluted way to disambiguate in my use case.  Specifically:

  • I keep track of whether I'm expecting an imminent RX 'end transfer' event.  I expect an imminent RX 'end transfer' event when: 
    • 1) I have received a callback with LPUART_UART_IP_EVENT_RX_FULL event, AND
    • 2) I have not reset the receive buffer  to non-zero size within that callback, e.g., via Lpuart_Uart_Ip_SetRxBuffer().
    • 3) I have not yet received the expected callback indicating the 'end transfer' event.
  • When I am expecting an imminent RX 'end transfer' event, I assume the callback is for the outstanding RX operation.
  • When I receive an 'end transfer' callback under other conditions, I assume the callback is for the outstanding TX operation.

Perhaps I'm missing something - is there a better way to disambiguate?  Other RTD implementations have separate RX and TX callbacks, but that isn't the case here.  My suggestion would be to have separate 'end transfer' event type enumeration values for RX and TX, but I realize that such a change to the API wouldn't be backwards-compatible, and probably couldn't be instituted before the next major RTD version (e.g. 6.0.0)

 

Tags (3)
0 Kudos
Reply
1 Solution
446 Views
PetrS
NXP TechSupport
NXP TechSupport

Hi,

Currently, the implementation does not differentiate between TX and RX end events directly. Your proposed method could be beneficial. If Lpuart_Uart_Ip_SetRxBuffer is not invoked during the LPUART_UART_IP_EVENT_RX_FULL event, the callback for LPUART_UART_IP_EVENT_END_TRANSFER will be triggered immediately without being interrupted by another event. Therefore, if a user flag is set during the LPUART_UART_IP_EVENT_RX_FULL event when SetRxBuffer is not called, this flag can be utilized in the LPUART_UART_IP_EVENT_END_TRANSFER event to identify that it pertains to the RX event, and the flag can then be cleared.

Ideal proposal is to split EVENT_END_TRANSFER by EVENT_END_TX_TRANSFER and EVENT_END_RX_TRANSFER as you mentioned, but not sure if it is planned for next revisions. But you can test this as well.

BR, Pert

View solution in original post

0 Kudos
Reply
1 Reply
447 Views
PetrS
NXP TechSupport
NXP TechSupport

Hi,

Currently, the implementation does not differentiate between TX and RX end events directly. Your proposed method could be beneficial. If Lpuart_Uart_Ip_SetRxBuffer is not invoked during the LPUART_UART_IP_EVENT_RX_FULL event, the callback for LPUART_UART_IP_EVENT_END_TRANSFER will be triggered immediately without being interrupted by another event. Therefore, if a user flag is set during the LPUART_UART_IP_EVENT_RX_FULL event when SetRxBuffer is not called, this flag can be utilized in the LPUART_UART_IP_EVENT_END_TRANSFER event to identify that it pertains to the RX event, and the flag can then be cleared.

Ideal proposal is to split EVENT_END_TRANSFER by EVENT_END_TX_TRANSFER and EVENT_END_RX_TRANSFER as you mentioned, but not sure if it is planned for next revisions. But you can test this as well.

BR, Pert

0 Kudos
Reply