今天在將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)); //普通方式延時
}
|
