move code from interrupt context to task context

[Catalin Demergian]

Hi,
I did implement this with Rate Monotonic Manager.
I followed
https://docs.rtems.org/releases/rtems-docs-4.11.3/c-user/rate_monotonic_manager.html#simple-periodic-task
(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
application.

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 ?)

regards,
Catalin



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

> On Tue, Aug 20, 2019 at 7:50 AM Catalin Demergian <demergian at gmail.com>
> 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 rtems.org
> > http://lists.rtems.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20190904/cc849f03/attachment.html>