STM32 | 通俗易懂地串口通讯解析

平时使用串口打印出现乱码的绝大部分原因是串口波特率没对。那么我们怎么测量实际的波特率呢？在这之前，顺便一起回顾一下波特率的概念。

什么是波特率、比特率？

• 比特率(Bitrate)表示每秒钟传输的二进制位数，单位为比特每秒(bit/s)。

• 波特率(Baudrate)表示每秒钟传送的码元符号的个数，是衡量数据传送速率的指标。

• 码元是通讯信号调制的概念，通讯中常用时间间隔相同的符号来表示一个二进制数字，这样的信号称为码元。

常见的通讯传输中，用 0V 表示数字 0， 5V 表示数字 1，那么一个码元可以表示两种状态 0 和 1，所以一个码元等于一个二进制比特位，此时波特率的大小与比特率一致。

如果在通讯传输中，有 0V、2V、 4V 以及 6V 分别表示二进制数 00、 01、 10、 11，那么每个码元可以表示四种状态，即两个二进制比特位，所以码元数是二进制比特位数的一半，这个时候的波特率为比特率的一半。

因为很多常见的通讯（比如串口通讯）中一个码元都是表示两种状态，所以大家常常直接以波特率来表示比特率 。

串口通讯协议

在串口通讯的协议层中，规定了数据包的内容，它由启始位、主体数据、校验位以及停止位组成，通讯双方的数据包格式要约定一致才能正常收发数据，其数据帧组成如下：

下面我们来实际验证一下其数据帧是不是真的是这样的。编写如下代码：

代码很简单，就是使用串口不断地往外发数据0xAA（当然发送其它数据也是可以的）  。我们的串口配置如下：

我们可以使用示波器或者逻辑分析仪抓取实际信号看看数据是不是符合上面的帧格式。这里，我们使用逻辑分析仪抓取USART1的发送信号线（TX）：

从实际结果中我们可以看到的确是按帧格式来发的。这里可能会有人有疑问，上面那个数据帧的图片中有个空闲状态，这个又是什么呢？空闲、空闲，当然是没有在发数据时候的状态呀，我们把我们的代码改为：

在初始化完成之后只发送一次0xAA，逻辑分析仪抓到的数据为：

可见，空闲状态是个高电平。在上一个的范例中，我们一直在while循环中发送数据0xAA，所以就没有空闲状态。

在这个实验中我们需要知道的是两个点是：

• 串口发送数据是低位先发的。我们单片机发0xAA（10101010B），所以逻辑分析仪抓到的有效数据是01010101B。

• 单片机的串口使用的是TTL电平，为正逻辑电平信号。逻辑分析仪抓到的数据0对应着实际电压0~0.5V，数据1对应着实际电压2.4V-5V，

经常与TTL电平标准做对比的是RS-232电平标准，如：

常见的电子电路中常使用 TTL 的电平标准，理想状态下，使用 5V 表示二进制逻辑 1，使用 0V 表示逻辑 0；而为了增加串口通讯的远距离传输及抗干扰能力，RS-232电平标准使用-15V 表示逻辑 1， +15V 表示逻辑 0。

在旧式的台式计算机中一般会有 RS-232 标准的 COM 口(也称 DB9 接口)  ：

在这个示例程序中，我们设置的串口波特率为115200bps。在串口通讯中，码元只用1个二进制数来表示（即只有0 和 1两种状态），所以波特率与比特率在数值上是相等的。

而比特率表示的是每秒钟传输的二进制位数，那我们知道传一位数据的时间岂不是就可以反推出波特率是多少了吗？从逻辑分析仪中，我们可以知道发送一位数据的时间如下：

发送一位数据的时间大约为8.667us，所以1秒钟发送多少位数据是可以算出来的：

算出来的波特率为115380bps，与115200bps很相近。最终肯定是有一定的误差，这个误差产生的原因包括逻辑分析仪的质量及我们的测量环境等等因素。但是这个误差也是在允许的范围内的，可以看看串口助手接收到的数据是不是正确的：

可见，数据接收正确，也就是波特率对的上了。

串口波特率对不上怎么解决？

在实际中。我们可能会遇到这样的情况，代码里配置的波特率与串口助手上设置的波特率一样了，但还是出现异常情况。

异常情况如我们往串口助手发送字符串，串口助手上本该显示的字符串出现了乱码。或者我们往串口助手发送一个数据，发现数据移位了。

出这种情况大多是波特率对应不上，我们就得自己检查我们的底层文件了，代码中的某个与波特率计算相关的值（时钟）与实际不匹配了，就会出现这样的现象，比如之前我的一位同事就遇到这样的情况就是这个原因导致的。

我们用STM32的时候，一般都是使用外部晶振，比如STM32F103系列，可输入的外部晶振的范围是4~16MHz：

经验值往往是8MHz，而且一般的demo工程底层代码里默认的也是设置为8MHz，比如：

但是，如果实际晶振贴的不是8M的话，就出问题了（比如串口波特率就不正确了）。追根溯源，串口波特率是配进USART_Init函数中的，打开这个函数：

计算串口波特率需要一个apbclock变量，而这个值得来源从RCC_GetClocksFreq函数来，再打开这个函数：

所以要注意的是，HSE_VALUE这个值要与实际做对应。

遇到这种问题找谁说理去。。经验就是不断采坑不断积累的一个过程，早点遇到坑可能也是一件好事。像类似底层的问题很少遇到，但是一旦遇到那就得比较棘手的问题了，需要很有耐心地去查找。

能用稳定的芯片是一件很幸福的事情，用不稳定、不成熟的芯片的时候，那个才是真的难啊，遇到问题真是让人怀疑人生啊，软件、硬件、芯片都可能有问题。。。