From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <43EA5FEB.50109@domain.hid> Date: Wed, 08 Feb 2006 22:17:31 +0100 From: Philippe Gerum MIME-Version: 1.0 Subject: Re: [Xenomai-core] Watchdog/Interrupt management References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: ROSSIER Daniel Cc: xenomai@xenomai.org ROSSIER Daniel wrote: > Hi Philippe, >=20 >=20 >=20 >>-----Message d'origine----- >>De : Philippe Gerum [mailto:rpm@xenomai.org] >>Envoy=E9 : mardi, 7. f=E9vrier 2006 14:45 >>=C0 : 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 we= ll >> >>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 interrupt= s >>by doing >>this in your ISR: >> >>unsigned long flags; >> >>rthal_local_irq_sync(flags); >> >>rthal_local_irq_restore(flags); >=20 >=20 > Please, could you just provide me with a small explanation about what t= he rthal_local_irq_sync() function is doing?=20 > This unstalls Xeno's pipeline stage and re-enables hw interrupts in the s= ame time=20 when entering your ISR, then restores the original masking before returni= ng to the=20 nucleus. >=20 >>>I've attached the code below (I've removed the function return check f= or >> >>readibility reasons, but all objects are fine). >> >>>Another question: the ISR is called on behalf of the interrupted stac= k >> >>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 t= he >>preempted context. >> >=20 >=20 > So, I presume I can use the rt_task_self() function to get the task wh= ich has been pre-empted, right? (and I've always a valid task) >=20 rt_task_self() always returns NULL when called over an ISR. >=20 > Thanks for your help. >=20 > Daniel >=20 >=20 --=20 Philippe.