Re: [Xenomai-core] Watchdog/Interrupt management
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Watchdog/Interrupt management
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.
