4 年前写过一篇关于 GPIO 模拟串口的文章：GPIO 模拟串口
4 年来陆陆续续有人联系我要示例代码，可见 GPIO 模拟串口是一个实际需求。最近我也又碰到了该需求，因为客户用的 MCU 本身只有 2 个串口，而实际需要 3 个串口，所以需要额外模拟一个出来。
于是把之前的代码又重新移植并测试了下，之前代码发送的时候波特率可以达到 115200bps，但是接收却不行。当时没有细致分析过原因，这次认真的分析了一下。
这次使用的 MCU 主频运行在 48Mhz，模拟串口发送的逻辑和实现比较简单，按照 1/波特率周期，在定时器中断服务函数里去发送串口对应的 bit 位即可。实测波特率可以支持到 256000bps。
接收的逻辑是：当 RX 引脚检测到下降沿时，进入 GPIO 中断，然后开启一个定时器，第一次定时器周期设置为 1/波特率的一半(目的是为了在中心处判断是否为低电平，以表示是否为起始位)，再之后就可以设置定时器周期为 1/波特率，每隔此周期在定时器中断服务函数里去采样 RX 引脚电平，将数据接收完毕。
为什么接收时，波特率高了之后就数据异常呢? 未修改代码之前，我测试波特率最高只能支持到 19200bps，
我们在接收定时器中断服务函数里加入点代码，在串口每一个 bit 位处理前后进行一次 GPIO 翻转。通过波形来分析接收的处理时序：
加入上述代码后，接收波特率最高只能支持到 14400bps 了，以下是波形图，其中 Channel 0 是翻转 IO 的波形，Channel 1 是串口接收引脚波形
从上图中我们首先看到第一个 IO 翻转时间为 14us，明显高于后续其他翻转时间。这个原因经分析是代码里用了一个除法运算导致的。
我们优化一下代码，不用每次都在这里做一次除法。改完之后时间从原来的 14us 缩短为 2us。除法导致运行时间长具体可以查看之前的文章：在 KEIL 中勾选微库后，延时函数为什么不准了？
另外发现 RX 下降沿到 IO 口开始反转的时间是 50.8us，理论值应该是 35us 才对。
为什么延迟了这么多呢？问题出在这里，这里也用了除法，同样的我们也做一下修改
改完之后，这个时间就到了 39us，偏差就小了很多。
可以进一步优化，在进入下降沿中断里一开始就先配置并启动定时器
这样对应的时间还可以更准确一点。
经过以上修改后，19200bps 接收正常，但是 38400bps 波特率还是异常，我们看一下波形：
问题出在第一个起始位采样点有 3us 偏移，导致后续的采样点相比自身的中心点偏的越来越大，以至于第 2 字节数据的起始位没有来得及处理，进而导致后续的数据处理错误。
我们将采样首次的采样时间做进一步优化，让其更靠近中心点，
这样修改后波特率可以达到 56000bps，但是再增加到 57600bbps 后还是有问题。其实原因也很简单。还是因为首次 1/2 周期采集依然有偏差，随着后续不断按照 1/波特率周期去采集，误差越来越大。
我们进一步做优化，将后续按照固定周期去采集的方式改为动态调整周期值，最简单的方式是周期大小做交替变化，这样到最后一个字节就不会偏差那么大。
改完之后可以支持到 57600bps，但是 115200bps 还是不行。
通过观测波形可以看到，第一个 IO 翻转下降沿到第二个 IO 翻转下降沿的时间间隔出现了错误，理论应该是 9us，但实际只有 5us。
经分析原因是随着波特率的提高，定时器的周期越来越短，当波特率为 115200bps 时，1/波特率的一半 周期只有约 4us，而起始位的代码执行时间已经接近 4us，所以定时器周期还没有更新生效的时候，原来的一半周期中断又来了。代码优化如下，首先更改周期。
这样就可以达到 115200bps 的波特率：
以上记录本次调试过程中遇到的问题及解决办法。总结一下：要想 GPIO 模拟串口能够提高波特率，需要通过精确的定时器配置、精简的中断服务程序、动态误差补偿等措施来实现。
END
作者：TopSemic
来源：TopSemic嵌入式
推荐阅读
欢迎大家点赞留言，更多 Arm 技术文章动态请关注极术社区嵌入式客栈专栏欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。
