MPC57xx howto add UART hardware flow control (CTS/RTS) ?

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

MPC57xx howto add UART hardware flow control (CTS/RTS) ?

跳至解决方案
1,642 次查看
ruudsiebierski
Contributor III

I'm trying to add hardware flow control (based on CTS/RTS) to the MPC5748G UART. The MPC is connected to a FTDI2232H in UART mode, and I have a .NET application running on the PC which sends serial data using the virtual COM port.

Basically the setup works, when I de-assert the RTS output of the MPC, the transmission of data stops, but not immediately. It seems that 1 byte is still sent which causes a buffer overrun error on the MPC side.

Is there a recommended way on how to implement hardware flow control for the MPC ? 

标记 (3)
0 项奖励
1 解答
1,479 次查看
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi,

hardware flow control is not implemented in the microcontroller, so this feature must be implemented by software using GPIO pins. I'm not aware of an application note or general recommendations about this.

"Basically the setup works, when I de-assert the RTS output of the MPC, the transmission of data stops, but not immediately. It seems that 1 byte is still sent which causes a buffer overrun error on the MPC side."

- The effect is usually not immediate - transmission can be already in progress, so the receiver needs to be still prepared.

It's similar to Xon/XOff flow control. When XOff character is sent, receiver may still receive some next characters because it takes time to send the character, transmitter has to process the command and then current transmission must be finished.

Regards,

Lukas

在原帖中查看解决方案

0 项奖励
2 回复数
1,480 次查看
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi,

hardware flow control is not implemented in the microcontroller, so this feature must be implemented by software using GPIO pins. I'm not aware of an application note or general recommendations about this.

"Basically the setup works, when I de-assert the RTS output of the MPC, the transmission of data stops, but not immediately. It seems that 1 byte is still sent which causes a buffer overrun error on the MPC side."

- The effect is usually not immediate - transmission can be already in progress, so the receiver needs to be still prepared.

It's similar to Xon/XOff flow control. When XOff character is sent, receiver may still receive some next characters because it takes time to send the character, transmitter has to process the command and then current transmission must be finished.

Regards,

Lukas

0 项奖励
1,479 次查看
ruudsiebierski
Contributor III

Hi Lukas,

Thanks for the feedback. It would be nice to have some kind of "BUFFER_ALMOST_FULL" callback mechanism implemented in the Linflex driver, where the user (me) is able to do hardware flow control. Off course I can implement it myself.

Anyway, thanks :smileyhappy:

Best regards,

Ruud

0 项奖励