————————————————————————
斑竹竞选报名结束，初选投票正式开始！ (截止日期2007-06-30)
————————————————————————
投票处（点击进入）
————————————————————————
这是两年前我的徒弟遇到过一个故障。当时开发的一个产品，一项功能是在通电后播放40秒的语音.
测试时发现，大约通电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: E9E0 LDI R30,0x90 Load immediate
+0000007D: E0F1 LDI R31,0x01 Load immediate
+0000007E: 164E CP R4,R30 Compare
+0000007F: 065F CPC R5,R31 Compare with carry
+00000080: F428 BRCC +0x05 Branch if carry cleared
在ms_counter==255时 R4是255 R5是0
CP R4,R30 ;这时R4是255
注意！如果在这两条语句中间产生了中断 ms_counter增一 以后 R4是0 R5是1
CPC R5,R31 ;这时R5是1
简单的说是由于在整型数增一进位的时候，又受到中断的影响。
本来正确值 0x00ff或0x0100（ms_counter），
实际错误值 0x01ff（ms_counter） 先判断低位时低位是FF，中断后判断高位时高位是01
ms_counter在255时被误认为511（0x01ff）导致提示音提前关闭。
这是一大类故障，由于中断造成的操作数更改。在其他的数据类型或编译器中也可能出现，虽然出现的机率不大，但影响是不可预知的，也是更容易忽视的。
哈哈！提醒一下没学过汇编的朋友。用C写一条语句，实际是几条汇編语句。在语句中间是有可能产生中断的。
if (ms_counter<400) //这是好几条汇编
ms_counter++; //这是好几条汇编
ms_counter=45; //这是好几条汇编
经验总结：
如果在中断程序中改变了多字节类型的变量，那么中断程序以外的程序中（主程序，子函数），读写前要关中断，读写后再开中断。
举一反三：
其他的数据类型也可能有这种影响。例如：长整型、浮点型。
上面的例子是中断里写，主程序中读。相反主程序写，中断里读也可能出错。
发了这篇文章希望能对大家有所帮助，做到防患于未燃。更希望大家支持我竞选版副。
|
楼主
标题置顶
标题高亮
来自 2楼
