On Mon, 13 Nov 2006, Gilles Chanteperdrix wrote:
Sebastian Smolorz wrote:
Gilles Chanteperdrix wrote:
Sebastian Smolorz wrote:
> Gilles Chanteperdrix wrote:
> > Sebastian Smolorz wrote:
> > > Sebastian Smolorz wrote:
> > > > 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.
> > > >
> > > > I see another one which has to do with the fact that
> > > > __ipipe_mach_tsc is updated both in __ipipe_mach_get_tsc and
> > > > __ipipe_mach_set_dec. This leads to double-added ticks because
> > > > the latter funcion is called only once a period and the former
> > > > even more than once. So Xenomai counts jiffies in
> > > > /proc/xenomai/timer to fast. Manfred, can you confirm this?
> > >
> > > Forget this, my eyes weren't open this morning ... In
> > > __ipipe_mach_get_tsc there is no update of __ipipe_mach_tsc, of
> > > course.
> >
> > Right, but __ipipe_mach_tsc and ns_timer_lxlost get also updated in
> > __ipipe_mach_acktimer, this looks wrong, in the integrator
> > implementation, they are updated in the timer interrupt, only if the
> > timer is not stolen.
>
> OK, let's speculate a little bit. (Maybe all of the following turns out
> to be completely wrong, but it wouldn't be the first time for me today.
> ;-) Hopefully Manfred can give some comments which pieces of my
> speculation are right.)
>
> The timer counts down to zero, causes an interrupt and then reloads
> automatically with ns_timer_reload. So, when __ipipe_mach_acktimer is
> called ns_timer_reload ticks have passed and can be added to
> __ipipe_mach_tsc and ns_timer_lxlost. Some ticks later,
> __ipipe_mach_set_dec is executed, the passed ticks are added to
> __ipipe_mach_tsc and ns_timer_lxlost and the timer is reprogrammed to
> the new value.
The problem is that when Xenomai manages the timer, it get reloaded with
values distinct from ns_timer_reload,
But the reload value is assigned to ns_timer_reload in set_dec. So every
time __ipipe_mach_acktimer is executed it adds the last set reload value
which is the right one, isn't it?
Manfred sent its code in two versions: one inlined in the mail, the
other as an attachment. In the inlined version, ns_timer_reload is not
set in set_dec.
Ok, I was talking about the attachment because set_dec was not there in
the inlined code.
it is even not reloaded at all when the system is a bit late,
Are you referring to the discussed ipipe_trigger_irq call when the delay is
zero?
Yes. And in this case set_dec is not called before acktimer,
Agreed. So the adding of ticks must be removed from __ipipe_mach_acktimer.
Additionally, when the timer has reloaded itself these ticks must not be
"forgotten". The integrator implementation takes care of it in
integrator_getticksoffset(), see [1].
[1]
http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/arch/arm/patches/adeos-ipipe-2.6.15-arm-1.5-02.patch?v=SVN-trunk;a=arm#L5609
--
Sebastian
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
