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｝
萬一上電時ＳＲＡＭ中就是55AA,您就無法復位ＤＳＰ，寫板型了．
要再上加強筋！
網友評論：概率是1/65536,但由于工藝原因還要小得多!!
1/65536是一個確定的數字，但后面的由于工藝原因可能還要小的多就沒有什么直接證據能證明能概率能小到多少內了。。。
所以，還是本質不可靠
網友評論：軟復位的徹底性還有一個地方，怕的是有一些軟件不可訪問的寄存器。
如果有寄存器可以讀出來上次復位的原因是上電復位還是reset復位以及內部wdt復位都話就別這樣操作了，雖然說55AA概率比較小，但是也還是有的。
另，似乎沒有更好都方法了。
網友評論：再多的旁證也不能做為直接證據使用
網友評論：前幾天公司年終總結會抽獎(獲獎面50%),我們IT室9個人有8個人抽到,
誰能
計算一下概率?
網友評論：不可能以真隨機數的概率出現。
要做成真隨機數發生器也不容易呀。
網友評論：復位后除了被復位的寄存器都是不變的。
而長期掉電后大部分為0的。
網友評論：哈哈，老頑童，不管你用了多少年，你如果不能從根本上證明數學概率為0，那么俺們這些愚笨之人是絕對不敢嘗試的。
250天才1次這樣的話，呵呵，這句可不太象你一向的作風啊，哪怕500天才1次，也是難消我等心理陰影啊。。。
網友評論：哈哈~~~
