基于ARM內核目標系統中的代碼運行時間測試

　　int my_CountStop() {

　　int i=0;

　　rWTCON=((MCLK/1000000-1)8)|(23);　　　//計時結束

　　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("counting 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的精度無法滿足的應用，這種處理都不失為一種準確、高效的方法。

參考文獻:

[1].S3C44B0Xdatasheethttp://www.dzsc.com/datasheet/S3C44B0X_589522.html.
[2].1/16datasheethttp://www.dzsc.com/datasheet/1%2f16_2510134.html.