RS 232中断信号

Question

我有一个RS232信号捕获设备.它运作良好.

我需要一些帮助来理解数据.基本上我们买它是因为我们正在处理使用串行通信的80年代后期的机器控制器.尽管知道了端口参数,但我们运气不佳.

从我倾倒的数据中,机器控制使用中断信号作为其协议的一部分.我无法使用VB和MSComm复制它.我知道要打开和关闭中断信号.但我不确定我应该用它做什么.我应该为我发送的每个数据字节保留它.或者发送一个字节的数据然后切换.

我也很困惑,我应该从控制器接收任何数据.打开中断时是否切换标志,然后当它关闭时读取输入？

任何见解将不胜感激.

Answer 1

Michael Burr对破解方式的描述是准确的.通常,"中断"信号的发送时间明显长于一个字符时间.

目前,"Break"在串行通信中很少使用,但最常见的用途是作为提供数据包同步的"廉价"方式.可以在数据包启动之前发送"中断",以警告接收方新数据包正在路上(并允许其重置缓冲区等)或在数据包结束时发出信号,表示不再需要数据.它是一种"元字符",它允许您保留数据包内容的全部8或7位值,而不用担心如何描述数据包的开始或结束.

要发送休息时间,通常会调用SetCommBreak,等待一段适当的时间(例如,在9600波特率下大约2毫秒),然后调用ClearCommBreak.当然,在此期间你不能发送任何其他东西.

因此,假设协议在数据包开始时需要"中断",我会这样做(对于伪代码抱歉): -

procedure SendPacket(CommPort port, Packet packet)
{
    SetCommBreak(port)
    Sleep(2);  // 2 milliseconds - assuming 9600 baud. Pro-rata for others
    ClearCommBreak(port)

    foreach(char in packet)
        SendChar(port, char)
}

接收器的伪代码更加困难,因为您必须对传入的数据包格式和用于接收中断的API调用进行大量假设.这次我会写C,并假设存在虚函数.WaitCommEvent可能是处理传入Break的关键.

bool ReadCharOrBreak(char *ch); // return TRUE if break, FALSE if ch contains received char

我们还假设固定长度的100字节数据包在每个数据包之前发送"中断".

void ReadAndProcessPackets()
{
  char buff[100];
  int count;

  count = 0;

while (true)
{
  char ch;
  if (ReadcharOrBreak(ch))
    count = 0; // start of packet - reset count
  else 
  {
     if (count < 100)
     {
       buff[count++] = ch;
       if (count == 100)
         ProcessPacket(buff);
     }
     else 
       Error("too many bytes rx'd without break")
  } 
} 

警告 - 完全未经测试,但应该给你一个想法......

有关使用Break的协议示例,请查看DMX-512舞台照明协议.

数据包的开始由一个Break表示,后跟一个称为"Mark After Break"(MAB)的"mark"(逻辑1).中断信号表示一个数据包的结束和下一个数据包的开始.它使接收器开始接收.分手后发送513个插槽.

Answer 2

中断信号是无效字符.当RS-232线路空闲时,电压处于"标记"(或"1")状态(如果我没记错,则为-12伏).发送字符时,协议将线路切换到"空间"(或"0")状态一位时间(起始位),然后根据数据(数据位)和任何奇偶校验位切换信号.然后,它将线路保持在空闲/标记(或1)状态,用于由停止位定义的多个位,这通常是可配置的(根据我的经验,通常为1个停止位).

由于总是有一段时间线在数据字符之间处于标记状态,因此始终可以识别字符的开头.这也意味着该行可以处于空间状态的最长时间是:

1 start bit + however many data bits + a parity bit (if any)

中断信号被定义为将行保持在空间状态的时间超过该时间段 - 没有有效的数据字节可以做到这一点,因此中断'字符'实际上不是一个字符.这是一个特殊的信号.

至于何时需要发出中断信号完全取决于所使用的协议.