EEPW论坛

flash是SST39VF160，90nS的，64M主频下，6cycles是93.75nS，可以满足要求，每次访问不到100nS。16bit接口，每条指令要两个存储器访问周期，不到200nS，所以说19条指令只需3.8uS.

6cycles不是core等待时间，而是总线接口等待时间，core等待时间不止6cycles，应该不了15cycles，即使达到15cycles，那也不用10uS啊。

还是想不明白。

注：计算flash代码量的时候已经将 ldr r0,=xxxx这样的伪指令按两条指令计算了，实际指令是17条。

我算了算，感觉差不多。

如果你只计算了总线接口时间，那么还遗漏了从内核到总线的时间。我也只是猜测，大概来回一趟要8个cycles左右。加上访问32bit数需要两倍的flash访问时间，那么一条指令共需要6*2+8=20个cycles。

所以，大约19条指令的取指时间是1/64M * 20 * 19 = 6us

另外，到目前为止计算的都是取指时间，离真正执行的时间还有很大区别。

1）比如所有LDR， STR指令，除了取指，还要读取存储器，加倍。

2）你说程序是大量的中断构成的。处理器要进行中断处理，要自动作大量工作，参考另外一个帖子

R14_ = Return Link
SPSR_= CPSR
CPSR[4:0] = Exception Mode Number
CPSR[5] = 0 ；当运行于 ARM 工作状态时
If == Reset or FIQ then；当响应 FIQ 异常时，禁止新的 FIQ 异常
CPSR[6] = 1
PSR[7] = 1
PC = Exception Vector Address

3）你处理中断是不是要保存现场，LDM/STM指令可不是6个总线Cycles能执行完的。

4）另外，我猜测出来的执行时间是通过中断和Timer得到的，误差也不小。

其实，使用Cache，将性能提高5~8倍，是很正常的。要考虑到通常Cache的命中率都会在90%

还是有疑问,我不明白的是flash被cache和禁止cache时为什么会相差10uS.因为相差的时间仅仅是从flash里取指的时间,而ldr和str指令操作的是sdram,不管flash是不是被cache,这个时间是固定的.我的程序很短小,只要被允许,不管是sdram还是flash,肯定会被cache命中.

至于内核到总线的时间,我倒是要研究一下,主观感觉上有些不合理,如果存储器比cpu慢,内核总是在饥饿状态,流水线应该是连续取指才对.

测量方法:启动定时器,进入用户中断程序时立即读出定时器当前计数值,与reload值之差即为中断发生到中断函数被执行的时间.44b0的手册上说,当定时器溢出时,申请中断并reload计数值继续计数,那么中断发生后,定时器是从reload值开始递减的,reload与当前值之差就是中断响应的时间.