|
|
今天在將SGP30氣體傳感器的代碼移植到ucosii中使用時遇到了輸出數(shù)據(jù)一直為65535的情況。分析現(xiàn)象，開始以為是硬件問題（元器件損壞等原因）
使用了裸核代碼進(jìn)行測試，能夠正常讀取相應(yīng)參數(shù)說明硬件正常。
ucos跑死了？
增加led顯示任務(wù)，led顯示任務(wù)正常進(jìn)行
懷疑是ucos在iic進(jìn)行延時時運(yùn)行了別的任務(wù)
增加臨界區(qū)，仍然無法正常讀取
上網(wǎng)查詢后發(fā)現(xiàn)大家普遍都有這個問題
研究了下正點(diǎn)原子的綜合測試實(shí)驗(yàn)（在ucos下使用了iic）
發(fā)現(xiàn)正點(diǎn)原子的iic代碼中是沒有delay_ms的同時它iic中的延時函數(shù)的參數(shù)普遍較小，進(jìn)行了相應(yīng)的修改
測試成功，能夠正常進(jìn)行參數(shù)讀取。
刪除臨界區(qū)仍能進(jìn)行正常參數(shù)讀取。
下面是關(guān)于為什么將delay_ms改成delay_us就能成功進(jìn)行iic讀寫的解釋
仔細(xì)閱讀相應(yīng)代碼會發(fā)現(xiàn)delay_us中使用OSSchedLock();禁止了os調(diào)度而delay_ms中沒有，猜測是使用delay_ms就算進(jìn)入臨界區(qū)仍會進(jìn)行調(diào)度（不常用ucos，有大佬比較懂的勞煩您賜教）。
//延時nus
//nus為要延時的us數(shù).
void delay_us(u32 nus)
{
u32 ticks;
u32 told,tnow,tcnt=0;
u32 reload=SysTick->LOAD; //LOAD的值
ticks=nus*fac_us; //需要的節(jié)拍數(shù)
tcnt=0;
delay_osschedlock(); //阻止OS調(diào)度，防止打斷us延時
told=SysTick->VAL; //剛進(jìn)入時的計數(shù)器值
while(1)
{
tnow=SysTick->VAL;
if(tnow!=told)
{
if(tnow<told)tcnt+=told-tnow; //這里注意一下SYSTICK是一個遞減的計數(shù)器就可以了.
else tcnt+=reload-tnow+told;
told=tnow;
if(tcnt>=ticks)break; //時間超過/等于要延遲的時間,則退出.
}
};
delay_osschedunlock(); //恢復(fù)OS調(diào)度
}
//延時nms
//nms:要延時的ms數(shù)
void delay_ms(u16 nms)
{
if(delay_osrunning&&delay_osintnesting==0) //如果OS已經(jīng)在跑了,并且不是在中斷里面(中斷里面不能任務(wù)調(diào)度)
{
if(nms>=fac_ms) //延時的時間大于OS的最少時間周期
{
delay_ostimedly(nms/fac_ms); //OS延時
}
nms%=fac_ms; //OS已經(jīng)無法提供這么小的延時了,采用普通方式延時
}
delay_us((u32)(nms*1000)); //普通方式延時
}
|
評分
-
查看全部評分
|
QQ好友和群
QQ空間
騰訊微博
騰訊朋友
收藏
淘帖
頂
踩
