2012-01-03 80 views
1

任何人都可以与我分享什么正确发生(或意图发生......)在RS232通信时,当RTS或CTS线的状态改变的任何信息?RS232握手 - 详细发生了什么?

我正在研究一个应用程序,在该应用程序中,通过Qt的QextSerialPort库连接到串行端口的PC与Atmel AVR微控制器进行通信。有时微控制器必须做些事情(检查ADC,时间精确的时间间隔等),要求它禁用其内部中断,并因此暂时关闭其UART端口。我正在使用RTS/CTS握手信号,以便AVR在将要通过将其RTS线路拉高来关闭其端口时向PC发出信号,并通过再次使RTS变为低电平来通知重新打开端口。

基本上这个功能很好,但是我仍然不清楚如果RTS设置为高电平而在通过任一方向传输的中途有一个字节时会发生什么。在AVR方面,我可以在很低的水平上控制事物,但在PC端,我只是将QextSerialPort置于硬件流控制模式,这使得它可以执行底层的Windows功能。我想知道这里的行为不匹配可能是我在传输中偶然出现的一些故障的解释。

回答

0

AFIAK,只有在字符之间的“空闲时间”内,RTS行才能在字节传输过程中被声明。

问题是,握手几乎从未正确执行。 Windows 应该符合标准(或维基百科条目),但我无法证实这一点。

1

不,这很麻烦。 RTS/CTS握手由驱动程序执行,而不是UART。当CTS关闭时,它会停止将字节写入发送器FIFO。你将会得到飞行中的字节以及FIFO中仍然可以传输的任何信息。如果接收器FIFO不够大并且中断关闭时间过长,这肯定会出错。 PC端的FIFO为16字节,取决于硬件。不知道AVR,你没有提到一个模型。

一定要在AVR端执行缓冲区溢出检查来诊断这种事故。降低波特率是一种便宜的解决方法。

+0

这是照亮,谢谢你;我不知道当CTS上线时USART继续工作,我认为它只是在它的轨道上停下来(或者最多传输了当前字节后)。这也许可以解释我偶尔看到的其他一些奇怪的效果,虽然也许不是我现在正在处理的那个。 – 2012-01-03 22:12:48