Click the above 
“Chuangxue Electronics” to follow easily and learn electronic knowledge.
The testing method is as follows:
The main loop continuously increments a variable (sum1++), ensuring no overflow.
Using the Systick counter of the Cortex-M3, with a limit of one second, the value of sum1 can determine which method is faster. To be precise, we observe the counting effect between the first second and the second second; instead of from the 0 second to 1 second (because there may be a gap between enabling Systick and actually executing sum1++). When entering the Systick ISR for the first time, record the value of sum1; when entering the Systick ISR for the second time, record sum1’s value again. The difference between the two values indicates how many times sum1 was incremented in the one-second interval. This shows which method is faster.
The same testing premise: Prefetch Buffer Enable + Flash Latency=”2″ (As required by the Flash Programming Manual, when 48MHz<SYSCLK<=72MHz, two wait states must be inserted for flash access).
The test results are as follows:
No code optimization, executing the program in RAM: sum1 counts 69467/sec.
No code optimization, executing the program in FLASH: sum1 counts 43274/sec (slower in Flash).
/*********** The loop body contains N or fewer blocks *************/
(1)LDR R0,[PC, #0x154]
(2)LDR R1,[PC, #0x154]
(3)LDR R1,[R1,#0]
(4)ADDS R1, R1,#0x1
(5)STR R1,[R0, #0]
……
/****************************************************/
With speed optimization turned on, executing the program in RAM: sum1 counts 98993/sec.
With speed optimization turned on, executing the program in FLASH: sum1 counts 115334/sec (faster in Flash).
/*********** The loop body contains N or fewer blocks *************/
(1)LDR R1,[R1,#4]
(2)ADDS R1, R1,#0x1
(3)STR R1,[R0, #0]
……
/****************************************************/
The conclusion is:
1) Whether the program runs faster in RAM or Flash is not absolute; it depends on the code;
2) In the above two specific code situations, I think without optimization, executing in Flash: (1)(2) fetching instructions (reading flash) -> decoding -> executing (reading flash); the target addresses for fetching and executing in flash are not continuous, hence non-sequential access, so it is slower;
When optimization is turned on, (1)(2)(3) do not cause non-sequential access in flash, so the advantages in flash (fetching instructions and data use different buses ICode and DCode, plus Prefetch) become evident.
Further analysis leads to the following conclusions:
Without optimization, when executing instructions, fetching constants from Flash causes interruptions in the instruction prefetch queue, and after fetching constants, the instruction prefetch queue needs to be refilled, and flash access requires inserting wait states, resulting in longer time.
After code optimization, executing instructions no longer requires fetching constants from Flash, the instruction prefetch queue is not interrupted, and the effect of inserting wait states for flash access is offset by the instruction fetching buffer mentioned in the post below, so the speed naturally increases; at this point, executing in RAM may actually be slower because RAM is not on the ICode bus, fetching instructions from RAM requires a detour, which is naturally slower than flash on the ICode bus.
For performance on Flash, please see my other analysis: [Analysis] Timing Analysis of Running Programs from Flash on STM32.
Additionally, the bus architecture of STR9 and STM32 is the same; here are some empirical data for an FFT function implemented on STR9, which further illustrates that running code in Flash can be faster than in RAM!
On ST’s website, there is a DSP function library, and its documentation “STR91x DSP library (DSPLIB)” has a section discussing the speed of FFT operations, which provides actual computation time comparisons, excerpted as follows:
Radix-4
Complex FFT Operation Mode Cycle Count Microseconds
64 Point Program in Flash & Data in SRAM 2701 28.135
64 Point Program & Data in SRAM 3432 35.75
64 Point Program in Flash 3705 38.594
256 Point Program in Flash & Data in SRAM 13740 143.125
256 Point Program in SRAM 18079 188.323
256 Point Program in Flash 19908 207.375
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
==> Visit www.eeskill.com to learn more!