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 <j...@rtems.org> wrote: > On Tue, Aug 20, 2019 at 7:50 AM Catalin Demergian <demerg...@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@rtems.org > > http://lists.rtems.org/mailman/listinfo/users >
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
