很多測量時間的C函數在ARM中都不能使用。某些能使用的，也是基于系統實時時鐘（RTC），故最短時間單位只能達到10-2 s。作為一種通用的精密計時方法,為了取得更精細的時間度量，可以考慮啟用ARM芯片內置的WatchDog實現擴展了的實時時鐘功能，并推廣到程序精確延時的用途，彌補現有C函數的不足。本文對此作出分析，并給出了具體的實驗描述。

關鍵詞 精確時間 測量精密計時 ARM實時時鐘擴展 看門狗

　　在ARM系統中，有時需要精確的時間測量。通常,取時間的C函數（如gettime()等）不僅通用性差（必須包含頭文件DOS.H，且不支持Unix、Linux和標準C），明顯不適用于ARM系統[1]；更成問題的是，其最短時間只能到10-2 秒級，不能提供更短的時間分度。根本原因在于： 這類函數是基于系統實時時鐘（RTC）的，而RTC通常采用標準化鐘表晶振，頻率只有32.768 kHz而已[2]。

　　然而很多應用涉及μs級的時間計量，這是標準化了的RTC以及基于它的時間函數所無能為力的。筆者在移植DES算法到ARM系統的實驗過程中，便遇到過要定量評估加密算法耗時多少的問題，發現的確不能用上述常規的C函數解決。經對ARM芯片結構的考察，發現其內置的WatchDog系統是以系統時鐘驅動的，定量性能應該很好，區分時間間隔的精細程度也應該足夠。于是根據所用ARM芯片的原廠家數據手冊中的說明，借用 WatchDog編寫了自己的計時函數，使用起來也比較方便。考慮到ARM芯片都帶有內置看門狗，筆者覺得這種方法可算是一個不錯的“過渡性”解決方案，故在此加以介紹，供同行們參考并指正。

1? 測量原理

　　ARM芯片中的看門狗，其原始功能是監視CPU核心運行的某些超時。這些超時的發生，通常是因為干擾和系統錯誤等造成的程序運行混亂。一旦發生這類情形，看門狗便請求中斷服務或發出復位脈沖重啟系統。為了達到這樣的目的，其計時原理必須獨立于系統中的任何進程。實際上，WatchDog是獨立的硬件邏輯，其計時脈沖直接取自系統主時鐘,因此它與RTC一樣具備實時性和獨立性，借用看門狗的計時體系來實現高精度時間測量是合理的。

　　先以實驗中用到的S3C44B0X為例（該實驗所用的ARM開發板型號為NETARM300），具體談談看門狗的工作原理。其原理框圖如圖1所示，圖中MCLK即系統主時鐘[3]。

圖1? S3C44B0X內嵌看門狗硬件原理框圖

　　從圖中可以看出，系統主時鐘MCLK經過可編程預分頻、可選固定分頻后，進入WTCNT（硬件系統的計時計數器，16位）計數。根據器件手冊，計數時間間隔t_watchdog=1/(MCLK/(Prescaler value+1)/Division_factor )。式中，參數Prescaler value的取值為0～28-1；Division_factor有16、32、64、128四種取值。如果復位信號輸出允許（即WTCON的位0置1），那么一旦計數器WTCNT的計數超過WTDAT允許的范圍，看門狗就會將CPU復位。本實驗過程中屏蔽掉了這種復位和中斷請求功能，僅讓它對脈沖計數。

　　控制寄存器WTCON的有關各位定義圖中已給出（如需詳細解釋可查閱器件手冊，如參考文獻[3]），其他全為保留位，可全置為0。

　　至于MCLK具體值的計算，可以查驗系統中的晶振參數（頻率），讀取系統時鐘的PLL寄存器（如S3C44B0X的PLLCON）后算得。計算的方法都已在具體ARM芯片手冊中給出[4]。

2? 測量算法實現和實驗結果

