串口波特率(怎么测量实际的波特率、比特率?)

/ 0评 / 0

串口波特率(怎么测量实际的波特率、比特率?)

通常用串口打印乱码大多是因为串口波特率不对。那么我们应当如何测量实际的波特率呢?在此之前,让我们回想一下波特率的概念。

什么是波特率和比特率?

比特率的英文是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。

RS-232电平尺度常与TTL电平尺度相比拟。例如,

TTL电平尺度常用于普通电子电路中。在幻想状况下,5V表现二进制逻辑1,0V表现逻辑0。为了进步串口通讯的远距离传输和抗百思特网干扰才能,RS-232电平尺度用-15V表现逻辑1,+15V表现逻辑0。

在旧的台式盘算机中,通常有一个RS-232尺度的COM端口(也称 DB9 接口):

在这个示例程序中,我们将串口波特率设置为115200bps。在串口通讯中,符号只由一个二进制数表现(即只有0 和 1两种状况),因此波特率和比特率是相等的。

比特率代表每秒传输的二进制位数,所以我们知道传输一比特数据的时光,我们能推导出波特率吗?从逻辑剖析仪上我们可以知道,发送一位数据的时光如下:

发送一位数据的时光约为8.667us,因此可以盘算出一秒钟发送多少位数据:

盘算出的波特率为115380bps,非常接近115200bps。最后,确定是有必定的毛病。这个毛病的原因包含逻辑剖析仪的质量和我们的测量环境。但这个误差也在许可规模内。您可以看到串口助手吸收到的数据是否准确:

可以看到吸收到的数据是准确的,即波特率是准确的。

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

在实践中。我们可能会遇到这样情形,即代码中配置的波特率与串口助手上设置的波特率雷同,但仍然存在一个异常。

例如,如果我们向串口助手发送一个字符串,那么应当显示在串口助手上的字符串就被乱码了。或者我们发送一个数据到串口助手,发明数据被移动了。

在这种情形下,大多数波特率都不对应,因此我们必需检讨底层文件。如果代码中波特率盘算相干值(时钟)与实际情形不符,就会涌现这样的现象。例如,我的一位同事以前遇到过这种情形,这就是原因。

在应用STM32时,通常应用外部晶百思特网体振荡器,如STM32F103系列。外置晶体振荡器的输入规模为4~16mhz:

经验值一般为8MH(原创版权www.isoyu.com)z,而且一般的demo工程底层代码里默认的也是设置为8MHz,比如:

但是如果实际晶体振荡器没有粘贴8m,就会涌现问题(例如串口波特率不准确)。追溯到源代码,串口波特率被分配到USART_Init函数中的,打开这个函数:

盘算串口波特率须要一个apbclock变量,而这个值得起源从RCC_GetClocksFreq函数来,再打开这个函数:

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

遇到这种问题找谁说理去。经验就是不断采坑不断积聚的一个进程,早点遇到坑可能也是一件好事。像相似底层的问题很少遇到,但是一旦遇到那就得比拟辣手的问题了,须要很有耐烦地去查找。

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