Re: [Xenomai-help] timer-handling adeos/xenomai on arm

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

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.

> 
> 
>>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, so
ns_timer_reload value is wrong.

-- 
                                                  Gilles Chanteperdrix