專注差異化嵌入式產(chǎn)品解決方案 給智能產(chǎn)品定制注入靈魂給予生命
提供開(kāi)發(fā)工具、應(yīng)用測(cè)試 完善的開(kāi)發(fā)代碼案例庫(kù)分享
從全面的產(chǎn)品導(dǎo)入到強(qiáng)大技術(shù)支援服務(wù) 全程貼心伴隨服務(wù),創(chuàng)造無(wú)限潛能!
提供新的芯片及解決方案,提升客戶產(chǎn)品競(jìng)爭(zhēng)力
提供最新的單片機(jī)資訊,行業(yè)消息以及公司新聞動(dòng)態(tài)
單片機(jī)方案開(kāi)發(fā)商深圳英銳恩分享PIC單片機(jī)學(xué)習(xí)知識(shí)點(diǎn),菜鳥學(xué)PIC單片機(jī)(三)LCD時(shí)鐘的總結(jié),并由中斷暫禁的后果說(shuō)開(kāi)去。
上回說(shuō)到剛接觸PIC沒(méi)20天的菜鳥碧水長(zhǎng)天準(zhǔn)備"野心勃勃"寫一段LCD顯示精確時(shí)鐘的但遭到無(wú)情狙擊的故事,幸好得到這里行家的點(diǎn)撥,方能理清一點(diǎn)頭緒,于是,今天就接著上回的故事,總結(jié)一些通用的注意事項(xiàng),并對(duì)LCD顯示精確時(shí)鐘進(jìn)行功能實(shí)現(xiàn)上的分析.
一、先總結(jié)一些細(xì)節(jié)的問(wèn)題,再分析功能實(shí)現(xiàn)上的缺陷:
1. 關(guān)于中斷現(xiàn)場(chǎng)的保護(hù)和恢復(fù)的問(wèn)題
由于movf指令可以影響STATUS,而W又要在現(xiàn)場(chǎng)保護(hù)過(guò)程中起中轉(zhuǎn)寄存器的作用,因此,應(yīng)先保護(hù)W,再保護(hù)STATUS,最后是保存其他現(xiàn)場(chǎng)變
量。保存的時(shí)候應(yīng)注意,如果W的備份寄存器w_temp若不是位于快速存取區(qū)70H~7FH,假如w_temp定位為0x20,那么還需保證bank1,bank2,
bank3中的0xA0,0x120,0x1A0出的單元沒(méi)有被派做他用。如果fsr_temp,pclath_temp等也不是定義在快速存取區(qū)的話,那么,需注意在備份FSR
,PCLATH之前,要確保當(dāng)前操作在bank0處(當(dāng)然,在其他bank也可,但必須注意在恢復(fù)現(xiàn)場(chǎng)的時(shí)候,也要保證在相同的bank中對(duì)備份積存器進(jìn)
行操作,為了方便起見(jiàn),建議控制在bank0處進(jìn)行保存和恢復(fù)操作)。
至于,備份寄存器若定位與快取區(qū)中,那么對(duì)bank沒(méi)有要求,但對(duì)次序的要求仍然存在的。
這是經(jīng)過(guò)改進(jìn)后的恢復(fù)和保存現(xiàn)場(chǎng)代碼:
ORG 0x000 ; processor reset vector
nop ; ICD need
goto main ; go to beginning of program
ORG 0x004 ; interrupt vector location
movwf w_temp ; 先保存W
movfw STATUS ; 再保存STATUS到W中
clrf STATUS ; 注意該指令,確保對(duì)status_temp,pclath_temp的操作在bank0中
; (如果備份寄存器定義在快取區(qū)中,可無(wú)取消此條clrf及恢復(fù)現(xiàn)場(chǎng)那條clrf指令)
movwf status_temp ; 保存上上條指令備份在W中的STATUS
movfw PCLATH ; 備份PCLATH
movwf pclath_temp
movfw FSR ; 備份FSR
movwf fsr_temp
; 可添加其他欲保護(hù)的變量
;******************** 中斷服務(wù)代碼
btfss INTCON,T0IE ; 判斷是否為T0中斷
goto other_int
btfss INTCON,T0IF ; it 's the time of T0 int
goto other_int
bcf INTCON,T0IF ; 是T0中斷,清除中斷標(biāo)志
movlw 0x10 ; 微秒的高位字節(jié)加上定時(shí)時(shí)間 256x16分頻=4096=0x1000的高位(0x10)
addwf us+1
goto end_int
other_int ; 可添加其他中斷服務(wù)代碼
nop ; other isr code can be added
;**********************************
end_int ; 恢復(fù)現(xiàn)場(chǎng)
clrf STATUS ; 確?;謴?fù)現(xiàn)場(chǎng)的操作在bank0中(如果備份寄存器定義在快取區(qū)中,可無(wú)取消此條指令)
; 可添加恢復(fù)其他變量
movfw fsr_temp ; 恢復(fù)FSR
movwf FSR
movfw pclath_temp ; 恢復(fù)PCLATH(FSR和PCLATH的恢復(fù)無(wú)先后之分)
movwf PCLATH
movfw status_temp ; 先恢復(fù)STATUS
movwf STATUS ;
swapf w_temp,f
swapf w_temp,w ; 最后恢復(fù)W,采用swapf是因?yàn)槠洳粫?huì)影響STATUS
retfie ; 中斷返回
;*********
2.(保留區(qū)域,待添加)
--------------------------------------------
二、分析功能實(shí)現(xiàn)上的缺陷,并由中斷響應(yīng)及子程序暫禁中斷所引起的問(wèn)題說(shuō)開(kāi)去
先將昨天貼的源程序的main部分的代碼拿出來(lái)分析:
主程序要實(shí)現(xiàn)的功能是顯示時(shí)鐘:
HH MM SS
00:00:00
定時(shí)中斷每次產(chǎn)生4096us的增量,在中斷服務(wù)中,將此時(shí)間增量累加在(us+1:us)兩個(gè)相鄰的字節(jié)中,由_clock子程序
對(duì)(us+1:us)進(jìn)行及時(shí)判斷,超出50ms即取走一個(gè)50ms的增量,并保留余量在(us+1:us)中以保證長(zhǎng)時(shí)間定時(shí)精確.
主程序流程:
main
nop
call _init ; 調(diào)用初始化子程序,清緩沖區(qū),實(shí)現(xiàn)液晶顯示器和TMR0的初始化操作.
call _disp1 ; 調(diào)用顯示字符" HH MM SS "的子程序
loop
call _clock ; 調(diào)用時(shí)間更新子程序,更新定時(shí)中斷產(chǎn)生的時(shí)間累加值
call _convert ; 調(diào)用時(shí)鐘的小時(shí),分,秒的BCD碼轉(zhuǎn)換子程序,并換成字符對(duì)應(yīng)的ASCII碼
call _disp2 ; 調(diào)用轉(zhuǎn)換后的小時(shí):分:秒字符的顯示子程序
goto loop ; 執(zhí)行主循環(huán)
分析如下:
由于_clcok和_convert碼制字符轉(zhuǎn)換子程序與時(shí)間顯示_disp2子程序是前后的順序關(guān)系的,在時(shí)間顯示時(shí),前兩個(gè)子程序是不工作的,由于
LCM的慢顯特性,使得該子程序執(zhí)行時(shí)間較長(zhǎng),這樣,即使中斷定時(shí)時(shí)間已經(jīng)累計(jì)到應(yīng)改變顯示結(jié)果的條件,但此刻_disp2若仍在顯示上一時(shí)間
,使得_clcok不能及時(shí)更新時(shí)間,并且_convert不能轉(zhuǎn)換代碼,那么顯示結(jié)果仍然
沒(méi)有變化。當(dāng)loop循環(huán)執(zhí)行一次完畢之后,_clock和_convert才開(kāi)始更新.
但是這里可能會(huì)有個(gè)疑問(wèn):既然如此,計(jì)算_disp2的執(zhí)行時(shí)間大概為500ms,當(dāng)_disp2子程序執(zhí)行完畢之后,那么也開(kāi)始循環(huán)執(zhí)行_clock和
_convert,然后LCM再顯示,此刻應(yīng)該顯示的是更新的時(shí)間了吧,總時(shí)間也大概為1s多一點(diǎn),為何執(zhí)行結(jié)果大概等到1分鐘左右,秒?yún)^(qū)數(shù)字才加1呢?
問(wèn)題提得很好。
思考原因可能為 :由于_clock不能及時(shí)更新時(shí)間,及不能及時(shí)取走(us+1:us)中大于50ms時(shí)的50ms量,但中斷服務(wù)代碼中始終嚴(yán)格執(zhí)行下面兩
條指令:
movlw 0x10 ; 256x16分頻=4096=0x1000的高位(0x10)
addwf us+1 ; 微秒的高位字節(jié)加上定時(shí)時(shí)間
多次累加后(15次累加令us+1單元的內(nèi)容為從00H到F0H)令us+1單元溢出,丟失定時(shí)的時(shí)間增量,若當(dāng)_clock更新時(shí),(us+1:us)發(fā)生溢出使得其
值小于50ms(代數(shù)值50000),因此也不能使得變量ms50的值增加,那么秒鐘變量sec也不會(huì)變化,轉(zhuǎn)換后時(shí)間顯示仍然保持不變.
注意: 當(dāng)_clock更新時(shí)間時(shí),(us+1:us)若滿足大于50 000的條件,則ms50變量加一,在main主程序中_clock循環(huán)更新時(shí),若捕捉到20次
(us+1:us)單元大于50000(50ms)時(shí),sec的值才能加1。而這個(gè)在多次更新過(guò)程中捕捉該條件的周期,就是秒?yún)^(qū)顯示加1的周期,我認(rèn)為這個(gè)周
期是固定的,也許是30秒,也許是1分鐘,也許更長(zhǎng),只要程序長(zhǎng)度和結(jié)構(gòu)沒(méi)有發(fā)生變化。后來(lái)在程序中,我增加延時(shí)子程序的時(shí)間,結(jié)果秒?yún)^(qū)數(shù)字加1的間隔時(shí)間也跟著延長(zhǎng)了。
到了這里,知道了問(wèn)題所在,那么在基于原程序的框架下,我對(duì)幾種解決方案都嘗試了一下:
方案1:
[既然癥結(jié)是在_clock不能真實(shí)捕捉到每一次中斷時(shí)間累加增量(us+1:us)值大于50ms(50000)的條件,那么,將_clock內(nèi)嵌中斷中去,中
斷每一次改變us+1的值然后馬上進(jìn)行時(shí)間更新,這樣,使得_clock能真實(shí)捕捉每一次(us+1:us)值大于50ms(50000)的條件,也能真實(shí)更新系統(tǒng)時(shí)
間。]
方案1分析:這樣確實(shí)可以保證每一次都可以捕捉us時(shí)間增量,不考慮運(yùn)行的結(jié)果問(wèn)題,該方案有幾個(gè)缺點(diǎn):
1) 中斷服務(wù)代碼由于調(diào)用了_clock子程序,顯得異常臃腫;
2) 每次中斷(4096us)都調(diào)用_clock,判斷其是否到50ms(值為50000),增加了程序的開(kāi)銷,效率較低;
3) 由于LCM慢顯示特性的原因,可能使得結(jié)果仍然不能令人滿意:
關(guān)于3) 我描述一下一下:雖然此刻,秒?yún)^(qū)的數(shù)字能基本上每秒鐘跳變一次了,但是調(diào)試過(guò)程中出現(xiàn)了一個(gè)問(wèn)題: 秒?yún)^(qū)數(shù)字跳變有時(shí)會(huì)忽略下
一個(gè)值,而跳到下下一個(gè)值去,比如,當(dāng)前顯示12,然后馬上顯示14。
那么問(wèn)題出在什么地方呢? 試想,若_convert在進(jìn)行格式轉(zhuǎn)換時(shí),發(fā)生中斷,且更改了sec變量,那么,_convert會(huì)按新的值進(jìn)行轉(zhuǎn)換,這
樣,本來(lái)這次要轉(zhuǎn)換并送顯示的舊值被新值給覆蓋了,所以,_disp2在顯示的時(shí)候,也就根據(jù)_convert的轉(zhuǎn)換結(jié)果,忠實(shí)地顯示了一個(gè)新值,將
本來(lái)應(yīng)該顯示的值給忽略了。
既然如此,有什么辦法來(lái)解決呢??jī)蓚€(gè)方法:
(a) _convert在對(duì)時(shí)間變量進(jìn)行格式轉(zhuǎn)換時(shí),暫時(shí)禁止TMR0中斷,轉(zhuǎn)換后再開(kāi)啟TMR0中斷;
(b) 將_conver也歸并到中斷代碼中去,規(guī)定次序,使得_clock更新時(shí)間后,_convert再進(jìn)行轉(zhuǎn)換,這樣,格式轉(zhuǎn)換區(qū)的變量不用擔(dān)心被
_clock修改;
**那么方法(a)會(huì)存在什么問(wèn)題呢?試想:當(dāng)_convert在轉(zhuǎn)換時(shí),TMR0定時(shí)時(shí)間到,TMR0向內(nèi)核提交中斷,但由于TMR0中斷請(qǐng)求被禁止,即使
_convert轉(zhuǎn)換完畢之后,允許TMR0中斷,那么TMR0的中斷請(qǐng)求會(huì)不會(huì)被丟棄呢? 顯然,根據(jù)PIC的中斷系統(tǒng),當(dāng)TMR0定時(shí)時(shí)間到后,首先將
T0IF置1,并由T0IF向內(nèi)核提出中斷請(qǐng)求,如果該中斷請(qǐng)求被禁止,那么只要其中斷標(biāo)志T0IF仍然保持為1,當(dāng)該中斷響應(yīng)解禁之后,內(nèi)核根據(jù)
T0IF立即響應(yīng)其中斷。
因此,方法(a)中"TMR0的中斷請(qǐng)求可能會(huì)被遺棄的擔(dān)心"是多余的.
并且,由于_convert的執(zhí)行時(shí)間少于一個(gè)中斷周期,所以它對(duì)中斷的暫禁操作不會(huì)出現(xiàn)在一個(gè)暫禁中斷的過(guò)程中,中斷標(biāo)志T0IF的多次被置一
的現(xiàn)象,所以不會(huì)發(fā)生中斷響應(yīng)被沖掉的不良后果。同樣,_clock子程序在沒(méi)有加載到中斷服務(wù)代碼中去時(shí),其對(duì)TMR0的暫禁影響與_convert分
析的結(jié)果相同.
那么,既然如此,我認(rèn)為這樣的話,由于_disp2的執(zhí)行時(shí)間也不會(huì)超過(guò)1秒,因此,不會(huì)出現(xiàn)當(dāng)秒跳變時(shí),_convert來(lái)不及轉(zhuǎn)換而丟棄上一次待
轉(zhuǎn)換的字符。所以,結(jié)果應(yīng)該是正常.
于是按照這種方法修改程序,結(jié)果發(fā)現(xiàn)秒?yún)^(qū)每次都跳變,最小增量為2,最多為為3(跳變周期大約1.2秒)。于是將延遲子程序的外循環(huán)值由
64H-〉40H(大概右25ms變成16ms),結(jié)果仍然如此,秒?yún)^(qū)每次都跳變,只是跳變節(jié)奏比未修改延時(shí)子程序前變快很多(跳變周期大約0.6s),但最
小跳變?cè)隽?,最多為2。
[正在分析其根源,也請(qǐng)有興趣的兄弟一起思考一下.....]
那么那試試方法(b).我按方法(b)修改了程序,結(jié)果發(fā)現(xiàn),仍然出現(xiàn)秒?yún)^(qū)數(shù)字跳變的情況。
究其原因,跟3)類似:當(dāng)_disp2運(yùn)行的時(shí)候,準(zhǔn)備從顯示緩沖區(qū)取字符來(lái)顯示,如果發(fā)生中斷,_clock,_convert更改了顯示緩沖區(qū)的內(nèi)容
,使得本來(lái)即將待顯示的內(nèi)容被替換成下一次顯示的內(nèi)容。所以,該方法依然存在,而且,由于_disp執(zhí)行時(shí)間大于一次中斷的255us,如果在
_disp執(zhí)行過(guò)程暫禁TMR0中斷將會(huì)丟棄中斷請(qǐng)求(即:TMR0的中斷請(qǐng)求被自己下一次中斷請(qǐng)求覆蓋,上一次中斷請(qǐng)求被忽略,顯示時(shí)間將變慢)。
----------------------------------------------------------------
方案2:
[中斷服務(wù)仍然只改變us+1的值,但是格式轉(zhuǎn)換及顯示功能內(nèi)嵌到_clock子程序中去,主程序執(zhí)行_clock循環(huán)。]
下午我按這種方式更改了程序,在軟件模擬時(shí)發(fā)現(xiàn)程序跑飛。原因是:內(nèi)嵌了這些功能之后,代碼由400行變成500多行,在_disp1查表顯示
字符時(shí),_table已經(jīng)超過(guò)PCL的256字ROM空間,而查表時(shí)未注意PCLATH內(nèi)容,以致跑飛。解決此問(wèn)題后,下載到ICD中運(yùn)行,發(fā)現(xiàn)結(jié)果倒是正常
了,但是感覺(jué)時(shí)間好像有一點(diǎn)點(diǎn)慢。
呵呵,細(xì)心的站友想必已經(jīng)看出來(lái)了,由于加了顯示功能的_clock子程序中依然是暫時(shí)禁止TMR0中斷的,雖然該時(shí)間顯示功能只是在時(shí)間跳
變時(shí)刷新LCD屏幕,但是正是由于在時(shí)間跳變時(shí)執(zhí)行時(shí)間刷新的周期過(guò)長(zhǎng)(大于4096us),TMR0 的多次中斷請(qǐng)求最后只被響應(yīng)一次,即T0IF多次
被置1后,卻只能在_clock子程序末對(duì)TMR0解禁時(shí)得到一次中斷響應(yīng),未被響應(yīng)的累積時(shí)間被丟棄了,沒(méi)有加到(us+1:us)中去,引起時(shí)鐘顯示變慢了.
方案3:
由于前兩個(gè)方案均存在不近人意的問(wèn)題,難道在用TMR0做秒表時(shí),且當(dāng)"定時(shí)中斷的周期小于LCD慢顯器件的驅(qū)動(dòng)刷新周期的情況下",就沒(méi)有一個(gè)完美的解決方案么?
留在這里和有興趣的站友一起思考...
深圳市英銳恩科技有限公司(www.traavell.com)為單片機(jī)技術(shù)服務(wù)\開(kāi)發(fā)設(shè)計(jì)和產(chǎn)品代理商,授權(quán)MDT(麥肯 MICON)單片機(jī)A級(jí)代理商,MICROCHIP產(chǎn)品全系列單片機(jī)與模擬器件授權(quán)推廣商。同時(shí)A級(jí)代理分銷NOVACAP、Syfer、Voltronics精密可調(diào)電容、DLI寬帶隔直微波電容,專注分銷AIC沛亨半導(dǎo)體(電源管理IC)、IR(場(chǎng)效應(yīng)管)。
如:
MDT2020/MDT10P20(完全兼容PIC16C57C、PIC16F57、CF775,直接替換,不要任何硬軟與軟件修改)
特性:ROM:2K,腳位:28PIN,I/O:22PIN,復(fù)位時(shí)間極快.2V,低電壓工作.低功耗,溫度范圍寬。
MDT2030 (完全兼容PIC16C58B,直接替換,不要任何硬軟與軟件修改)
特性:ROM:2K,腳位:18PIN,I/O:13PIN,復(fù)位時(shí)間極快.2V,低電壓工作.低功耗,溫度范圍寬。