Prerequisites

This is the second entry in a series on Dynamic Tick Mode for µC/OS-III V3.07 and above. If you have not done so, please read the first part “Dynamic Tick on µC/OS-III - Part 1: Getting Started”. This document assumes that the reader is familiar with the concepts described in Part 1.

Overview

Part 1 of this series demonstrated a fully functional Dynamic Tick BSP running on a Silabs EFM32GG11. You may recall that the BSP made use of a 32-bit timer, which is recommended for most applications. However, µC/OS-III makes no assumptions regarding the size of the hardware timer. For those cases where a spare 32-bit timer is not available, a smaller timer can be used. 

Regardless of the timer size, a sub-optimal configuration of the timer will reduce the number of ticks that it can count before overflowing. The resulting interrupt may bring our system out of low-power mode prematurely with nothing to run. Optimizing your configuration increases the length of time that the system can remain idle. This is especially important when using smaller timers.

Concepts

Timer-Tick Ratio (TTR)

The Timer-Tick Ratio is so defined:

For a given delay in OS Ticks, R lets us calculate the equivalent number of timer counts at frequency F. OS timing calculations are handled purely by integer arithmetic, so we must ensure the additional requirement on F is followed in our code; otherwise, the hardware delays will be longer or shorter than what we expect from the given tick rate.

Converting from OS ticks to timer counts is done as follows:

Example 1

Assume a timer frequency of 20 kHz and a Tick Rate of 100 Hz.

Note that it requires 200 timer counts to delay for 1 OS Tick. A 16-bit timer can delay for  before overflowing.

Example 2

Assume a timer frequency of 200 kHz and a Tick Rate of 100 Hz.

Note that it requires 2000 timer counts to delay for 1 OS Tick.A 16-bit timer can delay for  before overflowing.

TTR Minimization

From the previous examples, it should be clear that a larger ratio will increase the number of timer counts required to delay for the specified number of ticks. It stands to reason that we should aim for the smallest ratio possible to increase the maximum number of ticks that our timer can support; a ratio of 1 would be the ideal case.

Mathematically, we must either decrease F or increase T to achieve the desired result. However, while increasing the tick rate may increase the number of ticks that our timer can handle, each tick period is reduced by the same factor so the maximum possible delay is unchanged. This leaves us with the second option of reducing the timer frequency.

There is also the third option of changing both the Frequency and the Tick rate. Example 4 demonstrates this, but we will avoid discussing it in detail as it adds another element of complexity. This topic may be covered more in a later app note, but for now the tick rate is assumed to be constant.

Example 3

Our Silabs EFM32GG11 uses WTIMER0 as the dynamic tick source. Its input clock is . This limits our choice of input frequency to those listed below.

We can immediately eliminate any frequency with a fractional component (Rows 8-10): since the product of two integers can never contain a fractional component, we know that these options cannot be integer multiples of any tick rate we choose. The remaining options are all suitable, provided our tick rate is appropriate. Since a tick rate of 1000 is the usual choice for our example projects, it is the constraint we chose for our example on the EFM32GG11. With that constraint, we can eliminate Rows 5-7 because they fail to satisfy the integer multiple requirement (the fractional TTR is indicative of this).

By process of elimination, we have reduced our choices to Rows 0-4. Any choice satisfies our requirements, but we still want to optimize our configuration. Using TTR minimization, we know that the smallest R is what we want. Row 4 is therefore chosen as the optimal configuration for a tick rate of 1 kHz. This explains why, in Part 1, 3.125 MHz was chosen for the timer frequency; it was not an arbitrary choice, but one that was optimized to work within a set of constraints.

For the sake of comparison, let us see how one second of idle time would be represented in hardware.

Example 4

What if we relax the requirement on our Tick rate? Perhaps we don’t need millisecond precision for our delays and timeouts and would rather take advantage of a longer system idle time. Let’s see how our process works with a 10 Hz tick rate.

Following the same steps as before, we can see that more frequencies are available for us to use. However, notice that our best R is much larger than the one from before. Lowering our tick rate has, in fact, given us a worse TTR. Despite this, we can still idle for longer than before; keep in mind that each tick represents a longer period of time. The period of each tick has increased by a factor of 100 whereas our TTR has increased by a factor of 25. This may or may not be the case depending on the frequencies available; it is possible to decrease the tick rate and end up with a shorter max idle time give the right frequency values.

Let’s compare with the results from Example 3.

It takes fewer timer counts to represent the same amount of time even though our TTR is larger than Example 3. This is a direct consequence of changing the tick rate. The TTR is not a quantity independent of unit; therefore, a TTR with T = 1 kHz is not immediately comparable to a TTR with T = 10 Hz since the definition of the Tick unit has changed.

Conclusion

We’ve delved into more theory than in Part 1, but did so in the hopes that it will be put to practical use.The goal was to demonstrate how hardware timers should be optimized for Dynamic Tick Mode. We tried to avoid discussing topics which could derail the main thrust of this app note, but we acknowledge that such topics exist and might be covered by other entries in this series.In summary, our recommendation is to choose a tick rate based on the application requirements and then apply TTR minimization by adjusting the timer frequency. We believe that this will cover the majority of use cases.