上回說到剛接觸PIC沒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é)的問題，再分析功能實(shí)現(xiàn)上的缺陷：

1. 關(guān)于中斷現(xiàn)場(chǎng)的保護(hù)和恢復(fù)的問題
  由于movf指令可以影響STATUS，而W又要在現(xiàn)場(chǎng)保護(hù)過程中起中轉(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出的單元沒有被派做他用。如果fsr_temp,pclath_temp等也不是定義在快速存取區(qū)的話，那么，需注意在備份FSR

，PCLATH之前，要確保當(dāng)前操作在bank0處（當(dāng)然，在其他bank也可，但必須注意在恢復(fù)現(xiàn)場(chǎng)的時(shí)候，也要保證在相同的bank中對(duì)備份積存器進(jìn)

行操作，為了方便起見，建議控制在bank0處進(jìn)行保存和恢復(fù)操作）。
   至于，備份寄存器若定位與快取區(qū)中，那么對(duì)bank沒有要求，但對(duì)次序的要求仍然存在的。
  
  這是經(jīng)過改進(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)及子程序暫禁中斷所引起的問題說開去

  先將昨天貼的源程序的main部分的代碼拿出來分析:
  主程序要實(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é)果仍然沒有變化。當(dāng)loop循環(huán)執(zhí)行一次完畢之后,_clock和_convert才開始更新.
   但是這里可能會(huì)有個(gè)疑問：既然如此，計(jì)算_disp2的執(zhí)行時(shí)間大概為500ms，當(dāng)_disp2子程序執(zhí)行完畢之后，那么也開始循環(huán)執(zhí)行_clock和

_convert，然后LCM再顯示，此刻應(yīng)該顯示的是更新的時(shí)間了吧，總時(shí)間也大概為1s多一點(diǎn),為何執(zhí)行結(jié)果大概等到1分鐘左右，秒?yún)^(qū)數(shù)字才加1呢？   
   問題提得很好。

   思考原因可能為 :由于_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è)在多次更新過程中捕捉該條件的周期，就是秒?yún)^(qū)顯示加1的周期，我認(rèn)為這個(gè)周

期是固定的，也許是30秒，也許是1分鐘，也許更長(zhǎng)，只要程序長(zhǎng)度和結(jié)構(gòu)沒有發(fā)生變化。后來在程序中，我增加延時(shí)子程序的時(shí)間，結(jié)果秒?yún)^(qū)數(shù)字加1的間隔時(shí)間也跟著延長(zhǎng)了。

   到了這里，知道了問題所在，那么在基于原程序的框架下，我對(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é)果問題，該方案有幾個(gè)缺點(diǎn)：

  1) 中斷服務(wù)代碼由于調(diào)用了_clock子程序，顯得異常臃腫；
  2) 每次中斷(4096us)都調(diào)用_clock，判斷其是否到50ms(值為50000)，增加了程序的開銷，效率較低；
  3) 由于LCM慢顯示特性的原因，可能使得結(jié)果仍然不能令人滿意：

  關(guān)于3) 我描述一下一下：雖然此刻，秒?yún)^(qū)的數(shù)字能基本上每秒鐘跳變一次了，但是調(diào)試過程中出現(xiàn)了一個(gè)問題: 秒?yún)^(qū)數(shù)字跳變有時(shí)會(huì)忽略下

一個(gè)值，而跳到下下一個(gè)值去，比如，當(dāng)前顯示12，然后馬上顯示14。

  那么問題出在什么地方呢？ 試想，若_convert在進(jìn)行格式轉(zhuǎn)換時(shí)，發(fā)生中斷，且更改了sec變量，那么，_convert會(huì)按新的值進(jìn)行轉(zhuǎn)換，這

樣，本來這次要轉(zhuǎn)換并送顯示的舊值被新值給覆蓋了，所以，_disp2在顯示的時(shí)候，也就根據(jù)_convert的轉(zhuǎn)換結(jié)果,忠實(shí)地顯示了一個(gè)新值，將

本來應(yīng)該顯示的值給忽略了。

  既然如此，有什么辦法來解決呢？?jī)蓚€(gè)方法:

  (a)  _convert在對(duì)時(shí)間變量進(jìn)行格式轉(zhuǎn)換時(shí)，暫時(shí)禁止TMR0中斷，轉(zhuǎn)換后再開啟TMR0中斷；
  (b)  將_conver也歸并到中斷代碼中去，規(guī)定次序，使得_clock更新時(shí)間后，_convert再進(jìn)行轉(zhuǎn)換，這樣，格式轉(zhuǎn)換區(qū)的變量不用擔(dān)心被

_clock修改；
   
   **那么方法(a)會(huì)存在什么問題呢？試想：當(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è)暫禁中斷的過程中,中斷標(biāo)志T0IF的多次被置一

的現(xiàn)象，所以不會(huì)發(fā)生中斷響應(yīng)被沖掉的不良后果。同樣，_clock子程序在沒有加載到中斷服務(wù)代碼中去時(shí),其對(duì)TMR0的暫禁影響與_convert分

析的結(jié)果相同.

   那么,既然如此,我認(rèn)為這樣的話,由于_disp2的執(zhí)行時(shí)間也不會(huì)超過1秒，因此，不會(huì)出現(xiàn)當(dāng)秒跳變時(shí)，_convert來不及轉(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ū)取字符來顯示，如果發(fā)生中斷，_clock,_convert更改了顯示緩沖區(qū)的內(nèi)容

，使得本來即將待顯示的內(nèi)容被替換成下一次顯示的內(nèi)容。所以，該方法依然存在，而且，由于_disp執(zhí)行時(shí)間大于一次中斷的255us，如果在

_disp執(zhí)行過程暫禁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)超過PCL的256字ROM空間，而查表時(shí)未注意PCLATH內(nèi)容，以致跑飛。解決此問題后，下載到ICD中運(yùn)行，發(fā)現(xiàn)結(jié)果倒是正常

了，但是感覺時(shí)間好像有一點(diǎn)點(diǎn)慢。
   呵呵，細(xì)心的站友想必已經(jīng)看出來了，由于加了顯示功能的_clock子程序中依然是暫時(shí)禁止TMR0中斷的，雖然該時(shí)間顯示功能只是在時(shí)間跳

變時(shí)刷新LCD屏幕，但是正是由于在時(shí)間跳變時(shí)執(zhí)行時(shí)間刷新的周期過長(zhǎng)(大于4096us)，TMR0 的多次中斷請(qǐng)求最后只被響應(yīng)一次，即T0IF多次

被置1后,卻只能在_clock子程序末對(duì)TMR0解禁時(shí)得到一次中斷響應(yīng)，未被響應(yīng)的累積時(shí)間被丟棄了,沒有加到(us+1:us)中去，引起時(shí)鐘顯示變

慢了.


方案3:

由于前兩個(gè)方案均存在不近人意的問題,難道在用TMR0做秒表時(shí),且當(dāng)"定時(shí)中斷的周期小于LCD慢顯器件的驅(qū)動(dòng)刷新周期的情況下",就沒有一個(gè)

完美的解決方案么?
  留在這里和有興趣的站友一起思考...
   

  呵呵,羅羅嗦嗦地寫了這么一堆,就做為學(xué)習(xí)總結(jié)吧,也希望對(duì)一些和我一樣的新手有一些啟發(fā)...