move code from interrupt context to task context

[Joel Sherrill]

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