关于cc2540时钟更新算法osalTimeUpdate()优化

本文探讨了蓝牙4.0协议栈1.3.2版本中,cc2540时钟更新算法`osalTimeUpdate()`存在的潜在溢出风险。通过对MAXCALCTICKS的分析,指出在ticks625us较大时,while循环可能导致remUsTicks超过7,从而引发溢出。提出的改进方案是找到一个能整除8的MAXCALCTICKS值,如13104,以消除while循环内的余数获取和溢出隐患。

本博文是原创博文,转载请注明出处


我研究的代码是蓝牙4.0,协议栈版本是1.3.2
问题来源是 `

// (MAXCALCTICKS * 5) + (max remainder) must be <= (uint16 max),
// so: (13105 * 5) + 7 <= 65535
 #define MAXCALCTICKS  ((uint16)(13105))

从上面可以看到对于MAXCALCTICKS的定义是为了限制ticks625us这个微秒级别的变量转化成ms时不溢出;他这里就有个默认 max remainder 变量认为最大是7;也就是确定这个MAXCALCTICKS宏是以认为这个余数最大是7。不会超过7,但是我认为它在下面函数处理中存储余数变量remUsTicks就可以超过7,虽然在us转ms时候虽然用了while循环但是任然有溢出的可能。
这是在osalTimeUpdate函数里对时间从us转到ms的转化代码

 while ( ticks625us > MAXCALCTICKS )     //主要为了数据过大转换为ms是溢出了。MAXCALCTICKS >13105就会溢出从零开始,对时间来说是不行的
    {
      ticks625us -= MAXCALCTICKS;
      elapsedMSec += MAXCA
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值