今天在将SGP30气体传感器的代码移植到ucosii中使用时遇到了输出数据一直为65535的情况。分析现象，开始以为是硬件问题（元器件损坏等原因）
使用了裸核代码进行测试，能够正常读取相应参数说明硬件正常。
ucos跑死了？
增加led显示任务，led显示任务正常进行
怀疑是ucos在iic进行延时时运行了别的任务
增加临界区，仍然无法正常读取
上网查询后发现大家普遍都有这个问题
研究了下正点原子的综合测试实验（在ucos下使用了iic）
发现正点原子的iic代码中是没有delay_ms的同时它iic中的延时函数的参数普遍较小，进行了相应的修改
测试成功，能够正常进行参数读取。
删除临界区仍能进行正常参数读取。
下面是关于为什么将delay_ms改成delay_us就能成功进行iic读写的解释
仔细阅读相应代码会发现delay_us中使用OSSchedLock();禁止了os调度而delay_ms中没有，猜测是使用delay_ms就算进入临界区仍会进行调度（不常用ucos，有大佬比较懂的劳烦您赐教）。
//延时nus
//nus为要延时的us数.
void delay_us(u32 nus)
{
u32 ticks;
u32 told,tnow,tcnt=0;
u32 reload=SysTick->LOAD; //LOAD的值
ticks=nus*fac_us; //需要的节拍数
tcnt=0;
delay_osschedlock(); //阻止OS调度，防止打断us延时
told=SysTick->VAL; //刚进入时的计数器值
while(1)
{
tnow=SysTick->VAL;
if(tnow!=told)
{
if(tnow<told)tcnt+=told-tnow; //这里注意一下SYSTICK是一个递减的计数器就可以了.
else tcnt+=reload-tnow+told;
told=tnow;
if(tcnt>=ticks)break; //时间超过/等于要延迟的时间,则退出.
}
};
delay_osschedunlock(); //恢复OS调度
}
//延时nms
//nms:要延时的ms数
void delay_ms(u16 nms)
{
if(delay_osrunning&&delay_osintnesting==0) //如果OS已经在跑了,并且不是在中断里面(中断里面不能任务调度)
{
if(nms>=fac_ms) //延时的时间大于OS的最少时间周期
{
delay_ostimedly(nms/fac_ms); //OS延时
}
nms%=fac_ms; //OS已经无法提供这么小的延时了,采用普通方式延时
}
delay_us((u32)(nms*1000)); //普通方式延时
}
|
