Re: [Xenomai-core] Watchdog/Interrupt management

[Philippe Gerum]

ROSSIER Daniel wrote:
Hi Philippe,


-----Message d'origine-----
De : Philippe Gerum [mailto:[EMAIL PROTECTED]
Envoyé : mardi, 7. février 2006 14:45
À : ROSSIER Daniel
Cc : xenomai-core@gna.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.