Very simple case for analysis
Hi
To simplify the analysis, I have now concentrated on a single anomaly that is highlighted by simply using the exact same source code except for the iterations parameter which assumes different values (100, ... 10 000 000).
Here I have collected the different suggestions given to me by @Community member, @TDK and @KiptonM.
- Interrupt are disabled (__disable_irq(); in line 13).
- DWT->CYCCNT was used instead of the oscilloscope.
- All tests now use a single function
- Disassembly is now available (ATTACH_FILE_#2 list files $1.lst about test case 3 and $2.lst about test case 4)
Follow the code for test case 3 (iterations = 10000).
#include "stm32f767xx.h"
const uint32_t iterations = 10000UL;
volatile uint32_t total_for_watch = 0;
void test_function (uint32_t iterations);
int main (void)
{
uint32_t start = 0;
uint32_t finish = 0;
__disable_irq();
for (;;)
{
start = DWT->CYCCNT;
test_function(iterations);
finish= DWT->CYCCNT;
total_for_watch = finish - start;
}
return 0;
}
void test_function (uint32_t iterations)
{
uint32_t cnt = 0;
/* Dummy code */
while (cnt < iterations)
{
cnt++;
}
}A summary of the results follows
All tests are with Compiler ARM V5 (in Keil uVision 5.36) without optimizations in C99 mode.
Note. In other tests not documented here I have seen that the total_for_watch values are consistent with time measurements obtained using digital output
toggles and oscilloscope. I therefore believe the total_for_watch values to be reliable.
Hi @Community member, @KiptonM, @TDK and @Community member
TDK is right. Test results follow
#include "stm32f767xx.h"
void test_function (uint32_t iterations);
uint32_t last_dwt_cyccnt, current_dwt_cyccnt;
/* Variable for watch */
volatile uint32_t computing_time_1, computing_time_2, computing_time_3,
computing_time_4, computing_time_5, computing_time_6;
int main (void)
{
__disable_irq();
for (;;)
{
last_dwt_cyccnt = DWT->CYCCNT;
test_function(100UL);
current_dwt_cyccnt = DWT->CYCCNT;
computing_time_1 = current_dwt_cyccnt - last_dwt_cyccnt;
last_dwt_cyccnt = current_dwt_cyccnt;
test_function(1000UL);
current_dwt_cyccnt = DWT->CYCCNT;
computing_time_2 = current_dwt_cyccnt - last_dwt_cyccnt;
last_dwt_cyccnt = current_dwt_cyccnt;
test_function(10000UL);
current_dwt_cyccnt = DWT->CYCCNT;
computing_time_3 = current_dwt_cyccnt - last_dwt_cyccnt;
last_dwt_cyccnt = current_dwt_cyccnt;
test_function(100000UL);
current_dwt_cyccnt = DWT->CYCCNT;
computing_time_4 = current_dwt_cyccnt - last_dwt_cyccnt;
last_dwt_cyccnt = current_dwt_cyccnt;
test_function(1000000UL);
current_dwt_cyccnt = DWT->CYCCNT;
computing_time_5 = current_dwt_cyccnt - last_dwt_cyccnt;
last_dwt_cyccnt = current_dwt_cyccnt;
test_function(10000000UL);
current_dwt_cyccnt = DWT->CYCCNT;
computing_time_6 = current_dwt_cyccnt - last_dwt_cyccnt;
}
return 0;
}
void test_function (uint32_t iterations)
{
volatile uint32_t cnt = 0;
/* Dummy code */
while (cnt < iterations)
{
cnt++;
}
}But my original problem was that it seemed strange to me (and therefore I thought I had made some mistakes) that very small changes in the code could result in very large changes in the runtime. For example, consider the following code, which I call %2.
#include "stm32f767xx.h"
void test_function (uint32_t iterations);
uint32_t last_dwt_cyccnt, current_dwt_cyccnt;
/* Variable for watch */
volatile uint32_t computing_time_1, computing_time_2, computing_time_3;
volatile uint32_t computing_time_4, computing_time_5, computing_time_6;
int main (void)
{
volatile uint32_t system_core_clock_for_watch = SystemCoreClock; // @1
__disable_irq();
for (;;)
{
last_dwt_cyccnt = DWT->CYCCNT;
test_function(1000000UL);
current_dwt_cyccnt = DWT->CYCCNT;
computing_time_5 = current_dwt_cyccnt - last_dwt_cyccnt;
last_dwt_cyccnt = current_dwt_cyccnt;
}
return 0;
}
void test_function (uint32_t iterations)
{
volatile uint32_t cnt = 0;
/* Dummy code */
while (cnt < iterations)
{
cnt++;
}
}Then consider the following code, which I call %3.
The only difference is that in% 3 the line 14
volatile uint32_t system_core_clock_for_watch = SystemCoreClock; // @1
present in% 2 has been deleted.
#include "stm32f767xx.h"
void test_function (uint32_t iterations);
uint32_t last_dwt_cyccnt, current_dwt_cyccnt;
/* Variable for watch */
volatile uint32_t computing_time_1, computing_time_2, computing_time_3;
volatile uint32_t computing_time_4, computing_time_5, computing_time_6;
int main (void)
{
//volatile uint32_t system_core_clock_for_watch = SystemCoreClock; // @1
__disable_irq();
for (;;)
{
last_dwt_cyccnt = DWT->CYCCNT;
test_function(1000000UL);
current_dwt_cyccnt = DWT->CYCCNT;
computing_time_5 = current_dwt_cyccnt - last_dwt_cyccnt;
last_dwt_cyccnt = current_dwt_cyccnt;
}
return 0;
}
void test_function (uint32_t iterations)
{
volatile uint32_t cnt = 0;
/* Dummy code */
while (cnt < iterations)
{
cnt++;
}
}!!! computing_time_5 went from 5 444 543 cycles to 15 000 038 cycles (3 x).
See ATTACH_FILE_#3 list files %2.lst about code %2 and ATTACH_FILE_#3 list files %3.lst about code %3 (ARM compiler V5, C99, optimization level 0 (-O0)).
I also found similar behaviors also making other very small changes in the code other than the one now shown or with the ARM 6 compiler.
I am new with ARM. My previous experiences are related to Microchip's simple dsPIC MCUs or Motorola's older 68000 CPUs but I have never experienced such a high sensitivity of execution times towards the code.
Am I the only one who finds this behavior "strange" or for you who move in the ARM world with more experience than me is this behavior normal ?
