要求非常抗干扰的串口，我这样处理，请大家帮忙看看有什

只看该作者 · 2008-11-27 08:01

我的串口程序可以说是上位机给下位机发送命令用的。
发送与接收都是用中断模式。
1，上位机发送一个12字节的命令帧，其中前8个字节是指令/数据，后4个字节是CRC-32校验码。
2，下位机通过一个volatile声明的计数变量从中断中循环接收12个字符。
3，下位机校验收到的前8个指令/数据字的CRC并与后4个字节CRC码比较。
4，如果相等则存入命令栈中等待执行，并发送0xFF（11111111B)表示接收正确，如果不相等或者命令栈满了则发送0x00(00000000B)要求重发。
5，（这一步我都觉得太夸张了）上位机接收到下位机返回的那个字节，并逐位分析，如果1的数量≥4个则判定下位机接收成功，如果1的数量＜4个则判定下位机接收失败要重发，这样的话关键的返回值受干扰翻转了也没事，总不能在一个字节内给我连错4个吧- -
===================================================================
上位机和下位机都用的ARM7核，运算速度应该够，大家怎么看呢？

只看该作者 · 2008-11-27 10:27

如果把第四步也用类似第一步的格式（用返回FF,00我觉得不可靠），可以去掉第五步。校验不通过可以申请重发，或者用超时重发。用不着连续发4次吧。

1万 · 2008-11-27 15:33

  1. 数据/指令格式要求-->包头+(设备号)+流水号+类型+(包长)+包内容+校验+(包尾), 括弧内不具体要求, 包头尾间内容顺序不做要求, 流水号的处理比较重要

  2. 各方接收缓冲池的处理, 包头不匹配时只能丢弃包头第一个字节, 继续在池内查找包头, 不能整个包甚至整个缓冲池丢弃

  3. 一般过程(从机无主动过程)
    主从均有超时处理 --> 一种是未收到应答, 回若干次; 再是收到应答后超时, 处理流程比较复杂, 也可以简单处理
  (1/主)指令包
  (2/从)指令应答包[可以短至一个字节, 但有些条件下可以考虑做长包-即包头+从机流水号+类型+(校验)+(尾巴)]
  (3/主)无须应答
  (4/从)指令执行结果包
  (5/主)结果应答包
  (6/从)无须应答

  4. 校验一般两个字节就够了, 当然资源多可不管

只看该作者 · 2008-11-27 19:03

To Mr.lws
    其实我所指的应答帧0xFF,0x00。前者（代表正确）含有8个二进制1，而后者（代表错误）含有8个二进制0，如果0xFF中有一位出错，成了0xFE，那么含有二进制1的个数仍然占多数，主机判定从机应答正确信号。
    串口发送在8位中连错4位...概率应该是超低的吧

To Mr.wh6ic
    具体的系统中，下位机其实是用栈的方式保存命令但并不是立即执行的..要等系统的一轮动作完毕后才会读取这些指令（参数设置为主）然后更新内部设置后进行下一轮的动作，所以从机只能在第一时间应答“命令接收成功/失败”的状态，而无法立即应答“指令执行结果”...所以现在我考虑的就是如何将指令送入从机并保证从机正确接收。
    由于从机内存紧张，所以缓冲池做得不是很大，指令栈的大小也是确定的，因为每次系统开始新一轮动作时就会发送【开始运行】的状态字给主机，然后主机在收到【运行结束】的状态字前发送的指令是有条数限制的（这个限制就是从机指令栈的最大指令存放条目数），多余的会在收到下一个【开始运行】状态字时被送往从机。毕竟主机只是提供人机界面而已，所以主机采用死等之类的笨办法也无关紧要的..
    包头+(设备号)+流水号+类型+(包长)+包内容+校验+(包尾), 这个倒是没考虑过...看来还是规范点的好...根据需要我改成了：包头+流水号+指令字+参数表+校验+句尾的结构了~~正好明天去试试看...