RT-Thread一般讨论

请教一个关于rt_tick_get()的问题

发布于 2012-01-06 10:42:56 浏览：7237 订阅该版

9 个回答

zyb 2012-01-06

This guy hasn't written anything yet

bernard 2012-01-06

This guy hasn't written anything yet

zyb 2012-01-06

This guy hasn't written anything yet

bernard 2012-01-06

This guy hasn't written anything yet

zyb 2012-01-06

This guy hasn't written anything yet

fubaojun2006 2021-01-29

哇(挖)~~坑~~~啊！

哇，好详细，新的知识点又学到了。
如你所说，8位MCU对于 16bits 32bits的数据，确实是这样分指令处理的。
那么大概率出问题的地方应该是在 自加之后回写的过程中读取的时候会出现错误。
```
+1
写回低8位
写回中间8位
写回中间8位
写回高8位
```
我想在这里举一个具体的数据可能会更好理解一点。
先假设 rt_tick = 0x1234 56FE
那么自加之后回写过程中的数据是：
```
+1            //rt_tick = 0x1234 56F**_F_**
写回低8位      //[0] = 0xF**_F_**
<-------------在此处读取_rt_tick  = 0x1234 56FF_ 符合预期 ,不影响最终读取结果
写回中间8位    //[1] = 0x56
写回中间8位    //[2] = 0x34
写回高8位      //[3] = 0x12
```
那么 下一个 tick 再次读取的情况呢？
经过上次的自加过程，此时 rt_tick = 0x1234 56FF 
```
+1            //rt_tick = 0x1234 **_57_** **_00_**
写回低8位      //[0] = 0x**_00_**
<-------------在此处读取_rt_tick  = 0x1234 56**_00_**_ 可见最后一个字节由于进位已经全部清零 ,最终读取结果与预期差异较大。
写回中间8位    //[1] = 0x**_57_**
写回中间8位    //[2] = 0x34
写回高8位      //[3] = 0x12
```
再举例一个极端的例子，假设 rt_tick = 0x1234 FFFF
那么自加之后回写过程中读取数据：
```
+1            //rt_tick = 0x12**_35_** **_0000_**
写回低8位      //[0] = 0x**_00_**
<-------------本次不在这里进行读取分析了
写回中间8位    //[1] = 0x**_00_**
<-------------在此处读取_rt_tick  = 0x1234 0000_ 可见最后两个字节由于进位已经全部清零 ,最终读取结果与预期差异较大。
写回中间8位    //[2] = 0x**_35_**
写回高8位      //[3] = 0x12
```
~~~~~~~~~~
总结一下，理论上，
在8位单片机当中，确实会出现读取rt_tick 与 预期 差异较大的小概率情况。
~~~~~~~~~~
实践当中，
1、首先这种冲突在一起的情况，概率太渺茫了。需要条件非常苛刻，在滴答中断执行过程中，有一个高优先级的中断发生，打断滴答中断回写过程，执行rt_tick_get。且需要有进位发生。
2、对于8位单片机的资源来说，上RTT ，基本上也是学习使用。并没有非常实用的场景需求。
3、我搜索到这个帖子的原因，是为了在LOG打印中，区分线程的执行先后顺序，既不在高优先级中断中执行rt_tick_get，程序的执行又不严格依赖读取到值进行特殊处理。所以，对于这种应用场景，值错了也无所谓。

那么再来分析一下ucos 当中对于这个情况 能不能避免呢？引用上面的回复。
```
“注意，在访问OSTime 的时候中断是关掉的。这是因为在大多数8 位处理器上增加和拷贝一个32
位的数都需要数条指令，这些指令一般都需要一次执行完毕，而不能被中断等因素打断。"
```
哦，我上面分析的过程中 只分析了 在滴答中断执行过程中，有一个高优先级的中断发生，打断滴答中断回写过程。
忘了分析 滴答中断 打断 低优先级的线程 读取过程。
对于高优先级的中断发生，打断滴答中断回写过程，这种情况下的读取，不论rtt 或 ucos 都会受影响。此处就不做展开分析了。
对于滴答中断 打断 低优先级的线程 读取过程，在这种情况下，确定ucos里要关中断后再操作，这种办法可以避免数据被中断篡改的情况。
rtt受影响的分析过程呢跟上面的字节序刚好翻过来了。越是高字节越是受影响，当然也是只在进位的时候受影响。
还是举例一个例子好理解，假设 rt_tick = 0x12FF FFFF
那么自加之后回写过程中读取数据：
```
读取32位数过程：
读取低8位      //[0] = 0x**_FF_**
读取中间8位    //[1] = 0x**_FF_**
<-------------滴答中断 打断 低优先级的线程 读取过程
<-------------在中断自加_rt_tick  = 0x1300 0000_ 
<-------------滴答中断 返回 低优先级的线程 读取过程
读取中间8位    //[2] = 0x**_00_**
读取高8位      //[3] = 0x13

============>最终读取回来的_rt_tick  = 0x1300 FFFF_ 可见最后两个字节由于进位已经全部清零 ,最终读取结果与预期差异较大。

```
其他情况就不分析了。
恰饭了~~~