使用开发板的USART作为UART通信,在前调用BSP_Init()函数初始化开发板,串口上传输的数据出错:'a'变成0xfa或0xfe;
【在这个问题解决之后,回头总结下,在解决问题时:
1.预计有可能造成出错的原因(这个可能需要一些经验,但是思维方式需要这样的猜测,从系统内外,可以先罗列出尽可能有的原因,后面再一一排除)
2.尽可能的定位出错的地方(比如这里通过在线调试,确定在修改时钟后,可以解决数据发送的不正确)
3.推测并排除次因,找出主因,往深一步探测 】
1:猜测原因。
外因:串口接收的过程受干扰
内因:A.端口设置有问题 B.USART的波特率设置有问题
2:定位错误
在刚开始时通过屏蔽BSP_Init()发现功能正常,再具体定位到BSP_Init()里面的SYSCLK_Frequency时钟设置,发现例程中默认的是72M,但是改为36M,就没有问题,应该是时钟方面的设置问题,具体的问题做何解析?
3:推测排除,深究
外因内因很好排除,数据既然在波特率低时能正常通信,可能不是端口设置的问题,应该是波特率的问题,常看用户手册该节的资料:
注:
1.CPU 的时钟频率越低,则某一特定波特率的误差也越低。可以达到的波特率上限可以由这组数据得到。
2.只有USART1 使用PCLK2(最高72MHz)。其它USART使用PCLK1(最高36MHz)。
USART的波特率的计算公式:
USARTDIV是一个无符号的定点数。这12位的值设置在USART_BRR寄存器。那么USARTDIV与USART_BRR的关系又是怎么样的?
加入USARTDIV=27.75;那么USART_BRR=0x1B(27)+0XC(0.75*16)=0X1BC;同理可以从USART_BRR推出USARTDIV的值;
假设fck=36000000;Tx=115200;=>USARTDIV=19.53125;所以0x13+(0.53125*16=8.5)=>0x13+0x9=0x139;所以实际上是0x139产生的波特率:115015.97(误差率为0.15%);
===》理论最大波特率:36000000/(16*1.0)=2.25M(USARTDIV最小为1.0)
继续往下查,对于SYSCLK_Frequency最高72M,运行应该没有问题,但是目前有问题;顺藤摸瓜,查看各个时钟控制器,发现时钟设置路径:HSE-->PREDIV2-->PLL2-->PREDIV1-->PLL-->SYSCLK;
发现其中有问题:HSE(25M),PREDIV2(源代码设置是2分频),PLL2(8倍频),PREDIV1(9倍频),SYSCLK是算不出72M的,这时72M的算法其实已经超过72M,所以给USART2时,波特率计算时会出现问题;将PREDIV2(改为5分频就对了);
这就是为什么调用BSP_Init()或者SystemInit会出问题,他们都调用SetSysClock(),再调用SetSysClockTo72()【宏定义72M】,同时将系统时钟改为36M时不会出问题,因为此时调用的不是出问题的SetSysClockTo72(),而在之前用的是出错的SetSysClockTo72()却没有发现问题,是因为系统时钟虽没有在预设值,但是系统还足以正常工作,但是一旦添加串口,波特率设置就会有很大的偏差,数据传输就出错。
1:参考代码其实里面是有很多问题的
2:我们应该尽可能的多阅读参考代码,利用其中的资源,避免重复造轮子。
2:用串口终端软件显示字符串,连续发送几个字符串时,“xxxx/n”,包含了换行转义字符,但是就是不会换行?
通过调试,发现在存储空间,转义字符‘/n’是正确的0x0a,
USART_SendString(USART2,Menu[0]);
USART_SendString(USART2,Menu[1]);
USART_SendString(USART2,Menu[2]);
USART_SendString(USART2,Menu[3]);
但是不连续发送就不会出现这种现象,或者一句句调试打印也不会出现不换行的现象,断定是连续发送的时间间隔太短,软件还没来得及换行,就又重新显示新数据,那么就在USART_SendString的尾部加了延时,就解决问题了。
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉
全部0条评论
快来发表一下你的评论吧 !