　　按照所需參數設置的看門狗定時器控制寄存器WTCON的值（如前所述），在待測代碼段執行之前開啟看門狗定時器；等其執行完畢則關閉看門狗定時器，讀取WTCNT的值即可算得運行時間。作為一個具體示例，筆者實驗中所實現的算法如下：

(1)? 計時算法

void my_CountStart() {
?????? rWTCON=((MCLK/1000000-1)<<8)|(2<<3);??? //1 MHz/64,Watchdog,nRESET,中斷禁止
?????? rWTDAT=0xffff;
?????? rWTCNT=0xffff;?
?????? rWTCON=((MCLK/1000000-1)<<8)|(2<<3)|(1<<5);?????? //計時開始
}
int my_CountStop() {
?????? int i=0;
?????? rWTCON=((MCLK/1000000-1)<<8)|(2<<3);?????? //計時結束
?????? i=0xffff-rWTCNT;//每16 μs計數一次
?????? return i*16;
}

(2)? 應用

int Main() {
??????? my_CountStart();
??????? Des_Go(buf, buf, sizeof(str), key, sizeof(key), ENCRYPT, Is3DES);
??????? encrypt_time=my_CountStop();
}

　　需要指出： 在改變WTCON的值之前應將原有值保存，待測量完成后再復原WTCON。之所以強調這一點，是因為系統別處很可能在使用看門狗功能。

　　實驗當中，對長度為189字節的字符串采用3次DES加密。密鑰長度為15位，測得的加密時間為28 832 μs，解密時間為28 896 μs。縮短字符串長度，測得的加密時間基本呈線性變化： 字符串長度為107字節而其他地方不變時，加密耗時16 928 μs，解密耗時16 948 μs；字符串長度為41字節而其他地方不變時，加密耗時7 424 μs,解密耗時7 424 μs。對于相同長度的字符串，密鑰長度的改變對加密/解密時間的影響不是很大。

　　值得一提的是，剛開始實驗時，被加密字符串分別取為190字節和75字節，測得耗時分別是34 032 μs和16 928 μs，顯然與倍增的關系相差很遠。分析程序后發現，原來問題出在加密算法中間的打印語句“Uart_Printf("\ncounting begin...!!!")”上。原來以為它耗時很少，故沒有將它從加密算法中移走；移走后再試，耗時大減，分別為29 600 μs和12 496 μs,與字符數倍增、時間倍增的預期基本相符。上面的實驗，還使筆者得知該打印語句占用了4 432 μs。稍微修改條件,繼續實驗： 當上述打印語句的字節數擴充為原來的4倍時，測得該語句耗時17 728 μs。可見,耗時與打印內容的字節數基本上成正比；另外，這種打印語句與加密/解密算法本身相比，并不是想當然地只占用一點點時間。（上述數據與PC機串口通信波特率的設置無明顯關系。實際測試結果為： 波特率由115 200 bps下降到57 600 bps，沒有可以察覺到的差別。）

3? 測量方法討論

　　ARM內置看門狗用作時間度量的適用范圍，大體以μs數量級為界。比如，從S3C44B0X的器件特性說明中可知，MCLK在看門狗計時器里的分頻比至少是1/16。典型情況下，MCLK＝60 MHz，則看門狗能夠分辨的最短時間單元t＝1/（60 MHz/16）＝0.27 μs。統計誤差約為t/2，即0.1?μs數量級。就μs級的時間測量精度而言，相對誤差有可能達到1%~10%；不過，這對很多速度估算的場合來說還是可以接受的。如果被測時間在10? μs以上，那就沒有任何問題，可以認為是相當精確的了。

　　這種思路還可用來實現精確延時，因為它的定時不依賴于指令執行時間（指令執行要受到系統調度等的影響，因而有很多不確定因素），而取決于對主時鐘的硬件分頻計數。

　　由此實驗推廣，ARM內置看門狗可以作為此類系統中的第二時鐘存在。對于那些時間要求精確到μs、RTC的精度無法滿足的應用，這種處理都不失為一種準確、高效的方法。