當主函數與中斷函數共享變量問題
加入技術交流群
測試時發現，大約通電70-80次就有一次播放時間不夠40秒就提前停止。
當時以為復位有問題，換了復位片，沒好。又先后換了CPU，語音芯片，還有電源，都沒有好轉。排除了硬件芯片原因導致的此現象.
后來又從軟件中查找原因。反復查找軟件邏輯，也沒發現問題。后來偶然發現在主while里增加大量延時后，穩定性提高。
幾乎不再出現問題。但是我還是覺得不對勁,用了兩天時間終于找到了原因。因為這是公司的程序，所以不能貼源碼。
我把其他程序都略去，只把出錯的程序大概寫一下。大家看看能找到問題嗎？
unsigned int ms_counter;
void T0()
{
//定時器程序每100毫秒中斷一次，程序略
if (ms_counter<1000) ms_counter++;
}
void main(void)
{
//初始化定時器程序每100毫秒中斷一次，程序略
unsigned char tt;
ms_counter=0;
tt=0;//用tt控制只響一次
while(1)
{
if (ms_counter<400)
{
if (tt==0)
{
tt=1;
Sound_on();
}
}
else
{
Sound_off();
}
//其他程序
//。。。。。。
}
}
高手們不要笑，菜鳥們坐好
問題出在ms_counter不到400時，程序提前執行了Sound_off();
原因分析：if (ms_counter<400)中的ms_counter是兩字節的整型，而且在中斷里有增一操作。
這就有一種錯誤的可能
if (ms_counter<400)//被編譯器翻譯成以下語句
+0000007C:E9E0LDIR30,0x90Load immediate
+0000007D:E0F1LDIR31,0x01Load immediate
+0000007E:164ECPR4,R30Compare
+0000007F:065FCPCR5,R31Compare with carry
+00000080:F428BRCC+0x05Branch if carry cleared
在ms_counter==255時R4是255R5是0
CPR4,R30;這時R4是255
注意！如果在這兩條語句中間產生了中斷ms_counter增一以后R4是0R5是1
CPCR5,R31;這時R5是1
簡單的說是由于在整型數增一進位的時候，又受到中斷的影響。
本來正確值0x00ff或0x0100（ms_counter），
實際錯誤值0x01ff（ms_counter）先判斷低位時低位是FF，中斷后判斷高位時高位是01
ms_counter在255時被誤認為511（0x01ff）導致提示音提前關閉。
當主函數與中斷函數共用變量時，可能發生：
1.主函數對變量的讀-寫，可能造成中斷函數對變量的讀-寫無效。
如：當主函數剛剛把變量讀入到內部寄存器時，還未再回寫到變量中時，發生中斷，中斷中改寫了變量。當中斷返回時，主函數將值再回寫到變量中。造成中斷函數對變量的改寫無效。
2.多字節變量讀取錯誤。
如：當變量的其中一個字節讀入到寄存器中時，發生中斷，中斷中改寫了變量值。當中斷返回時，變量的其他字節繼續被讀入到寄存器中，造成新舊字節組合錯誤。
主函數與中斷函數共享變量問題類似兩個線程共享資源的問題，如何解決共享資源沖突是系統結構設計的關鍵
解決方法
1.volatile正確使用.
2.注意臨界段(或原子操作).（寫變量時,關中斷,寫完后再開）
操作系統中對這種問題有另一種解決辦法，即引入一個與ms_counter相同類型的臨時變量：
unsigned int tmp_counter;
在使用ms_counter做判斷前作如下操作：
do {
tmp_counter = ms_counter;
while (tmp_counter != ms_counter);
然后使用tmp_counter代替ms_counter進行判斷，這樣可以保證回避樓主所述問題。
一般說來，volatile用在如下的幾個地方：
1)、中斷服務程序中修改的供其它程序檢測的變量需要加volatile；
2)、多任務環境下各任務間共享的標志應該加volatile；
3)、存儲器映射的硬件寄存器通常也要加volatile說明，因為每次對它的讀寫都可能由不同意義；
評論