工作日记：：测试日记：：调试CAN&RS485

0.预备工作：

1. • 配置编译需要测试的设备的驱动与接口。（scons --menuconfig 打开配置界面）

1Kconfig机制：通过编写Kconfig设置好可供开发人员配置的配置项及默认开/关。

配置完成后会自动生成.config文件与rtconfig.h文件，通过宏的方式配置编译哪些c代码编译。

2.结合Scons：rtthread.py ; sconstruct.py ; sconsript.py

-- rtconfig.py ---- 控制SCons构建的配置文件，存放了如工具链，构建参数等配置。
-- SConscript ---- 各级源码的scons子脚本，控制当前级别下的源码构建行为
-- SConstruct ---- SCons的入口脚本，初始化了SCons构建rt-thread所需的必要环境

注：记得将自己写的代码的路径写到当前目录的编译构建脚本SConscript中。

1. 打开脚本

2. 复制自己代码的路径

3. 按原有的脚本编码风格，将路径加入进去或替换原有的同功能代码。

一、调试CAN&RS485

整体逻辑：

1、芯片1：：CAN-->芯片2：：CAN-->芯片2：：RS485-->芯片1：：RS485

2、芯片1：：RS485-->芯片2：：RS485-->芯片2：：CAN-->芯片1：：CAN

代码模块：

1、逻辑1：：芯片1

CAN设备发送数据模块；RS485接收数据模块；发送接收同步问题

2、逻辑1：：芯片2

一些问题总结：

1. RTT有自动清空缓存的机制，rt_device_read获取读取的内容后，不需要手动清空缓存

2. 逻辑1：

CAN发CAN比较好调，一般都是电源供电问题，或者是明显的逻辑错误

（协议和接口都比较好，确定接线和供电没问题，基本就顺着改代码就行）

CAN转485，纯代码逻辑

485发485：容易出现丢包，

一串数据一起发会少触发中断，

一个一个发时间比较长，也涉及丢包问题，发数据和触发的中断数不一样：初步猜测

少接收到数据或接收到数据后没有触发中断、、

排查方法：将接收到的数据size打印出来

接收回调函数会读取 ：size：缓冲区数据大小

RTT有自动清空缓存的机制，rt_device_read获取读取的内容后，不需要手动清空缓存

二、重新设计：用数据回环测试

优点：解开两个模块的耦合，方便定位错误并修改、

设计逻辑：

芯片1：：CAN发-->芯片2：：CAN收-->芯片2：：CAN发-->芯片1：：CAN收。（没问题）

芯片1：：RS485发-->芯片2：：RS485收-->芯片2：：RS485发-->芯片1：：RS485收。

问题排查定位于修改、

问题1：芯片1：：发送成功；芯片2：：没有/少触发接收回调。

可能性猜测： 1）没有接收到数据 2）接收后没有触发回调

排查： 直接while（1）读数据，读取失败，确定是可能性1。

可能原因： 未有相关知识储备；百度：rtthread RS485 数据回环 发送8个数据只接收到7/3/0个数据。

相关可能性尝试：

RT-Thread-STM HAL 串口中断接收丢失数据问题讨论RT-Thread问答社区 - RT-Thread

RT-Thread-同时打开CAN与RS485的通讯，RS485无法正常通讯RT-Thread问答社区 - RT-Thread

解决问题过程中的几个神奇现象：

1、485接收数据非常的稳定的 为7|3|0 很奇怪， 每个地方丢的不一样，但在各个地方都很稳定，代码逻辑基本复制，很无解、、、、

是串口参数配置有问题，还是串口的控制引脚配置逻辑有问题？？

2、芯片1：：同样的代码，发在主线程，收在串口线程，稳定丢一个数据；全放到线程里，突然之前稳定丢一个数据的地方就可以了，这么神奇吗？

是半双工问题？收发时间不能重叠？ 都在同一线程里可以做到收发同步？

也不太可能，芯片1：：发==>芯片2：：收 这也不是线程同步问题。

问题2 ：对问题1的进一步确定：

逻辑1：main发-->CAN收：在单独的线程里发，CAN可以完整的收到数据。主线程会丢一个包。

1.此处猜测是发送逻辑的问题，虽然发没有报错，但改了发送后好了。推翻了前面的猜测，

逻辑2：CAN发-->main收：

1. 吸取上面的教训，main收不到时，改了CAN的发送：

1）另起一个线程给CAN发送（加入了信号量做线程同步）；

2）从接一个发一个，改为：全部接收后再一个一个发送。

效果：果然main接收到了数据，但是还有丢包，还是之前的问题，少一个数据？？？

所以之前另起一个线程并不是解决丢包问题的核心原因。

2. 同步改变的还有main芯片端的接收逻辑，当采取信号量等待时，只能接收到一个数据；注销掉带去直接延时两秒做同步时，接收到19个数据。（推翻了前面的猜测，并不是单纯发送端的问题）

终于发现，是个延时的问题，你要延时等所有的数据都接收了之后再去读取，此时是可以接收到19个数据的，（只触发了19次中断回调）。

猜测原因：485半双工问题？ 那也没道理接收完了才能读、、；应该是发送接收不能同时？？

注：RS485设备使用流程：

3. PIN引脚（配置模式与写电平高低（控制RS485读写（半双工）））

4. #define 串口名字 ： find-->control-->open-->loop -->close 。

一个测试模块（应用）的代码组成：

1. 线程：初始化/创建；启动；删除

2. 线程同步：初始化/创建；使用；删除

3. 设备：find，open，control ；

4. loop：

问题解决流程：

问题排查流程：

1. 按照报错，定位错误模块，进一步检查上述代码是否完整并正确的配置了参数等、、（此处有问题一把代码编译就会报错。）

2. 检查一些不同设备需要的额外的东西：例如RS485用引脚控制收发，所以需要配置引脚；CAN不需要；用RS232连接蓝牙，需要配置收发PIN；（总体而言就是配置该模块使用到的PIN引脚）

3. 确定代码框架完整后进一步检查loop，中断，业务线程间的代码逻辑问题；

4. 检查线程同步问题；检查数据收发的时间差问题，以及半双工通讯接口收发切换问题（RS485切换太快会丢一个数据）；

（通讯问题：确定硬件接口，接线，驱动没问题的情况下，应用逻辑层基本都是以上的4各方面的问题：1）引脚配置；2）参数配置（波特率，暂存块）；3）重开线程；4）时间问题（线程切换与等待））

解决问题方法论：

1. 定位问题：打断点（打印信息），不断精确错误环节。

2. 分析原因（大胆假设）：通过相关知识，没有就看文档；不断提炼出问题百度：从简单的现象总结，一直到原因归纳。不断百度学习。

3. 设计代码验证假设：一步一步解决问题、

4. 解决问题后记得复盘归纳出真正的原因、（这才是能力的提升，解决问题不是，总结才是。）