电子工程师技术服务社区
- 社区
- 论坛
- 单片机专区
- 搞定RS232串口通信全过程
搞定RS232串口通信全过程
-
-
学海无涯来追求
- LV3工程师
-
| 2015-11-30 14:40:44
- 浏览量 664
- 回复：2
搞定RS232串口通信全过程
出现的问题及解决过程：
1、通过串口调试助手发送过去然后回显的全是乱码
分析可能出错的地方：1、代码2、串口线3、串口调试助手
PS：很多时候我们都是直接找代码的原因，而并没有针对2或者3进行排查。当然这次出错也并不是出现在它们上面，但仍然有必要首先对这两项进行排查。正像很多时候电路有问题，我们就开始检查焊接走线，假如纠结了很久最后却发现有块芯片是坏的那种感觉我想是谁都不愿的。分析问题要有理有据，不能想当然觉得怎么样，什么都可能出问题，什么都要怀疑一下。
串口线怎么检测呢？找了个51系列的MCU，烧了个最简单的点灯代码，结果正常说明串口线可以用。然后就是串口调试助手。既然把51搬出来了，就顺便找个了它的串口通信代码，测试串口调试助手，也能正常。
接下来就可以安心地找代码的问题了。一直在想哪里最可能出问题呢？这段代码是别人编好并测试过的，我只是移植过来而已。就纠结了，不管那么多，再烧一遍看看情况，果真还是乱，纠结…不知怎么灵光一闪：波特率不协调，于是从150、300、600、1200、4800、……、115200试了个遍，竟然都不行，继续纠结……回到代码波特率设置相关部分，突然看到一个clk_50m，我的系统时钟是25M!!!!! 果断发现问题：波特率计数是按照50M的时钟，但实际时钟是25M，即意味着事先设置的9600bps就不是9600bps而是4800bps！好的回到串口调试助手，直奔主题波特率设置4800bps，发送一个数，果真收到了，但刚刚测的时候为什么是乱的呢? 然后同时输了多了数，点击发送，发现又乱了。只输一个数，点击发送，正常，再次重复，依然正常，多次重复，还是正常。好吧，再同时输多个数，还是不正常。这就有了第二个问题。
2、连续发送多个数据时显示乱码
在这个问题上纠结了很久，也正是由于一直解决不了才导致了当初准备放弃的想法。回头想想为什么很久迟迟解决不了，虽然当经验不足时问题的解决很多时候需要的是灵感，自己解决问题的方法不正确也是一个很重要的原因。没有认真去分析原因，有针对性采取措施，凭感觉乱试只是反复烧代码，你什么都没做怎么可能这次现象不对，下次就对了？
最后发现问题的原因在于：时序上不满足。连续发送时上一次接收没进行完，下一次的数据就发送过来了导致包丢失了一部分。其实两个问题说到底还是一个问题，串口通信出问题很多时候就是这个问题：发送方与接收方时序不匹配。要不然是代码中本身时序就有问题，要不然就是通信时具体设置不匹配。
找到问题的过程确实有一定偶然性，是用Modesim对模块单独仿真时偶然闪现的灵感。但其中也有教训要牢记。
经验总结：
1、做设计需要一个开发流程
虽然不是说就一定按部就班去完全走下来但最起码的流程还是要走的。再怎么说这些流程都是根据一线设计人员总结出来的，毫无疑问在很大程度上会减少错误的出现或者能更快定位错误根源，帮助缩短开发周期。当时就是因为不是自己设计的代码就忽视了设计流程，拿到代码没经simulation和verification就直接跳到最后阶段了，企图在那里采用一定措施找到原因，不但未能定位错误，还让自己思路越来越混乱了。
2、问题出现时重点还是分析现象，定位问题
这次浪费时间最多在了重复的编译上和烧代码上，总是期望自己凭感觉改这一下再试一次好像结果就会对似的。不去分析原因，有针对性采取措施，凭感觉乱试是不利于快速发现问题。观察现象是为了发现其*性，帮助定位问题。没分析出问题，没采取解决方案之前，就凭感觉改了点东西，再观察对的可能性也不大。
搞定RS232串口通信全过程
出现的问题及解决过程：
1、通过串口调试助手发送过去然后回显的全是乱码
分析可能出错的地方：1、代码2、串口线3、串口调试助手
PS：很多时候我们都是直接找代码的原因，而并没有针对2或者3进行排查。当然这次出错也并不是出现在它们上面，但仍然有必要首先对这两项进行排查。正像很多时候电路有问题，我们就开始检查焊接走线，假如纠结了很久最后却发现有块芯片是坏的那种感觉我想是谁都不愿的。分析问题要有理有据，不能想当然觉得怎么样，什么都可能出问题，什么都要怀疑一下。
串口线怎么检测呢？找了个51系列的MCU，烧了个最简单的点灯代码，结果正常说明串口线可以用。然后就是串口调试助手。既然把51搬出来了，就顺便找个了它的串口通信代码，测试串口调试助手，也能正常。
接下来就可以安心地找代码的问题了。一直在想哪里最可能出问题呢？这段代码是别人编好并测试过的，我只是移植过来而已。就纠结了，不管那么多，再烧一遍看看情况，果真还是乱，纠结…不知怎么灵光一闪：波特率不协调，于是从150、300、600、1200、4800、……、115200试了个遍，竟然都不行，继续纠结……回到代码波特率设置相关部分，突然看到一个clk_50m，我的系统时钟是25M!!!!! 果断发现问题：波特率计数是按照50M的时钟，但实际时钟是25M，即意味着事先设置的9600bps就不是9600bps而是4800bps！好的回到串口调试助手，直奔主题波特率设置4800bps，发送一个数，果真收到了，但刚刚测的时候为什么是乱的呢? 然后同时输了多了数，点击发送，发现又乱了。只输一个数，点击发送，正常，再次重复，依然正常，多次重复，还是正常。好吧，再同时输多个数，还是不正常。这就有了第二个问题。
2、连续发送多个数据时显示乱码
在这个问题上纠结了很久，也正是由于一直解决不了才导致了当初准备放弃的想法。回头想想为什么很久迟迟解决不了，虽然当经验不足时问题的解决很多时候需要的是灵感，自己解决问题的方法不正确也是一个很重要的原因。没有认真去分析原因，有针对性采取措施，凭感觉乱试只是反复烧代码，你什么都没做怎么可能这次现象不对，下次就对了？
最后发现问题的原因在于：时序上不满足。连续发送时上一次接收没进行完，下一次的数据就发送过来了导致包丢失了一部分。其实两个问题说到底还是一个问题，串口通信出问题很多时候就是这个问题：发送方与接收方时序不匹配。要不然是代码中本身时序就有问题，要不然就是通信时具体设置不匹配。
找到问题的过程确实有一定偶然性，是用Modesim对模块单独仿真时偶然闪现的灵感。但其中也有教训要牢记。
经验总结：
1、做设计需要一个开发流程
虽然不是说就一定按部就班去完全走下来但最起码的流程还是要走的。再怎么说这些流程都是根据一线设计人员总结出来的，毫无疑问在很大程度上会减少错误的出现或者能更快定位错误根源，帮助缩短开发周期。当时就是因为不是自己设计的代码就忽视了设计流程，拿到代码没经simulation和verification就直接跳到最后阶段了，企图在那里采用一定措施找到原因，不但未能定位错误，还让自己思路越来越混乱了。
2、问题出现时重点还是分析现象，定位问题
这次浪费时间最多在了重复的编译上和烧代码上，总是期望自己凭感觉改这一下再试一次好像结果就会对似的。不去分析原因，有针对性采取措施，凭感觉乱试是不利于快速发现问题。观察现象是为了发现其*性，帮助定位问题。没分析出问题，没采取解决方案之前，就凭感觉改了点东西，再观察对的可能性也不大。
1192137406
2015-12-02
US
2015-11-30
