Does fusion-0.7.2 support nested interrupts?

Philippe Gerum rpm at xenomai.org
Fri Jun 10 17:54:20 CEST 2005


Philippe Pétillon wrote:
>>-----Message d'origine-----
>>De : Philippe Gerum [mailto:rpm at xenomai.org]
>>Envoyé : vendredi 10 juin 2005 17:17
>>À : Philippe Pétillon
>>Cc : rtai at rtai.org
>>Objet : Re: Does fusion-0.7.2 support nested interrupts?
>>
>>
>>Philippe Pétillon wrote:
>>
>>>Do you think using a hw_unlock/hw_lock scheme in every ISR is
>>
>>practical? You
>>
>>>may, but I don't.
>>>
>>
>>Using hw_unlock/hw_lock is not the proper way to do this, using
>>xnlock_put_irqrestore()/xnlock_get_irqsave() is.
> 
> 
> OK, if you prefer, but my software will never run on a SMP machine anyway.

Who talked about SMP? Using xnlocks is about accessing the virtual PIC, 
which hw_* services do not.

> Not everyone is using PCs!!!
> 

No kidding?! Interestingly, my main test platform is PPC.

> 
>>Maybe one should first ponder about the penalty of trashing the I-cache
>>by taking another ISR compared to quickly getting out of the inner one
>>which should be designed to have a bounded complexity and run fast
>>anyway. Unless your do much of your work in the ISR, the latter is
>>better wrt concurrency. In case the ISR does heavy processing, one may
>>want to consider moving most of the complexity to a thread context.
>>
> 
> 
> I don't want to enter this kind of debate but I won't agree with you: cache
> performances
> are non-realtime issues, and if I need to respond to an event in a few
> microsecs,
> I really can't rely on other interrupts to be fast enough.

I would respectfully ask you to reconsider such thundering assertion 
with the little help of your favourite timebase counter.

  I need to have my
> interrupt at
> the highest priority (hw PICs are done for that) and to be sure of the
> maximum it latency.
> 
> 
>>>Anyway, how would you do this in xnintr_irq_handler (the nested variable
>>>makes me guess very much that it should be done there),
>>
>>No, it should be done in your ISR, not in the nucleus.
>>
>>  as the
>>
>>>IPIPE_STALL_FLAG is set in __adeos_sync_stage before entering
>>
>>the routine?
>>
>>>Of course the interrupts are re-enabled, but they do not reach
>>
>>the ISR level
>>
>>>because they are differred in __adeos_walk_pipeline?
>>
>>They won't be deferred. If the stage is unstalled while an interrupt
>>occurs for the current domain, the interrupt log will be immediately
>>synchronized by __adeos_walk_pipeline() on behalf of the current
>>interrupt frame.
>>
> 
> 
> On the version I use (fusion-0.7.2, adeos r7c1/ppc ported on ARM), it is not
> 

Cool. Any source code to publish?

the case.
> In __adeos_sync_stage, the line
> "__set_bit(IPIPE_STALL_FLAG,&cpudata->status);" stalls the pipe
> for my domain before trigerring the ISR, and after the ISR, the pipe is
> unstalled.
> If another interrupt occurs, it will be added to the pending list.
> I just checked it with an ISR that triggers another one with higher
> priority.
> 
> But maybe this has changed in newer version of adeos?
> 

Since I cannot diff with your code, I cannot tell.

> 
> 
>>>-----Message d'origine-----
>>>De : Philippe Gerum [mailto:rpm at xenomai.org]
>>>Envoyé : vendredi 10 juin 2005 16:40
>>>À : Philippe Pétillon
>>>Cc : rtai at rtai.org
>>>Objet : Re: Does fusion-0.7.2 support nested interrupts?
>>>
>>>
>>>Philippe Pétillon wrote:
>>>
>>>
>>>>Hello!
>>>>A small question about fusion-0.7.2.
>>>>
>>>>Does it support nested interrupts? If yes, how to enable it?
>>>
>>>
>>>If your ISR re-enables interrupts, nesting will occur safely on top of
>>>fusion's primary interrupt handler, since Adeos allows it too.
>>>
>>>
>>>
>>>>If not, how do you think you can build a real-time system above it?
>>>>
>>>
>>>
>>>Read the code. Emacs is your friend.
>>>
>>>
>>>
>>>>
>>>>*Philippe Pétillon*
>>>>SPiDCOM Technologies
>>>>137, avenue du Général Leclerc
>>>>92340 Bourg la Reine
>>>>
>>>>FRANCE
>>>>
>>>>
>>>>
>>>>Tel: +33 1 41 87 91 90
>>>>
>>>>email: philippe.petillon at spidcom.com
>>>
>>><mailto:philippe.petillon at spidcom.com>
>>>
>>>>www.spidcom.com <http://www.spidcom.com/>
>>>>
>>>>
>>>
>>>--
>>>
>>>Philippe.
>>>
>>
>>
>>--
>>
>>Philippe.
>>
> 
> 


-- 

Philippe.




More information about the Rtai mailing list