单片机串口通信的发送与接收(可编辑修改word版)

51 单片机的串口，是个全双工的串口，发送数据的同时，还可以接收数据。

当串行发送完毕后，将在标志位TI 置1，同样，当收到了数据后，也会在RI 置1。

无论RI 或TI 出现了1，只要串口中断处于开放状态，单片机都会进入串口中断处理程序。

在中断程序中，要区分出来究竟是发送引起的中断，还是接收引起的中断，然后分别进行处理。

看到过一些书籍和文章，在串口收、发数据的处理方法上，很多人都有不妥之处。

接收数据时，基本上都是使用“中断方式”，这是正确合理的。

即：每当收到一个新数据，就在中断函数中，把RI 清零，并用一个变量，通知主函数，收到了新数据。

发送数据时，很多的程序都是使用的“查询方式”，就是执行while(TI ==0); 这样的语句来等待发送完毕。

这时，处理不好的话，就可能带来问题。

看了一些网友编写的程序，发现有如下几条容易出错：１．有人在发送数据之前，先关闭了串口中断！等待发送完毕后，再打开串口中断。

这样，在发送数据的等待期间内，如果收到了数据，将不能进入中断函数，也就不会保存的这个新收到的数据。

这种处理方法，就会遗漏收到的数据。

２．有人在发送数据之前，并没有关闭串口中断，当TI = 1 时，是可以进入中断程序的。

但是，却在中断函数中，将TI 清零!这样，在主函数中的while(TI ==0);，将永远等不到发送结束的标志。

３．还有人在中断程序中，并没有区分中断的来源，反而让发送引起的中断，执行了接收中断的程序。

对此，做而论道发表自己常用的方法：接收数据时，使用“中断方式”，清除RI 后，用一个变量通知主函数，收到新数据。

发送数据时，也用“中断方式”，清除TI 后，用另一个变量通知主函数，数据发送完毕。

这样一来，收、发两者基本一致，编写程序也很规范、易懂。

更重要的是，主函数中，不用在那儿死等发送完毕，可以有更多的时间查看其它的标志。

实例：求一个PC 与单片机串口通信的程序，要求如下：1、如果在电脑上发送以$开始的字符串，则将整个字符串原样返回（字符串长度不是固定的）。

2、如果接收到1，则将P10 置高电平，接收到0，P10 置低电平。

（用来控制一个LED）单片机是STC89C52RC/晶振11.0592/波特率要求是9600 或4800。

谢谢！问题补充：可能会将【$ABCD,123456,987654ccc,aasdasd,aaaa,sssd,4D】这样的字符串（字符串长度约为50-150 个字符）传送给单片机，只能能原样返回。

