Calculate MCU load (or free) time during operation

I have a Cortex M0+ chip (STM32 brand) and I want to calculate the load (or free) time. The M0+ doesn't have the DWT->SYSCNT register, so using that isn't an option.

Here's my idea:

Using a scheduler I have, I take a counter and increment it by 1 in my idle loop.

uint32_t counter = 0;

while(1){
    sched_run();
}

sched_run(){
    if( Jobs_timer_ready(jobs) ){
        // do timed jobs
    }else{
        sched_idle();
    }
}

sched_idle(){
    counter += 1;
}

I have jobs running on a 50us timer, so I can collect the count every 100ms accurately. With a 64mhz chip, that would give me 64000000 instructions/sec or 64 instructions/usec.

If I take the number of instructions the counter uses and remove that from the total instructions per 100ms, I should have a concept of my load time (or free time). I'm slow at math, but that should be 6,400,000 instructions per 100ms. I haven't actually looked at the instructions that would take but lets be generous and say it takes 7 instructions to increment the counter, just to illustrate the process.

So, let's say the counter variable has ended up with 12,475 after 100ms. Our formula should be [CPU Free %] = Free Time/Max Time = COUNT*COUNT_INSTRUC/MAX_INSTRUC.

This comes out to 12475 * 7/6,400,000 = 87,325/6,400,00 = 0.013644 (x 100) = 1.36% Free (and this is where my math looks very wrong).

My goal is to have a mostly-accurate load percentage that can be calculated in the field. Especially if I hand it off to someone else, or need to check how it's performing. I can't always reproduce field conditions on a bench.

My basic questions are this:

1. How do I determine load or free?
2. Can I calculate load/free like a task manager (overall)?
3. Do I need a scheduler for it or just a timer?

I would recommend to set up a timer to count in 1 us step (or whatever resolution you need). Then just read the counter value before and after the work to get the duration.

Given your simplified program, it looks like you just have a while loop and a flag which tells you when some work needs to be done. So you could do something like this:

uint32_t busy_time = 0;
uint32_t idle_time = 0;
uint32_t idle_start = 0;

while (1) {
    // Initialize the idle start timer.
    idle_start = TIM2->CNT;
    sched_run();
}

void sched_run()
{
    if (Jobs_timer_ready(jobs)) {
        // When the job starts, calculate the duration of the idle period.
        idle_time += TIM2->CNT - idle_start;

        // Measure the work duration.
        uint32_t job_started = TIM2->CNT;
        // do timed jobs
        busy_time += TIM2->CNT - job_start;

        // Restart idle period.
        idle_start = TIM2->CNT;
    }
}

The load percentage would be (busy_time / (busy_time + idle_time)) * 100.

Counting cycles isn't as easy as it seems. Reading variable from RAM, modifying it and writing it back has non-deterministic duration. RAM read is typically 2 cycles, but can be 3, depending on many things, including how congested AXIM-bus is (other MCU peripherals are also attached to it). Writing is a whole another story. There are bufferable writes, non-bufferable writes, etc etc. Also, there is caching, which changes things depending on where the executed code is, where the data it's modifying is, and cache policies for data and instructions. There is also an issue of what exactly your compiler generates. So this problem should be approached from a different angle.

I agree to @Armandas that the best solution is a hardware timer. You don't even have to set it up to a microsecond or anything (but you totally can). You can choose when to reset counter. Even if it runs at CPU clock or close to that, 32-bit overflow will take very long (but still must be handled; I would reset the timer counter when I make idle/busy calculation, seems like a reasonable moment to do that; if your program can actually overflow the timer at runtime, you need to come up with modified solution to account for it of course). Obviously, if your timer has 16-bit prescaler and counter, you will have to adjust for that. Microsecond tick seems like a reasonable compromise for your application after all.

Alternative things to consider: DTCM memory - small tightly coupled RAM - has actually strictly one cycle read/write access, it's by definition not cacheable and not bufferable. So with tightly coupled memory and tight control over what exactly instructions are being generated by compiler and executed by CPU, you can do something more deterministic with variable counter. However, if that code is ported to M7, there may be timing-related issues there because of M7's dual issue pipeline (if very simplified, it can execute 2 instructions in parallel at a time, more in Architecture Reference Manual). Just bear this in mind. It becomes a little more architecture dependent. It may or may not be an issue for you.

At the end of the day, I vote stick with hardware timer. Making it work with variable is a huge headache, and you really need to get down to architecture level to make it work properly, and even then there could always be something you forgot/didn't think about. Seems like massive overcomplication for the task at hand. Hardware timer is the boss.