volatileunsignedintSystemRamTest;
voidSystemInit(void)
{
PortInit();
TimerInit();
//.......
WdtTest();//测试外部看门狗
}
voidPortInit()
{
P0=0xff;
P1=0xff;
P2=0xff;
P3=0xff;
}
voidWdtTest()
{
WdtClr();//喂外狗
if(SystemRamTest!=0x55aa)
{//上电复位可认为SystemRamTest是随机且不可能为0x55aa(概率几乎为0)
LedInit(1);//上电复位,初始化Led全亮,这样在外狗坏时常亮!!!
Delay100mS();//这里要用软件延时,因为这里还未开中断
XBYTE[0x0200]=0x77;//复位DSP
XBYTE[0x1000]=0x04;//写板型,上报PC
SystemCommand=0;//复位系统命令,但只有在上电时1次复位
SystemRamTest=0x55aa;//设置上电复位结束及RAM测试标志
while(1);//等待外部看门狗复位,测试外部看门狗喂狗
硬件引脚
}
else
{//外部看门狗复位测试通过,外狗器件完好
LedInit(0);//软件或看门狗复位,初始化Led全灭,外狗好时Led闪烁1次!!!
}
}
voidmain()
{
IE=0;//关中断
_start_();//启动时执行2次RETI
SystemInit();
while(1)
{
EA=1;//开中断
WdtClr();//喂狗
TaskMain();//主任务
PCON|=IDL_;//进入空闲状态
}
}
本贴由菜农提供"技巧"答谢诸位"狗友"~~~,转贴请注明出处(雁塔菜地)
HotPower@126.com2009.1.16于雁塔菜地
网友评论:只要有手段复位,则跑飞前的一部分
寄存器的状态本身不会被破坏。
但是由于复位,特别是硬件复位,那么内部模块被初始化为默认状态。
所以为了恢复,如P1口内容,则必须采用缓冲驱动思路,
即为P0口设置缓存寄存器Port1,再根据Port1来驱动P1.
这样就解决了复位后,由于Port1未变化,所以主循环前即可恢复P1
网友评论:当程序飞后,内部模块可能都乱了~~~
假定你根本未使用T2,那么你就不会考虑T2的初始化问题。
假定软件复位没进行ET2=0,TR2=0,且未未在T2Isr处加reti
则EA=1后,若跑飞时ET2=1,TR2=1,后果可知~~~
所以忠告大家:
初始化一定要彻底,一切系统资源都要初始化,哪怕未用!!!
有硬件看门狗时,最好while(1)自毁~~~
这样可对自己的有用模块再初始化,切记:所有中断向量表(程序)
无用的都应该用reti.
网友评论:大致应该这样(测试速度比23楼快):
#defineSOFT_DOG_TIMEXX//xx小于硬件狗溢出时间的一半
volatilebitflg_soft_dog=1;//注意加volatile,好像Keil的bit不需要
main()
{
...
while(1)
{
...
//-----------------
flg_soft_dog=1;
//-----------------
...
}
}
time_interrupt()//通用定时器
{
staticucharsoft_dog_timer=0;//应该用局部变量,最好少用全局变量
...
//--------------------------
if(flg_soft_dog)
{
flg_soft_dog=0;
soft_dog_timer=0;
}
else
{
soft_dog_timer++;
if(soft_dog_timer>=SOFT_DOG_TIME)
{
soft_dog_timer=0;
soft_reset();//软件复位
}
//--------------------------
}
...
}
网友评论:如果不小心让T2跑起来中断了,光有RETI,清不了中断标志,那将一直处于中断状态,
主程序每次只有执行一条指令的机会...结果就是系统变得很慢...
所以不用的中断最好是在里面做错误处理,检测到误中断干脆倒塌掉重新来过更爽...
网友评论:21ic的技术氛围已经看不见了。。。
俺不缺裤子!!!
俺认为有质量和技巧的应该送裤子,但绝非人情!!!
每个论坛都有精华版贴,这应该是真正的精华。
这样人们可以省去看水贴的时间。
网友评论:其实匠人也挺不容易的...
网友评论:而不是洪七公
网友评论:虽然说了是“送”,但那只是匠人戏言,并非真的徇私。大婶你收也得收,不收也得收。
另外:说到裤子的问题,其实匠人以前也解释过。斑竹加裤确实会因为各种原因而发生遗漏现象。这些原因包括:
1、遗漏、没有看到。毕竟斑竹也不是24小时值班的。
2、眼拙、没有领会帖子的奥秘。这是因为斑竹的技术并不能覆盖全部领域,会在掌握评判的标准时会有出入。
3、有些相同内容的帖子发得过于分散了,容易遗漏。比如前几天白沙兄一连发了十来个程序帖,匠人当时虽然帮他加了酷,但还是指出这种发贴方式不好。不利于读者阅读。最好的方法是,在一个主题贴下跟帖连发。
斑竹也确实有过把一些不是太精华的帖子设为酷贴。这一般是出于以下考虑:
1、鼓励新人
2、鼓励某些领域的讨论
对hotpower大婶,匠人加酷从不吝啬。并且也很诚心。大婶的“人情说”倒是反而有点见外了。
望大婶理解。
网友评论:同时希望给版主写出加酷理由~~~
不为本贴,只为以后~~~
网友评论:“staticucharsoft_dog_timer=0;//应该用局部变量,最好少用全局变量”
在这里,应该都是开辟一个单元存储吧,有什么不同呢?
网友评论:当1个变量只在某个函数中一直生存,就应该用静态局部变量。
这样变量名的选择余地大且可和其他全局变量重名。
网友评论:谢谢大叔,00.以前都用汇编,用C后,从来没有定义过静态变量。
网友评论:这样?
#defineSOFT_DOG_TIMEXX//xx小于硬件狗溢出时间的一半
bitflg_soft_dog=0;
main()
{
...
while(1)
{
...
//-----------------
flg_soft_dog=0;
//-----------------
...
}
}
time_interrupt()//通用定时器
{
...
//--------------------------
if(flg_soft_dog)
{
soft_reset();//软件复位
}
else
{
flg_soft_dog=1;
}
//--------------------------
...
}
1.ucharsoft_dog_timer=0;
因为它同时在主程序和中断中应用,故应该添加volatile修饰符。
可能Keil无事,但其他编译器未必。
2.实际soft_dog_timer根本无用!!!
这个程序实际为:
#defineSOFT_DOG_TIMEXX//xx小于硬件狗溢出时间的一半
bitflg_soft_dog=0;
ucharsoft_dog_timer=0;
main()
{
...
while(1)
{
...
//-----------------
flg_soft_dog=0;
//-----------------
...
}
}
time_interrupt()//通用定时器
{
...
//--------------------------
soft_dog_timer++;
if(soft_dog_timer>=SOFT_DOG_TIME)
{
soft_dog_timer=0;
}
if(flg_soft_dog)
{
soft_reset();//软件复位
}
else
{
flg_soft_dog=1;
}
//--------------------------
...
}
实际根本用不成~~~
网友评论:俺一般程序中的通用定时器设置为1毫秒中断。中断处理各种事件,程序中的软件复位处理只是其中一项任务。
如果软件看门狗溢出时间设置为20毫秒,哪么SOFT_DOG_TIME=20;
网友评论:这样?
#defineSOFT_DOG_TIMEXX//xx小于硬件狗溢出时间的一半
bitflg_soft_dog=0;
ucharsoft_dog_timer=0;
main()
{
...
while(1)
{
...
//-----------------
flg_soft_dog=0;
//-----------------
...
}
}
time_interrupt()//通用定时器
{
...
//--------------------------
soft_dog_timer++;
if(soft_dog_timer>=SOFT_DOG_TIME)
{
soft_dog_timer=0;
}
if(flg_soft_dog)
{
soft_reset();//软件复位
}
else
{
flg_soft_dog=1;
}
//--------------------------
...
}
网友评论:现在一直找不到方向啊……
网友评论://--------------------------
soft_dog_timer++;
if(soft_dog_timer>=SOFT_DOG_TIME)
{
soft_dog_timer=0;
if(flg_soft_dog)
{
soft_reset();//软件复位
}
else
{
flg_soft_dog=1;
}
}
//--------------------------
网友评论:哈哈,有趣
不怕一万,就怕万一.
{//上电复位可认为SystemRamTest是随机且不可能为0x55aa}
万一上电时SRAM中就是55AA,您就无法复位DSP,写板型了.
要再上加强筋!
网友评论:概率是1/65536,但由于工艺原因还要小得多!!
1/65536是一个确定的数字,但后面的由于工艺原因可能还要小的多就没有什么直接证据能证明能概率能小到多少内了。。。
所以,还是本质不可靠
网友评论:软复位的彻底性还有一个地方,怕的是有一些软件不可访问的寄存器。
如果有寄存器可以读出来上次复位的原因是上电复位还是reset复位以及内部wdt复位都话就别这样操作了,虽然说55AA概率比较小,但是也还是有的。
另,似乎没有更好都方法了。
网友评论:再多的旁证也不能做为直接证据使用
网友评论:前几天公司年终总结会抽奖(获奖面50%),我们IT室9个人有8个人抽到,
谁能
计算一下概率?
网友评论:不可能以真随机数的概率出现。
要做成真随机数发生器也不容易呀。
网友评论:复位后除了被复位的寄存器都是不变的。
而长期掉电后大部分为0的。
网友评论:哈哈,老顽童,不管你用了多少年,你如果不能从根本上证明数学概率为0,那么俺们这些愚笨之人是绝对不敢尝试的。
250天才1次这样的话,呵呵,这句可不太象你一向的作风啊,哪怕500天才1次,也是难消我等心理阴影啊。。。
网友评论:哈哈~~~