# How do I know if my microcontroller clock frequency is fast enough?

I've been using ARM microcontrollers from NXP in commercial products with great success for the last 2 years.

In most of my projects I don't use the PLL to increase the oscillator frequency because I never found it was needed (never felt that clock frequency was an issue), and because the PLL slightly increases power consumption.

However I don't know how can I measure what clock frequency is enough to power my code. I'm stuck with this question in my head because as you may know the faster the clock you use, the more power you end up consuming. Since these days portable equipment with limited batteries are common this is an important topic.

The main question here is how can I know if the current clock frequency is enough for my code?

In this question I state "stopping or delays" because I assume that if my clock frequency isn't enough the first symptom that will happen is a slow response time from time consuming routines.

I use in almost my projects a state machine system that has an OnIdle() function that is called when the system doesn't have any events to process, so it can put the MCU in a low power mode. I was thinking about measuring how much time the system stays in this function and record min and max watermarks of this measure to have real numbers about if the current system clock is or isn't enough.

Does anyone have suggestions for this?

• I second what Eugene suggests. Looking at the scope picture while 'playing' with your gadget can learn you a lot about cPU use. In addition, you should realize that it is sometimes better to run at a higher frequency when work is to be done, to make this run time a smaller percentage of the overall time. Whether this is worthwhile depends. Especially on the other power consuming factors (beside the CPU) in your chip & system. – Wouter van Ooijen Nov 4 '15 at 18:18

In case it is difficult or impossible to estimate the required frequency theoretically (based on calculations and the knowledge of the microarchitecture) or based on experience (similar code on similar machine), the empirical approach can be taken. A common technique to write an embedded real time application is by having the main loop to be fixed time long. Than your main loop will look something like that:

while (true)
{
doStuff();
waitSync();
}


waitSync here is driven by some kind of timer interrupt. By adding an indicator like GPIO pin output like this:

while (true)
{
gpioOn();
doStuff();
gpioOff();
waitSync();
}


and placing a scope probe on that GPIO you will get a nice pulse train, whose duty cycle will indicate the percentage of the CPU time, when it is actually "doing stuff".

• The timer / counter module on many microcontrollers can be used for code profiling too. This is useful where you have no external tools and a predictable time step inside the uC timers. – David Nov 4 '15 at 20:07

You're thinking about this backward. The question isn't "how can I know if my code running with its current clock is enough?", it's "how to I design my code such that I know if it's running correctly?

Microcontrollers are somewhat opaque. They're a hard platform to debug on. You need to develop the habit of splitting the code up into testable chunks, using techniques such as bit toggling to test each chunk, and then test the entire system. Building in the tests should become part of your though process, and starts before you write any code

There are different ways to run out of time with microcontroller code. You may run out of total bandwidth, in which case you've definitely got to change something (better algorithms, higher clock frequency, maybe a better architecture).

Before that happens, you may get more subtle effects such as excessive jitter in interrupt service routines or servicing of low-priority events such as the user interface.

It's usually desirable to have a fair bit of margin in total bandwidth- running out of speed (or memory) is not much fun unless you have a clear upgrade path (such as crank the clock speed up or drop in a more expensive micro that is upward compatible).

You can profile code in simulation or by toggling a GPIO pin as Eugene suggests, however note that in micros such as the ARM the GPIO is decoupled from the micro core by a relatively slow bus, so the profiling should be done on relatively chunky time slices.

You should also look at the specifications (and perhaps test) to see what the trade-offs are with clock speed and the typically numerous operating modes of the micro. If you're just idling in wait loops and not doing any power control, part of the supply current will be proportional to frequency (to a first order). However, if you're waking up, doing some stuff, then going to sleep, the effect of higher clock frequency may not be so significant (could even be an improvement), since the duty cycle will be less and perhaps some peripherals can be put into a low-power mode for longer at the higher clock frequency.