基于ARM内核目标系统中的代码运行时间测试.doc

基于ARM内核目标系统中的代码运行时间测试在ARM系统中，有时需要精确的时间测量。通常,取时间的C函数（如gettime()等）不仅通用性差（必须包含头文件DOS.H，且不支持Unix、Linux和标准C），明显不适用于ARM系统1；更成问题的是，其最短时间只能到10-2 秒级，不能提供更短的时间分度。根本原因在于： 这类函数是基于系统实时时钟（RTC）的，而RTC通常采用标准化钟表晶振，频率只有32.768 kHz而已。然而很多应用涉及s级的时间计量，这是标准化了的RTC以及基于它的时间函数所无能为力的。笔者在移植DES算法到ARM系统的实验过程中，便遇到过要定量评估加密算法耗时多少的问题，发现的确不能用上述常规的C函数解决。经对ARM芯片结构的考察，发现其内置的WatchDog系统是以系统时钟驱动的，定量性能应该很好，区分时间间隔的精细程度也应该足够。于是根据所用ARM芯片的原厂家数据手册中的说明，借用 WatchDog编写了自己的计时函数，使用起来也比较方便。考虑到ARM芯片都带有内置看门狗，笔者觉得这种方法可算是一个不错的“过渡性”解决方案，故在此加以介绍，供同行们参考并指正。1、测量原理ARM芯片中的看门狗，其原始功能是监视CPU核心运行的某些超时。这些超时的发生，通常是因为干扰和系统错误等造成的程序运行混乱。一旦发生这类情形，看门狗便请求中断服务或发出复位脉冲重启系统。为了达到这样的目的，其计时原理必须独立于系统中的任何进程。实际上，WatchDog是独立的硬件逻辑，其计时脉冲直接取自系统主时钟,因此它与RTC一样具备实时性和独立性，借用看门狗的计时体系来实现高精度时间测量是合理的。先以实验中用到的S3C44B0X为例（该实验所用的ARM开发板型号为NETARM300），具体谈谈看门狗的工作原理。系统主时钟MCLK经过可编程预分频、可选固定分频后，进入WTCNT（硬件系统的计时计数器，16位）计数。根据器件手册，计数时间间隔t_watchdog=1/(MCLK/(Prescaler value+1)/Division_factor )。式中，参数Prescaler value的取值为028-1；Division_factor有16、32、64、128四种取值。如果复位信号输出允许（即WTCON的位0置1），那么一旦计数器WTCNT的计数超过WTDAT允许的范围，看门狗就会将CPU复位。本实验过程中屏蔽掉了这种复位和中断请求功能，仅让它对脉冲计数。控制寄存器WTCON的有关各位定义图中已给出（如需详细解释可查阅器件手册，如参考文献3），其他全为保留位，可全置为0。至于MCLK具体值的计算，可以查验系统中的晶振参数（频率），读取系统时钟的PLL寄存器（如S3C44B0X的PLLCON）后算得。计算的方法都已在具体ARM芯片手册中给出。2、测量算法实现和实验结果按照所需参数设置的看门狗定时器控制寄存器WTCON的值（如前所述），在待测代码段执行之前开启看门狗定时器；等其执行完毕则关闭看门狗定时器，读取WTCNT的值即可算得运行时间。作为一个具体示例，笔者实验中所实现的算法如下：(1) 计时算法void my_CountStart() rWTCON=(MCLK/1000000-1)8)|(23); /1 MHz/64,Watchdog,nRESET,中断禁止rWTDAT=0xffff;rWTCNT=0xffff;rWTCON=(MCLK/1000000-1)8)|(23)|(15); /计时开始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(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。典型情况下，MCLK60 MHz，则看门狗能够分辨的最短时间单元t1/（60 MHz/16）0.27 s。统计误差约为t/2，即0.1s数量级。就s级的时间测量精度而言，相对误差有可能达到1%10%；不过，这对很多速度估算的场合来说还是可以接受的。如果被测时间在10 s以上，那就没有任何问题，可以认为是相当精确的了。这种思路还可用来实现精确延时