有关编写稳定高效的串口通讯的思考 点击:1487 | 回复:6



linkman

    
  • 精华:1帖
  • 求助:0帖
  • 帖子:32帖 | 210回
  • 年度积分:0
  • 历史总积分:833
  • 注册:2002年2月27日
发表于:2004-07-28 10:11:00
楼主
1. 一个完整的帧处理过程 组帧 组帧之后可能有不同的返回值 在发送帧之前作处理 标准发送帧 非标准发送帧 发送数据出错的返回值 在发送帧之后作处理 接收数据前的处理 接收同步数据的处理 等待的数据长度为0的返回值 在有限次接收过程中等待不到同步的返回值 接收数据头的处理 等待的数据长度为0的返回值 等待的数据不足长度的返回值 对数据头的处理 数据头的处理不正确的返回值 接收数据区的处理 等待的数据长度为0的返回值 等待的数据不足长度的返回值 等待的数据长度超出的返回值 接收数据后的处理 对接收数据作处理 数据的效验不正确的返回值 对接收的数据作处理 数据的处理结束后的返回值 返回值: 发送数据出错的返回值 -1 等待的同步数据长度为0 -2 有限次接收中不能同步的处理 -3 等待的数据头长度为0 -4 等待的数据头不足长度 -5 数据头不正确 -6 等待的数据区长度为0 -7 等待的数据区不足长度 -8 等待的数据区长度超出 -9 数据的效验不正确 -10 组帧之后可能作不同的跳转 0-99 数据的处理结束后的正常返回 100-199 2. 帧处理的多个变种 2.1. 只有接收帧,没有发送帧 2.2. 接收帧没有同步数据处理 2.3. 接收帧没有数据头的处理 3. 帧处理常见错误 3.1. 对出错的处理不够全面(帧处理的每一个步骤都可能出错) 3.2. 对异常情况的处理占用太多的CPU时间 3.3. 等待串口数据返回的时间过长 3.4. 等待时间设置不合理 3.5. 对同一个串口中存在多个设备的处理不周全 3.6. 对串口缓冲区中可能存在数据的处理不周全 3.7. 数据的效验不周全 3.8. 多设备的等待延时处理不周全 3.9. 对不合理数据的处理不周全 4. 帧间处理常见错误 4.1. 读写帧的配合关系未处理好 4.2. 对帧处理的时间过长,占用CPU时间太多 4.3. 装置状态的处理不周全 4.4. 对读取成功后的跳转处理不周全 4.5. 对读取失败的跳转处理不周全 4.6. 写命令需要读帧命令,处理时间太多 4.7. 对帧命令的组合效率太低 4.8. 改变接口数据数组越界 4.9. 不完全按接口要求改动返回数据 4.10. 对设备通道的理解不够,未能按要求实现所有功能 4.11. 对折分命令的处理不全面 5. 编写良好驱动程序的注意事项 5.1. 热爱驱动编程,不以完成驱动任务作为目标 5.2. 必须认识到,通讯的每一个步骤都可能出错,并通过编程对每一种可能的出错进行处理 5.3. 仔细对照以上可能出错的列表,判断是否已考虑周全 5.4. 命令返回参数中能将以上帧内处理和帧间处理的可能情况区分 5.5. 必须考虑如何尽量少的占用CPU时间,要将它作为一个重点进行思考 5.6. 驱动编写完毕,必须形成能满足以上所有要求的用例来测试驱动,用例能够重复利用,并形成标准 5.7. 对每一种情况,都要考虑长期拷机实验的用例,要检查是否有内存丢失的情况 5.8. 针对每个常见PLC和设备,都按以上标准严格考核 祝贺MCGS近期推出新功能“脚本驱动程序”,将一篇关于串口通讯的演讲PPT在此发表,希望与朋友多交流。 关于脚本驱动的话题,请见:http://www.gongkong.com/tech/detail.asp?id=247936 有关界面,请见:http://www.mcgs.com.cn/active/disp.asp?id=103



linkman

  • 精华:1帖
  • 求助:0帖
  • 帖子:32帖 | 210回
  • 年度积分:0
  • 历史总积分:833
  • 注册:2002年2月27日
发表于:2004-07-29 16:42:00
1楼
企图在一个开发框架中解决以上所有问题是不可能的,必须有一组方案来配合解决各种情况,平衡驱动功能,驱动速度,软件完善过程等。 目前国内采用串口通讯的产品多之又多,但能象其它领域一样,将这些东西做成模式?

linkman

  • 精华:1帖
  • 求助:0帖
  • 帖子:32帖 | 210回
  • 年度积分:0
  • 历史总积分:833
  • 注册:2002年2月27日
发表于:2004-07-30 12:24:00
2楼
我曾经编过100个以上的设备串口通讯程序,也曾看到或审查别人编写的串口通讯程序,发现很多人员编写的通讯程序,质量非常差,根本不考虑现场的复杂情况,也不考虑各种异常处理,只在实验室成功使用一些简单的数据测试即认为合格。也没有考虑通讯程序对CPU的占有率等,因此,专门针对此方面在公司内作了几次演讲。

deng_lp

  • 精华:5帖
  • 求助:0帖
  • 帖子:65帖 | 2669回
  • 年度积分:0
  • 历史总积分:2876
  • 注册:2001年6月19日
发表于:2004-07-31 08:56:00
3楼
这只是单独已知规约编写。 intouch 中的RPM kit是一个很好架构的通讯程序。 值得大家参考。

AK48

  • 精华:0帖
  • 求助:0帖
  • 帖子:4帖 | 23回
  • 年度积分:0
  • 历史总积分:84
  • 注册:2004年7月23日
发表于:2004-07-31 09:27:00
4楼
INTOUCH的RPM kit很好,实际上在灵活性和简单性方面永远是个矛盾,写通讯程序楼上只是论述了一些常识,有过2年编程经验的人都会注意,真正注意的还是要注意软件整体框架的设计,强烈推荐IFIX的驱动,感觉设计非常完善,应该说是目前最好的。

AK48

  • 精华:0帖
  • 求助:0帖
  • 帖子:4帖 | 23回
  • 年度积分:0
  • 历史总积分:84
  • 注册:2004年7月23日
发表于:2004-07-31 09:29:00
5楼
国内框架较好的应该是亚控和力控,但和国外比还是有一定的差距。

linkman

  • 精华:1帖
  • 求助:0帖
  • 帖子:32帖 | 210回
  • 年度积分:0
  • 历史总积分:833
  • 注册:2002年2月27日
发表于:2004-07-31 17:39:00
6楼
有道理,我只是抛砖引玉,希望各位多发高见

热门招聘
相关主题

官方公众号

智造工程师