app_scheduler / app_timer

[Dave]

Is there some documentation somewhere to explain how these work?

I kinda understand but in app_timer, why use a software interrupt of the same priority as the RTC interrupt? Why not just call timer_list_handler() ?

If its to minimize time in the interrupt handler, surely checking for timeouts timer_timeouts_check() and updating the list should all be done in the software interrupt handler with the swi being called from the RTC interrupt (so it can finish).

Or maybe Im completely missing the point? ;)

[Ole Morten]

Unfortunately, there isn't currently a lot of documentation on these modules, but this is something that will hopefully be improved in future SDK releases.

However, I can try to fill in a little details.

app_timer This module can be used to have an unlimited (limited by APP_TIMER_MAX_TIMERS) software timers, each with their separate callback and configurable timeout, but with using only one hardware RTC timer. This is a very useful module to create an event-driven application with no other content in the main loop than a sleep (and optionally a scheduler processing call).

Internally it is built with an operation queue, which is added to in the caller's context. When the operation have added however, a software interrupt is triggered and the caller method returns. The software interrupt reads out the operation and performs it. This software interrupt runs with the same priority as the RTC interrupt, to make sure that such operation is never interrupted by the RTC interrupt, since doing would potentially cause big problems. The interrupt structure is hence a way to ensure the integrity of the internal data structures at all times.

app_scheduler The primary function of app_scheduler is to move any processing out of interrupt handlers and into the main loop. This ensures that all interrupt handlers are short, and that all interrupts are processed as quick as possible. For some applications, this is very beneficial.

Since the scheduler causes things to run in main context, you can also avoid some problems concerning the sizing of the operation queue for the timer. See this question for details on this.

[Chris]

Does the app_timer handler run in the "main context"? If I want to use TWI triggered by an app_timer timeout, should I use the app_schedule to move that into the main loop or is it ok to execute the TWI calls in the timeout hander?

[Ole Morten]

What context an app_timer timeout handler runs in depends on whether or not you've told app_timer to use the scheduler.

If the last parameter of app_timer_init is true, all timer events will be passed through the scheduler, in which case all timeout handlers will run in main context.

If that last parameter is false, all timeout handlers will be run directly from RTC1_IRQHandler, which by default is APP_IRQ_PRIORITY_LOW.

It is also possible to have app_timer not use the scheduler by default, and only move events that you want to handle in main through the scheduler by using app_sched_event_put().

[Bastiaan]

How is sized OP_QUEUES_SIZE in APP_TIMER_INIT Would it be possible to have an example of how to blink the two EK LEDs with different timing using app_timer?

Thank you.

[Guest]

How is sized OP_QUEUES_SIZE in APP_TIMER_INIT Would it be possible to have an example of how to blink the two EK LEDs with different timing using app_timer?

Thank you.