move code from interrupt context to task context

Catalin Demergian demergian at
Wed Sep 4 13:08:16 UTC 2019

I did implement this with Rate Monotonic Manager.
I followed
(section 11.3.7, Simple Periodic Task)

This made my tests to pass, but then I wondered if there is any clock drift
What I mean is this: what is the interval between the 16msec HW timer I use
fires and the moment my monotonic task (also set to 16 msec) enters ?
I'm sure it will be an interval of some usecs, but I want it constant. If
this interval keeps growing, we have clock drift.
I made a patch to measure it and .. there is a clock drift of 20usec at
every 8 seconds !! this keeps on adding, so it's not acceptable for my

A few questions..
1. how reliable is RMM ? is there a precision to it ?
2. any reason why RMM would introduce clock drift ?
3. any other solution I can use to have a precise, clock-dirft-free
periodic task to execute ?
maybe keep a HW ISR and resume my task from there with rtems_task_resume
(can rtems_task_resume be used in ISR ?)


On Tue, Aug 20, 2019 at 4:27 PM Joel Sherrill <joel at> wrote:

> On Tue, Aug 20, 2019 at 7:50 AM Catalin Demergian <demergian at>
> wrote:
> >
> > Hello,
> > The context is RTEMS-4.11.3 on STM32H7.
> > I have a timer interrupt routine and I'm calling some functions from it.
> > I would like to write a RTEMS task (rtems_task_create API) and call those
> > functions from that thread instead of calling them from interrupt
> context.
> >
> > Of course, I have to call them periodically (say at 1 msec or a few
> msecs).
> > Any guidance how can I achieve that ?
> There is rtems_timer_server_fire_after which moves the timer service
> routine
> to a task. You could also create a task and use a period to achieve the
> same
> end effect. Under the hood, the overhead for both should be similar but you
> will get statistics by using a period inside a thread of your own
> construction.
> See Rate Monotonic Manager in the Classic API Guide.
> One general issue is ensuring your clock tick quantum is small enough that
> the math for your period works out evenly. But if the clock tick quantum
> is to
> small, then it can introduce excessive overhead.
> >
> > I was thinking about registering a callback that the OS should call for
> me a few msecs
> > later, but isn't that the same thing ? I guess the OS finds when the
> time elapsed with
> > the help of the HW and calls my callback from an ISR .. am I right ?
> > Or if I call some wait functions in my loop and sleep for a few msesc,
> can I be sure
> > that it sleeps 3 mesc instead of a little more based on other existing
> tasks ?
> > So, how can I do this with a good precision?
> Sleep/delay/wake_after will eventually skew. You want a high priority task
> using a rate monotonic period. And a clock tick quantum which is an even
> divisor for that. Hopefully the clock tick quantum is a divisor for all the
> periods in your application.
> --joel
> >
> > regards,
> > Catalin
> >
> > _______________________________________________
> > users mailing list
> > users at
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list