51内核软件延时和串口的巧妙方法介绍

不知道大家学习51是怎么过来的，反正我是一路忽悠过来的。现在用51来开发产品必须要充分用到它的内部资源，本来主频、资源就比不上32，不充分的利用怎么才能开发好的产品，那么今天我又学习到两个小技能：延时和串口的发送中断

情况是这样的，在产品的开发中，遇到了74HC595控制数码管，这个数字逻辑芯片用过的都知道，一位数码管还好，要是有多位那就得不断的刷新，为快不破，进而达到不同位显示不同断码(数字)的效果。这个刷新频率还有讲究，我不知道我的理论对不对，反正我知道民用电50Hz接在灯泡上，人眼是看不出灯泡在不断的闪烁的。那么就根据这个原理我只要保证在50Hz以上的频率(20ms以内)及时的刷新一次显示就行了。不过实际效果是我延时个5ms刷新一次才差不多看不到频闪，延时是软件的for循环延时，不太准，但是也差不多把。我也不明白为什么要到5ms才能把频闪给消除掉。反正就按照实际效果来咯。问题来了，5ms的周期性刷新，难道MCU就单纯的给这个数码管刷新不干别的活了，这往往是不太可能的。那在调试的过程中我实现的方法是这样的：

程序没有操作系统，就是普通的while循环，一个循环里面有很多任务，跑一趟下来时间可能比较长，那我就多copy几个刷新函数呗，根据任务大概的耗时放置在不同的位置。这样下来结果还是比较明显的，最起码效果好很多。接着就是新问题了，当一个任务函数执行的时间比较长的情况下，还是会出现频闪，有朋友可能会想到，那就在任务函数里面放刷新显示函数呗，的确这是一个好方法。在程序中我也用到了。可是有些任务函数对时间要求比较严格，还就真的不能放在里面干扰它的底层驱动程序。重点来了，我就来记录下我使用的两个方法;

1、 巧妙的使用任务函数本身的延时函数

例如我在工程里面用到了DHT11温湿度传感器，这个传感器(包括DS18B20)是单总线协议，对时间要求相当严格，我就看着底层驱动去找，找到了一个时间相对来说比较长的地方：

上图是DHT11的时序图，红线标注的地方是MCU给传感器的其实信号，这里手册上说的是至少拉低18ms，那就在这个地方做文章，以下是我修改的代码：

只是让这个20ms的时间去干点别的事情，就是刷新数码管。当然了，如果有操作系统的话，操作系统延时的调用机制会把效率进一步提高。在这里只要保证红色方框内的执行时间和需要延时的时间差不多，保证能正常读取到传感器数据就行了，我也就估算出来的没有实际测试时间，毕竟不方便仿真，不在公司手边也没有示波器。

2、串口发送中断的使用

除了这里的延时时间修改之外还有一个地方比较棘手，那就是串口发送一帧数据，一帧数据比较长，用一个个字节等待发送完成的方式太费时间了，其中又不好加上刷新函数，怎么办，突然想到了之前用过32的串口发送中断。于是就查了下寄存器试用了下，还真可以。表示之前几乎没有用过串口的发送中断，最多用过接收中断。修改前和修改后的代码如下：

注释的就是一个个字节数序发送了，发送一个字节的函数原型如下：

修改后的串口中断函数：

从代码的结构来看，大致的原理就是在没有数据需要发送的时候串口中断处于关闭状态，当有数据需要发送的时候，先把数据先准备好存储在一个数组里面，然后调用发送函数。发送函数的内容先是把串口的中断打开(ES=1)，清零发送完成标志位(TI = 0),把需要发送的第一个数据放进以为寄存器(SBUF = dat[0])，把模拟的发送数据地址指向发送的第二个字节(因为第一个已经发送了)，然后就等着中断吧。每发送完成一个字节串口就会进入中断函数，在中断函数里面先判断是不是发送中断(51内核串口的发送中断和接收中断使用的是同一个中断向量)，确保是发送中断后先清除中断标志，然后继续放入需要发送的下一个数据(SBUF = WIFI_TX_DATA[TX_CNT++];)同时需要发送的数据地址后移。判断需要发送的数据是不是全部发送完成了，发送完了那就关闭串口中断。这样一帧数据就完美的发送完成而且效率有所提升!

上述方法只是一个简单的处理，侦长度是定长14个字节，如果是不定长度的侦也是可以根据实际情况修改的。还有一个问题我在这里没有处理但是需要注意，那就是有一种情况需要考虑到，当一帧数据还没有发送完成，新的一帧数据又需要发送。那么这种情况就需要修改下存储的方法了。这里记上一笔，解决方式是把需要发送的数据存进一个相对大一点的数组里面，然后给这个数组分配两个指针，分别是头指针(p)和尾指针(q)，每次发送的时候先判断是不是(p=q)如果是的话就证明之前的数据都发送完了，现在可以畅通无阻;如果不相等，那就继续存储并同时后移尾指针q的位置(如果溢出了那就重新回头呗—循环数组的方法)。