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

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

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

ソリューションへジャンプ
1,697件の閲覧回数
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 ? 

0 件の賞賛
返信
1 解決策
1,534件の閲覧回数
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,535件の閲覧回数
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,534件の閲覧回数
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 件の賞賛
返信