STM32F103 跑起来很慢，求解……

只看该作者 · 2012-2-25 14:38

8M 晶振，串口数据传送接受都正常，但是跑程序速度明显很慢…… LCD 屏刷屏速度慢，命令执行的速度也慢。同样的程序烧到别的板子上就没问题，求点解……

只看该作者 · 2012-2-25 16:37

晶振是否配置对了？

只看该作者 · 2012-2-25 19:25

同样的程序，烧到另外一块同样的版上就没问题～

我觉得诡异的在于串口是对的，如果晶振有问题的话串口波特率应该也不准了才对……

1万 · 2012-2-27 10:18

可以按照这个思路查查：板子上有需要STM32访问处理的器件，但是因为这些器件造成STM32访问时需要等待较长时间，结果导致表面上看起来是STM32变慢了。

一辆F1赛车，在田间小路是跑不快的，不是因为车不行，是因为路不好。

只看该作者 · 2012-2-27 17:39

所用的只有串口，AD/DA，FSMC(没有接 BUSY ;P )。

刚低下头又看了看那块板…… 发现…… 晶振上…… 那个串联的电阻……没焊…… 汗……

不过奇怪的是串口的波特率是对的，难道在误差范围内？……

1万 · 2012-2-27 17:48

不管怎么说，如果串口的波特率是对的，表示系统时钟频率与预定的频率不会差太远，否则串口通信肯定有问题，除非你算错了，或你的另一个串口设备可以自适应波特率。

既然系统时钟频率与预定的频率不会差太远，而你有明显地感觉到系统变慢，除非你的感觉出了问题，肯定还是什么地方不对，但不会是系统时钟的问题；除了4楼说的外部器件的问题，你也可以查查，会不会有某个没有处理好的中断频繁出现，占用了大量时间。

只看该作者 · 2012-2-27 17:52

对啊～串口没问题，速度偏差应该在 5% 以内么～

啊！中断！像我这个经常虚焊的家伙…… 多谢香主，回头查查去！ ;)

只看该作者 · 2012-2-27 18:16

不管怎么说，如果串口的波特率是对的，表示系统时钟频率与预定的频率不会差太远，否则串口通信肯定有问题，除非你算错了，或你的另一个串口设备可以自适应波特率。

既然系统时钟频率与预定的频率不会差太远，而你有 ...
香水城发表于 2012-2-27 17:48

香主分析很到位，给力给力:)

只看该作者 · 2012-2-27 18:21

还是要试着自己先查找问题，一些比较明显的错误应该能发现

只看该作者 · 2012-3-1 17:04

又来自己结贴了～～

1，用库的话，USART 在一定程度上可以自动适应系统时钟的，它会获取当前系统的频率然后设置成你想要的波特率。具体的看代码，不解释。

2，这个问题最后却是的 HSE 启动时间过长的问题。在库里是:

  /* Wait till HSE is ready and if Time out is reached exit */
  do
  {
HSEStatus = RCC->CR & RCC_CR_HSERDY;
StartUpCounter++;
  } while((HSEStatus == 0) && (StartUpCounter != HSE_STARTUP_TIMEOUT));

把那个计数器去掉就好了……

实验室设备太差了，抓不到波形，估计是上电太慢造成的……

1万 · 2012-3-1 17:42

这个StartUpCounter是为了保证这个while不会死循环，你最好不要删掉它，如果HSE启动时间比较长，可以考虑把HSE_STARTUP_TIMEOUT改大一些。

如果去掉这个变量，一旦HSE出了故障，你的系统就彻底死掉了。

只看该作者 · 2012-3-1 17:47

如果芯片跑不到那个速度，很多东西就不对了，用它也就没有用了;)

1万 · 2012-3-1 18:01

如果芯片跑不到那个速度，很多东西就不对了，用它也就没有用了;)
grissiom 发表于 2012-3-1 17:47

从用户体验性出发，如果芯片跑不到那个速度，至少你要通知一下使用者吧，总不能悄悄地死去，让用户不知所终， :L

只看该作者 · 2012-3-1 18:14

STM8也有时钟切换，软件库离没有等待这一说法。
难道STM8不存在楼主遇到的问题？

回头测试一下，不要埋下什么炸*！

-447 · 2012-3-1 19:06

前几天我才发过一个帖子说系统变慢的事，我的问题是HSE启动过慢，原范例代码里面连等待都没有，我就是原地跳转，如果HSE没启动就死在那里。LZ这个是没焊好，问题一样。香主的思路是更合理的，如果时钟源故障但系统可以绕道，那么可以在硬件输出上面做个异常提醒。如果用户急用产品可以继续凑合用，不会耽误事情。但要告诉他这个问题，一有时间就必须去维修。