app timer and scheduler issues and enhancements

[Phil Young]

I'm trying to make my code now interface to the SDK only through the API, but at the moment this does not suit my requirements.

In particular I have issues with the implementation of the app timer / app scheduler

If I understand the operation correctly, there is a single app timer instance which reserves RTC1 and a single app scheduler instance,

when using the timer with the scheduler each time a timer expires the app timer handler will add an event into the scheduler and the main application thread will periodically call the schedulers app_sched_execute function which in turn will call timeout_handler_scheduled_exec to execute the corresponding timeout handler function.

The problem for me is that this mechanism does not provide for any prioritization of events generated by the timer over any events added by the applications main thread since the scheduler offers no prioritization mechanism, it seems to be just a queue operating in a FiFo manner.

Additionally, any call to app_sched_execute will execute ALL scheduled events before returning which means that there can be long delays before returning
to the application.

This is unsuitable for many applications and could be improved in many ways, e.g.
1. Adding priority levels to the queue
2. Encapsulating all scheduler data in an object so that multiple schedulers could be implemented based on priorities.
3. Providing a modified version of app_sched_execute which limits the number of scheduled events that it will execute before returning

For now I have to add my own scheduler ( written in C++ so much easier to use ) for priority management of my asynchronous events and replace app_sched_execute with modified version that executes a single event for the timer events.

This is far from ideal since it means that I am writing code that is interfering directly with the variables used by the mesh SDK rather than using the API, and must therefore modify / verify this code every time the SDK is revised, I also have to call 2 asynchronous scheduler functions at the moment instead of a single function.

[Kenneth]

Hi,

As you have already identified, the scheduler in the nRF5 SDK is very simple, there is no priority, just a simple fifo queue. The only thing I can say is that there will be changes coming that will address your input.

Best regards,
Kenneth

[Phil Young]

What might be a useful implementation is to allow a timer object to contain a pointer to a scheduler, and to define a structure for a scheduler so that multiple schedulers can be instantiated.

Then when a timer expires the timer could schedule the asynchronous callback on a scheduler specified by the user allowing for flexibility in scheduling, for example I would then define schedulers for fast events and events that might take some time to execute, or simply assign schedulers to different priorities.

my system currently uses a co-operative scheduling system to avoid using an RTOS and this is effectively what I do using a scheduler class, but in order to use the system timer I have to use a second callback that acts as a proxy and re-schedules events from the app_scheduler to different schedulers so that low priority events can be deferred.

It works but it's not as clean as it could be with the above suggestion.