For embedded systems, timing is often a very important aspect. In event based architectures, timers are used for example to perform periodic tasks, delay operations and handle timeouts. The DATAFLOW Runtime implements software timers, that can be used for such tasks. In addition, MCUs also provide hardware timers that can be used.

Software Timers

Software timers are implemented by the runtime. The timers are registered in a data structure and are updated with every SYSTICK interrupt. The frequency of this interrupt therefore also defines the resolution of all software timers. In most cases, the SYSTICK interrupt is configured to be triggered every millisecond, which is then also the smallest possible timer that can be used.

Software Timer Types

The runtime provides 3 types of timers that can be added to active parts:

• Periodic Timer
• One Shot Timer
• Variable Timer

Periodic Timer

This timer generates a timer event to be handled by the active part whenever the defined number of ticks have been passed. This event is generated until the timer is stopped. The number of ticks is defined in the diagram and generated as a constant inside the active part.

One Shot Timer

This timer runs for the defined number of ticks and generates a single timer event to be handled by the active part. Then the timer is disabled again and needs to be started again. The number of ticks is defined in the diagram and generated as a constant inside the active part. It is possible to enable autostart, which will start this timer in the start() method of the active part,

Variable Timer

A variable timer works like a one shot timer explained above. The only difference is, that the duration of the timer must be passed when the timer is started and can be different for each start. Therfore the timer length is not visible in the diagram (software architecture) but only in the code. Use this timer when implementing a complex protocol with many different timeout requirements to avoid defining a large number of one shot timers. In other cases, the one shot timer should be used instead.

Software Timer Priority

A software timer is always connected to the SYSTICK interrupt priority and the priority of the active part that receives the timer event. The SYSTICK normally has the lowest IRQ priority. This means, that handling of software timer events will be delayed by any other interrupt. In addition, any active part with a higher priority will also delay the handling of the timer events of any lower priority active part.

Software Timer Limitations

The resolution of software timers is always linked to the SYSTICK which is normally 1 millisecond. A periodic timer can therefore not exceed a frequencey of 1 kHZ. For one shot / variable timer a period of 0 can be passed. This will handle the timer event as soon as possible, but may be delayed by higher priority events (see above).

Jitter

A periodic timer event that is delayed by another event will be handled at a later time than expected. The next event will be triggered in relation to the original expected time. This may lead to the problem, that the time between two timer events is shorter than the period.

The following example shows a watchdog trigger signal that was toggled using a periodic timers and a one shot timer for the pulse length. The timer was expected to generate an event all 24ms. In some cases, the next pulse was already after 23ms.

To avoid this, a one shot timer can be used. The timer is then re-started in the event handler. This ensures, that the time between events is always the defined period or longer, never less. The drawback is, that the events will shift over time because of the delay until the timer is started again.

Resolution

One shot timers use the SYSTICK interval as resolution. The timer event is generated by the runtime when the tick counter reached the value for the next event (start + duration). This is checked in the SYSTICK IRQ handler. It is possible, that the start of a timer and the IRQ overlap, which means that the tick is incremented. The length of the timer is than 1 tick shorter than expected (but never more than 1 tick).

The following example shows a 1ms pulse that is generated by starting a one shot timer to pull the output low after a 1ms delay. If the SYSTICK IRQ happens directly after start timer, the timer event is scheduled immediately, which will create a shorter pulse.

To ensure a minimal tick length, the length must be set to N+1. This will ensure that it is never less than N.

Hardware Timer

Hardware timers are independent from the SYSTICK interrupt and may provide better timer resolution and accuracy as the software timers. In addition, these timers are independent from the software and could even keep running in power safe mode or when the device is powered down (mostly handled by the real time clock).

Hardware Timer Priority

The priority of the timer event depends on the priority of the timer interrupt. This must be configured above the PendSV and SYSTICK IRQ and below the NMI IRQ. Using different priorities can help in defining which timer (or other peripheral) must be handled first when the occur at the same time.

Best Practices

When working with timers, the following should be considered:

• Timers are updated at each SYSTICK. This means, a timer can be 1 tick shorter than expected.
• Periodic timers keep the correct period over a long time but may get single events delayed which will cause a shorter time between two events than expected.
• One shot timer will never be shorter than period - 1 tick, but using a one short timer for a periodic task will add the delay for the handling the event and for re-starting the timer on each period, slowly shifting the timer.
• Use hardware timers for precise timing with a resolution of <= 1 tick.