jfuwre 发表于 2019-1-4 12:19
如果是软延时呢，那就是很正常不过的了，因为有时候编译器会采用不同的优化策略，即使是非常小的改动，甚至无关的改动！！！硬延时的话，那就要看看数值是否正确了！！！如果是软延时，个人建议可以加大一下数值，或者直接用宏nop，如果要求非常高的化！！！！ ...

本帖最后由 野马-425178 于 2017-5-12 12:51 编辑

做了些实验，发现情况是这样的：
USB_OTG_BSP_uDelay函数在优化后如果有调用LDR汇编指令的时候即满足设计微秒级延时要求，但如果优化后没有调用LDR指令则延时时间被缩短且不符合要求了；
ST库提供的原始代码在优化时刚好有调用LDR指令（因为该变量定义的顺序刚好使MDK优化时认为无法保存寄存器变量，需要每次LDR重载），所以就没有问题；
而我把变量定义顺序修改后，经过MDK优化则把LDR指令去掉了，但是MDK也没有错，因为uTime是const变量，如果优化策略认为不需要每次重载的时候就不需要LDR了，结果导致时间不准确。
实际上，最安全的做法应该是要使用“__IO”来修饰变量“uTime”，而不是用“const”。

版主的回复也是对的，因为这个函数设计的时候就是用const修饰了uTime变量（不一定每次都重新加载），所以LDR被优化掉也算是正常，而我正好又是需要这个指令的运行时间。

在阿莫上刚好有个帖子，关于MDK优化省略了LDR操作的问题，里面描述了和我这个问题很类似。
https://www.amobbs.com/thread-4214047-1-1.html

该网址下以下内容和我的问题类似：
1、你好，我发现如果那个while(unIdleCount!=200);   不是一个空等待的循环，（当然，里面不是的环就不是等待2Ms了，而是在这2MS里一直执行某个操作了），这样的话就不会出现这种情况了，在比较之前
   会有一个LDR的操作，保证读取的是RAM里的数据，而这时我并没有用volatile修饰他，而且我的优化等级选的是最高的3也没关系

2、另一个，我发现，只要unIdleCount=0不是紧挨着下面那个判断语句，两句之间隔了一些函数，就算这些函数没有操作unIdleCount，在比较之前也会有那个LDR命令获得unIdleCount最新的值

   22:         TIM3_Int_Init(500,7199);//10Khz的计数频率，计数到5000为500ms   
     23:           
0x08000A08 8820      LDRH     r0,[r4,#0x00]   //这条语句是在下面那个判断之前突然出现的，用来获得最新的值  
     24:         while(unIdleCount!=10);
     25:                  
0x08000A0A 280A      CMP      r0,#0x0A
0x08000A0C D1FD      BNE      0x08000A0A

同样，这时我也没有用volatile修饰unIdleCount，那应该就是这时寄存器里面没有保存unIdleCount了，（因为这之前的操作保存不了了），所以会重新读，

3、后来我又脑残的做了几个实验，发现在unIdleCount=0；和while(unIdleCount!=10);之间相隔的有东西的时候，不管是函数（需要跳转）还是简单运算，只要编译器有办法用一个寄存器保存unIdleCount 的值
   同时又能完成这之间的运算，他就会直接比较寄存器里面的值，（此时我任然选的是最高优化级别）我的是4.7版本的MDK。
   于是我又重复了1里面说的，发现只要while里面有东西，哪怕简单得足以让可以保存unIdleCount的值，但是他也会每次都读取最新的值，
   于是我真的有点感慨，真的很智能，（他的理念或许就是这样），完全没意义的事就不用每次都浪费时间和代码空间读取最新的值了，但是
    真的有事要做的话就得严谨地每次读取最新的值看是不是满足条件，应不应该执行了，哈哈，说的优点多