|
工作半年，参与的项目里都存在需要外接的设备或是板上的芯片，这些东西都有一个共性，就是需要通过各种通信方式对设备进行控制或是从设备上获取数据，有官方现成驱动的使用官方现成驱动就好，一般问题不大，但是如果有官方驱动效果差或者是官方没有提供驱动的情况就需要自己动手丰衣足食了。
该博客仅针对外设官方驱动不满足项目需求或者是官方只给了电文及变量列表，也就是DataShell的情况给出我的一点点建议；
1、磨刀不误砍柴工
这些外设通常都是通过一些通信接口来与MCU通信，我主要见过的通信方式包括串口（TTL、RS232以及RS485）、CAN、SPI、IIC，其中串口和CAN多用在拉线接的外设上，SPI和IIC都是板上通过PCB的电路与MCU连接的芯片，正所谓磨刀不误砍柴工，意思是需要优先把这些东西的通讯方式建立成一个体系，保证通讯不容易出现意外情况，出现意外情况需要有对应的修复手段。以串口设备为例，当前串口设备较为常见的两种，第一种是基于ModbusRTU从站作为通信接口的设备，第二种是基于AT指令集设备，第二种设备多用在通信模块上；
针对这种设备在开发的过程中，首先需要完善串口的收发功能。
一般方法为：
发送：在程序中循环调用串口发送函数，串口调试助手监控，不丢数据为佳；
接收：使串口调试助手循环发送不同数据，MCU串口接收中断处理正常、不会卡死为佳；
串口卡顿修复：串口在遇到意外情况下卡死（原则上不允许），需要有办法将串口复位
2、构建通讯协议框架
这个比较宽泛，需要对照被通信对象厂家的数据手册，针对性的写通讯协议框架。
以ModbusRTU协议为例，电文结构为站号、功能码、数据起始地址、数据长度、CRC校验，就要定义对应长度的数组，将被读对象的站号、功能码、数据地址、长度以及CRC计算好填入数组，并通过串口进行发送，待数据返回后进行解析，获取需要的数据即可。
3、压力测试
一般写好的通讯代码，除非是经验丰富的老师傅，不然写完之后一段时间，通信或多或少会出现故障问题，所以针对战场新兵就需要进行压力测试，完成一次通讯做一次通讯成功加计数，通讯失败一次就对通讯失败进行一次加计数，运行一天两天的样子，看看通信成功和失败计数值是否在合理范围内，不在就需要分析代码是否存在问题，在合理范围内的话就可以暂时告一段落，等待甲方提奇奇怪怪的需求了。
4、错误代码记录
除此之外，外部设备也有自己的运行逻辑，同样也有自己的错误情况，除了我们自己的MCU和设备的通讯故障之外的问题，这些问题厂家一般会给出错误代码以错误代码对应的解决方案，一般按照官方解决方案进行操作就没问题，但是遇到也是在开发阶段的官方，且错误代码不全，处理方案也不全的情况下直接用复位初始化大法，因为设备故障之后我们是不能相信它的，预期带着一只坏掉并且修不好的手，不如砍了重新长。
一般做到以上几点，外部设备还搞不定的话，我个人就认为可以换一家的设备了；
一般在完成了整个设备的设计后，就需要再次进行压力测试，也就是在一个安全的环境内，模拟出设备以后的真实情况，进行长时间通电测试，看设备会不会出现故障，且出现故障之后会不会自行修复，当上述测试通过之后就可以转载盒子里，拿到市场上去售卖了。
|