ROSSIER Daniel wrote:
> >-----Original Message-----
> >From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> >On Behalf Of MEYLAN Jean-philippe
> >Sent: mercredi 31 octobre 2007 11:46
> >To: [email protected]
> >Subject: [Xenomai-help] task rate control with alarm and semaphore
> >
> >Hello,
> >
> >I'm working on the creation of a Xenomai target for Mathwork's
> >Real Time Workshop. In order to achieve this, I would like to
> >control the execution rate of a task with a semaphore periodically
> >released by an alarm handler. The tasks does nothing else but waiting
> >(in a loop) on the semaphore. If the task can immediately take
> >the sempahore, it means that the rate is too fast for it because
> >the semaphore has been released before the end of its current
> iteration.
> >
> >My problem is that I cannot decrease the alarm period under 40us
> >without facing this situation. I cannot figure what is the cause of
> >all that overhead (maybe it comes from the rt_alarm_wait call ?). I
> >have tried to use event flags instead of semaphores but I get the
> >same results.
> >
> >Do you have any idea ?
> >
> >Here is the code of the main task and the alarm handler:
> >
> >void tBaseRate(void * cookie)
> >{
> > while (1) {
> > if (rt_sem_p(&rtClockSem, TM_NONBLOCK) == 0) {
> > printf("Rate for BaseRate task too fast.\n");
> > } else {
> > rt_sem_p(&rtClockSem, TM_INFINITE);
> > }
> >}
> >
> >void clockHandler(void * cookie)
> >{
> > int status;
> > while (1) {
> > status = rt_alarm_wait(&clockDesc);
> > if (!status) {
> > status = rt_sem_v(&rtClockSem);
> > if (status)
> > printf ("Semaphore error : %d\n", status);
> > } else
> > printf ("Alarm error: %d\n", status);
> > }
> >}
>
> This example is very interesting. To make sense, the semaphore must be
> initialized to 0 so that
> the first invokation to rt_sem_p() in tBaseRate will suspend the task.
> But if the message
> "Rate for BaseRate task too fast" is displayed the next loop, it means
> that the time elapsed between
> the alarm and the next rt_sem_p() is more than 40us. Weird. Having a IRQ
> latency of about 5us, it means
> that the nucleus spend 35us to handle the switch between the alarm and
> the task itself.
The interrupt latency is one thing, here you have two context switches
after the interrupt, which basically means that the latency is at least
twice the _scheduling_ latency.
--
Gilles Chanteperdrix.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