[cpp] view plaincopy36. else { //如果送毕.37. TI = 0; //清除标志.38. Send_ed = 1;39. }40. }41. //----------------------------------------------/BLOG_ARTICLE_3007162.HTM串口接收程序是基于串口中断的，单片机的串口每次接收到一字节数据产生一次中断，然后再读取某个寄存器就可以得到串口接收的数据了。

然而在实际应用当中，基本上不会有单字节接收的情况。

一般都是基于一定串口通信协议的多字节通信。

在422 或者485 通信中，还可能是一个主机（一般是计算机）带多个从机（相应的有单片机的板卡）。

这就要求我们的单片机能够在连续接收到的串口数据序列中识别出符合自己板卡对应的通信协议，来进行控制操作，不符合则不进行任何操作。

简而言之就是，单片机要在一串数据中找到符合一定规律的几个字节的数据。

先来说下怎样定串口协议吧。

这个协议指的不是串口底层的协议，而是前面提到的数据帧协议。

一般都是有帧头（2~3 个字节吧），数据（长度根据需要），结束位（1 位，有时候设计成校验字节，最简单的校验也就是前面所有数据求和）。

比如0xaa 0x55 +（数据部分省略）+校验和（除了aa 55 之外数据的和），如果要是多板卡的话有时候还要在帧头后面加一个板选字节（相当于3 字节帧头了）。

第一次写串口接收程序的时候，我首先想到的就是定义一个全局变量（实际上最好是定义局部静态变量），初始值设置为0，然后每进一次中断+1，然后加到串口通信协议的长度的时候再清零。

然后判断帧头、校验。

写完了之后我自己都觉得不对，一旦数据错开了一位，后面就永远都接收不到数了。

无奈看了一下前辈们的代码，跟我的思路差不多，只不过那个计数值跟接收到的数据时同时判断的，而且每次中断都要判断，一旦不对计数的那个变量就清零。

废话少说，直接上一段代码让大家看看就明白了。

（通信协议姑且按照简单的aa 55 一个字节数据一个字节校验，代码是基于51 单片机的）。

接收成功则在中断程序中把串口接收成功标志位置1。

[cpp] view plaincopy1.然后串口中断部分2.void ser()interrupt 43. {4.static unsigned char count;//串口接收计数的变量5.RI=0;//手动清某个寄存器，大家都懂的6. receive[count]=SBUF;7. if(count==0&&receive[count]==0xaa)//同时判断count 跟收到的数据8. {9. count=1;10. }11. else if(count==1&&receive[count]==0x55)12. {13. count=2;14. }15. else if(count==2)16. {17. count++;18. }19. else if(count==3&&receive[count]== receive [2])//判断校验和，数据多的话是求//和，或者其他的校验方法，也可能是固定的帧尾20. {21. count=0;22. uart_flag =1;//串口接收成功标志，为1 时在主程序中回复，然后清零23. ES=0; //关中断，回复完了再ES=1;24. }25. else26. {27. count=0;//判断不满足条件就将计数值清零28. }29. }第一次做的串口大概就按照这个方法写完了（我后来看过其他的代码，有人用switch 语句写的，逻辑跟这个也差不多，不过我还是感觉用if else 来写清晰一些），不过在测试的时候发现了bug，如果数据帧发送一半，然后突然停止，再来重新发，就会丢失一帧的数据。

比如先接受到aa 55，然后断了，再进来aa 55 01 01，就不受控制了。

后来我也想到一个bug，如果在多设备通信中，属于其他设备的的帧数据最后一位是aa（或者最后两位为aa 55 ，或者最后3 位为aa 55 板选），下一次通信的数据就接收不到了。

当时对于数据突然中断的bug，没有想到很好的解决办法，不过这种情况几率极小，所以一直用这个方法写也没有问题。

多设备通信最后一位恰好是aa 的几率也很小，出问题的可能也很小。

当时项目里面的控制数据跟校验恰好不可能出现aa，于是我把if(count==0&&receive[count]==0xaa)改成了if(receive[count]==0xaa)其他都没变，解决了，没有bug 了。

后来我又写了几次单片机程序，才想到了一些解决问题的方法——不过改天再接着写吧，太累了，明天还要上班呢。

在后来的项目中，真的遇到了数据位跟校验位都可能出现aa 的情况。

我考虑到每次数据都是连续发送的（至少我们用labwindows 做的上位机程序是这样的），成功接收到了一帧数据是要有一定时间回复的，也就是说如果接收到一半，但是很长时间没接收到数据，把计数值count 清零就ok 啦。

涉及时间的问题自然要用定时器来实现啦。

这次的通信协议如下，串口波特率19200,2 个帧头aa 55 ，一个板选，6 字节数据，一个校验字节（除帧头外其他数据的和）。

[cpp] view plaincopy32. if(g_DatRev[count]==0xaa&&count==0) //帧头33. {34. count=1;35. }36. else if(count==1&&g_DatRev[count]==0x55)37. {38. count=2;39. }40.41. else if (count==2&&g_DatRev[2] == boardAddr)42. {43. CK = g_DatRev[count];44. count=3;45.46. }47.48. else if(count>=3&&count<9)49. {50.51. CK += g_DatRev[count];52. count ++;53. }54.55. else if(count == 9&&CK==g_DatRev[9])56. {57. ES = 0;58. retFlag = 1;59. count=0;60. }61. else62. {63. count=0;64. }65. resettimer();66.67. }68.69. //判断count 不为0 的话就启动定时器70. void resettimer()71. {72. TR0=0;73. TH0=(65536-2000)/256;74. TL0=(65536-2000)%256;这种方法的确是本人自己想出来的，别人可能也这样做过，但我这个绝对不是抄袭或者模仿来的。

这样写的确可以避免前面提到过的bug，不过代价是多用了一个定时器的资源，而且中断函数里的内容更多了，占用了更多的时间。

要是能把第一种方法改进一下就好了，主要是那个校验不能为aa 的那个bug，因为毕竟传输到一半突然断了的可能性是非常小的。

后来我想第一个判断if(count==0&&receive[count]==0xaa)好像有点太严格了，考虑到第二字节的帧头，跟板选地址不可能为aa，于是把这个改写为if(count>=0&&count<=2&& receive[count]==0xaa), 这样就把bug 出现的几率降到了非常小，也只是在前一帧结尾数据恰好为aa 55 板选的时候才出现，几率是多少大家自己算一下吧，呵呵。

这样我自己觉得，昨天写的那种方法改进到这个程度，应该算可以啦，反正我是很满意了。

实际上我还想过其他的方法，比如缓存的数组采用移位寄存的方式。

拿前面的 4 个字节的协议为例。

[cpp] view plaincopy这段代码看上去可是简单明了，这样判断可是不错啊，同时判断帧头跟校验不会产生前面提到的bug。