Philippe Gerum wrote:
> On Sat, 2006-11-11 at 12:05 +0100, Gilles Chanteperdrix wrote:
> > Schlägl "Manfred jun." wrote:
> > > Hi again!
> > >
> > > I've the presumption, there is something wrong with my timer-handling.
> > > Could you please take a look at my handling.
> > >
> > > Thanks in advance!
> >
> > The problem I see with your code is that you are updating
> > ns_timer_lxlost in __ipipe_mach_acktimer, the integrator architecture
> > code, which also uses a decrementer does not do that. Apart from that, I
> > see nothing wrong.
> >
> > If there is a problem with using ipipe_trigger_irq on your architecture,
> > maybe we could let rthal_timer_program_shot pass null delays to
> > __ipipe_mach_set_dec.
>
>
> Maybe the issue is not with ipipe_trigger_irq, which looks ok for ARM
> too, but rather with the internal latency/timings of the Xenomai port
> over this arch? The very difference between calling ipipe_trigger_irq
> and programming the decrementer for a close shot, is that interrupt
> delivery would happen immediately after the interrupt mask is enabled
> again with the former method. OTOH, the latter would likely leave some
> time left to the nucleus to get out of the current IRQ, thus preventing
> recursion-induced lockups.
What I meant is that maybe in Manfred case, some global variable need to
be set in __ipipe_mach_set_dec and used in __ipipe_mach_acktimer and when
using ipipe_trigger_irq, __ipipe_mach_acktimer get called without
__ipipe_mach_set_dec.
That said, I probably misunderstood ns_timer_reload.
--
Gilles Chanteperdrix.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
