Re: [Xenomai-core] Watchdog/Interrupt management

[Philippe Gerum <rpm@xenomai.org>]

ROSSIER Daniel wrote:
> Hi Philippe,
> 
> 
> 
>>-----Message d'origine-----
>>De : Philippe Gerum [mailto:rpm@xenomai.org]
>>Envoyé : mardi, 7. février 2006 14:45
>>À : ROSSIER Daniel
>>Cc : xenomai@xenomai.org
>>Objet : Re: [Xenomai-core] Watchdog/Interrupt management
>>
>>ROSSIER Daniel wrote:
>>
>>>Hi all,
>>>
>>>I've a - probably small ;-) - issue regarding the way how the watchdog
>>
>>and interrupt management are working together.
>>
>>>I'd like to implement a watchdog in a task to ensure that a task is well
>>
>>alive at periodic interval. For doing some tests, I've
>>
>>>implemented a small ISR which interceipts the keyboard interrupts (IRQ
>>
>>1). The ISR is simply doing some busy wait burning CPU time,
>>
>>>but with a delay greater than the task period.
>>>I assume that the ISR locks the rescheduling procedure as it is stated
>>
>>in the API doc (BTW; many thanks for having solved the doc issue).
>>
>>>So, the task switching is temporarly suspended and the watchdog should
>>
>>raise up an alarm after the ISR has been completed, right?
>>
>>>It doesn't.
>>
>>Because Adeos disables interrupts by default when calling an ISR from a
>>non-Linux
>>domain (like Xenomai's). You can re-enable them to get nested interrupts
>>by doing
>>this in your ISR:
>>
>>unsigned long flags;
>>
>>rthal_local_irq_sync(flags);
>><spin>
>>rthal_local_irq_restore(flags);
> 
> 
> Please, could you just provide me with a small explanation about what the rthal_local_irq_sync() function is doing? 
>

This unstalls Xeno's pipeline stage and re-enables hw interrupts in the same time 
when entering your ISR, then restores the original masking before returning to the 
nucleus.

> 
>>>I've attached the code below (I've removed the function return check for
>>
>>readibility reasons, but all objects are fine).
>>
>>>Another question:  the ISR is called on behalf of the interrupted stack
>>
>>context: does it mean that the ISR always runs in the stack context of the
>>highest priority task, i.e. the running task (assume no inversion
>>priority), or could it in some cases the kernel stack context (if ADEOS is
>>currently doing some interruptible stuff..)
>>
>>I-pipe Adeos versions always run interrupt handlers over the stack of the
>>preempted context.
>>
> 
> 
> So, I presume I can use the  rt_task_self() function to get the task which has been pre-empted, right? (and I've always a valid task)
> 

rt_task_self() always returns NULL when called over an ISR.

> 
> Thanks for your help.
> 
> Daniel
> 
> 


-- 

Philippe.