Scheduling future interrupts with a specific delay

[rushikeshsheth]

Posted on July 09, 2015 at 01:12

I'm trying to schedule a single interrupt in the future with a specific delay on the STM32F407, and I'd like to figure out the best way of doing this. I've played around with periodically waking up a task and generating PWMs with the timers, but now I'd like to specify an aperiodic interrupt in the future. I looked into the One Pulse Mode for the timers, but it seems that requires an initial external trigger. 

I'm sure there's an elegant & simple way to do this - it seems like a fairly straightforward timer use case. Could someone point me in the right direction?

Thanks!

#stm32f4 #interrupts #timers

[Danish1]

Posted on July 10, 2015 at 19:05

''Best'' depends very much on a number of things:

What sort of delay you are after (microseconds, seconds, hours, days).

The acceptable error in delay (must it interrupt at precisely 15.000036 seconds from now, or is 15.000040 acceptable)

How many simultaneous delays you will be running.

If you want an interrupt at a specific time, then the RTClock's alarm seems like a good choice (there are two of them).

If you have a spare timer and only need 16-bit accuracy, then you can set its prescaler to give the desired range, preload the timer with the desired number of counts and wait for it to hit zero. And you can chain two timers to get 32-bit accuracy.

You don't need a specific ''one pulse'' mode. Just stop the timer as part of its interrupt-service-routine.

Hope this helps,

Danish

[jpeacock]

Posted on July 10, 2015 at 22:35

A more general way to solve this problem is a timer service and a message queue.  The timer service runs in the background and schedules itself to wakeup for the next time event or if an incoming message arrives. 

The message queue is a request to signal an event at a point in time, within the resolution of the timer service.  Internally the timer service has an ordered list of pending time events in ascending order.  As each event fires and is removed the service computes the remaining time to the next event.

When the service processes incoming messages it has to recalculate the remaining time to the next scheduled event.

This works for both one-shot and periodic timers.  One-shot events are removed, periodic events are rescheduled after being triggered.  The service signals an event with a callback or an event flag.

You might look at how the timer service APIs work in FreeRTOS.

If you know the events are one-shots and always arrive in ascending order the service is very simple.  Read a message from the queue, delay to the event, signal the event, and then repeat for the next queue item.  The service stalls while the queue is empty.

If you don't have an RTOS then use a timer interrupt for the timer service task.

  Jack Peacock