在进行DSP开发时,代码编写完成后,如果时间不满足要求,则必须对代码进行优化,以更加适应DSP环境 。而在进行优化时,我们可以先测算每个函数的运行时间,从中到耗时较多的函数进行优化。
CCS官方给出了两种测试代码运行时间的办法:
方法一. Profileclock in CCS
1.在菜单栏的Tools->profile-> Setup Profile DataCollection ;在出来的Profile Setup 中选择新建,然后新建一个Configuration ,再在右边的Activities 中勾上Profile alll Function for Total Cycles;
2.然后在菜单栏选择Target ->Debug Active Project; 最后在运行。
3. Tools->profile-> view function profileresults即可看到结果。
网上也有针对低版本的测试方法—https://blog.csdn.net/u010186001/article/details/48895977
方法二.Watchpoints for Stellaris in CCS
步骤:
1、现将程序编译并Debug下载到开发板。然后点击Window->ShowView->Breakpoints
然后在右上角(默认设置)窗口中会多出一个断点窗口(默认有这个窗口可以跳过第一步)
2、点击断点下拉框选择CountEvent
弹出提示框后选择Clock Cycles,然后点击OK
3、经过第二部后在读断点窗口中会多出一个Count Event断点,在Count Event上鼠标点击右键选择Breakpoint Properties对此断点进行配置。
将Reset Count on Run改为true,点击OK保存。
4、将要测试的代码代码加上断点,如图,假如我要测试程序从1到2需要运行对少时间,则将1所在的行设置断点同时把2设置断点,此时可以看到断点窗口多了两个断点。(注:此时Count Event显示67941表示程序运行到main函数是已经运行了67941个时钟周期(启动代码消耗),刚加进来Count Event是的计数值很大,那个值不准,重新Debug程序到开发板时因为之前已经添加了Count Event,所以计数是准的)
5、单击运行按钮当程序运行到第一个断点时Count Event数值变为93210,说明从main函数运行到这一代码之前一条代码(断点处代码在程序暂停时还没有运行)用了93210个时钟周期,这个始终中期不包括之前启动代码运行消耗的67941个时钟周期,因为之前设置了Reset Count on Run为True,所以每一次点击运行按钮这个值都会清零。
在此点击运行按钮,当程序运行到2处时自动暂停运行,此时看到count event 变为了229938,说明程序从1运行到2用了229938个时钟周期。
6、运行时间计算
由第5步知道从代码1到代码2用了229938个机器中期,假如我设置时钟频率为40Mhz,那这段代码运行时间就是229938 * (1/(40*1000000)=0.00574845,约为5.75MS。
我在网上也看到了其他方法。
使用clock功能,这种方法操作比较简单,比较实用。
使用方法是,先打开clock功能,步骤是Run-> clock -> Enable。
右下角有个时钟的图标出现。这里写图片描述 双击它可以清零。
在要测试的代码上打两个断点,分别运行到两个断点处,就可以看到代码运行周期了。
使用公式 time = 1/CLK可以算得程序运行时间。
例如时钟周期为300MHz,测得数据为1000,则代码运行时间time = 1000 * (1/300,000,000) = 3.3 μs。
图例:
程序从InitSysCtrl()到InitPieCtrl()这段时间花费的Clock Cycle如下图所示。
在仿真器状态下的运行时间要大大慢于独立运行的时间。而且在RAM和FLASH中运行机器周期也有所不同。
有人做了实验:
CCSV5里面的 clock是不是不够精确?我编了一个程序:
for(frequency=1000;frequency<100000;frequency++) .................1
{ Calculate_Control_Word(frequency); ...................2
if(frequency==99999) ..................3
{frequency=1000;}
}
我编译完下载到28335的RAM中去后,enable 了clock。发现:
从程序1到程序2,要12个机器周期;
从程序2到程序3,要279个机器周期;
从程序3到程序1,要7个机器周期。
后来在这段程序没有变的情况下,又把.out文件重新下载到RAM中,发现
从程序1到程序2,要20个机器周期;
从程序2到程序3,要282个机器周期;
从程序3到程序1,要1200个机器周期。
请问这是怎么回事?这也相差太大了。每次重新加载后,有时正常,有时不正常。
个人觉得受到计算机内存指令调用方面的影响,运用timer,CCS程序里的CLOCK方式都不准确吧?唯独GPIO口输出切换程序是在DSP内部执行,不牵涉到计算机内存环境改变的问题,应该最准确,但是不是很方便。因为我观察EPWM的couter计算时也发现同样一个程序,每次执行完用的机器周期是不一样的。
用程序把timer里的值或EPWM里面couter的值显示出来,和用CCS里View的方式显示出来都应该一样。只要经过计算机读出,显示在CCS里面,就可能会不准确。最起码会出现不能保证每次加载后查看的机器数不尽相同。
TI对此给出的解释是:CCS中的Clock不准确,指的是程序在FLASH中运行的时候,可能涉及flash pipeline,或者在外部RAM中运行时碰到CPU stall。PWM outer和CPU timer的测试应该是最准确的。
既然软件并不可靠,那么,准确测量就需要脱离仿真器。
TI的技术支持提出:CCS里面的功能不是很准确,如果只是想确定一段代码的运行时间(绝对值),最准确也是最简单直接的方法是在前后加GPIO翻转,通过示波器量测。如果是想知道对应CPU时钟,则可以反汇编计算对应的指令周期数。
具体测量的方法如下:
1)测量子程序运行时间:在子程序运行开始,置一个引脚为高电平,退出子程序时为低电平;
2)测量主程序运行时间:每运行一次,在主程序循环程序开始处,将某引脚电平 反向。
用示波器测量引脚波形,可以知道程序运行的时间花费。
文章收集整理于网络,如有侵权,请联系小编删除