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

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

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

跳至解决方案
485 次查看
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)

 

标记 (3)
0 项奖励
回复
1 解答
451 次查看
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 项奖励
回复
1 回复
452 次查看
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 项奖励
回复