基于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.