Re: [Xenomai-core] RTDM and Timer functions

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 3319 bytes --]

Rodrigo Rosenfeld Rosas wrote:
> Em Quinta 09 Março 2006 17:33, Jan Kiszka escreveu:
> 
>> Rodrigo Rosenfeld Rosas wrote:
>>> Hi Jan,
>>>
>>> I'm still concerned about the future of RTDM and timer functions. I think
>>> there should be some function for starting the timer manually, since the
>>> automatic feature don't work great for RTDM drivers.
>>>
>>> It is not nice to have to run the latency (or any other) program for
>>> starting the timer before I can load my driver. And it is not suffice to
>>> run it once I booted. After I open/close my rtdm device and reload my
>>> driver the problem will occur again and I'll have to re-run the latency
>>> program.
>> Sorry I don't see the problem here.
>>
>> # modprobe xeno_nucleus; cat /proc/xenomai/timer
>> status=off:setup=1392:tickval=0:jiffies=0
>>
>> # modprobe xeno_rtdm; cat /proc/xenomai/timer
>> status=oneshot:setup=1392:tickval=1:jiffies=8113917792696
>>
>> So the timer is running right since when rtdm is loaded?!
> 
> Yes, here too.
> 
>> And that simple heartbeat rtdm example on my rt-addon homepage now
>> cleanly runs even without any further helper to start some timer.
> 
> Yes, here too. You are right, once the timer is in oneshot mode. My driver 
> loads correctly without the helper. Then I start a user application that 
> changes the timer to periodic mode and uses my driver. When I reload my 
> driver, now in periodic mode, the problem raises.

What happens if you make the periodic timer the default one in the
kernel configuration?

> 
> It seems, there is no problem when the timer is set to oneshot. But when 
> turning it to periodic, at least one of rtdm_task_busy_sleep() or 
> rtdm_clock_read() doesn't seem to work. See below:
> 
> cat /proc/xenomai/timer
>   status=periodic:setup=188:tickval=100000:jiffies=19972453
> 
> start_time = rtdm_clock_read();
> rtdm_task_busy_sleep(84000);
> temp_time = rtdm_clock_read();
> rtdm_printk(KERN_INFO "Should be near 84000: %u\n", (unsigned int)
>                    (temp_time-start_time));
> 
> Sometimes the result is "Should be near 84000: 100000", that is kind of 
> correct, since the tickval is 100000, although I think that those functions 
> in the RTDM driver context should be independent of the tick value set by the 
> user program... Maybe using oneshot in the driver calls and periodic in the 
> application... I really don't know what would be the best approach here...

rtdm_clock_read always uses the nucleus clock. Using something different
(e.g. always TSC) would break applications specifying absolute times
derived from the return values of other skins' functions.

> 
> But the worst case is that sometimes I get "Should be near 84000: 0" which 
> clearly is a incorrect result.

That might be a rounding issue somewhere, as the sleep than clearly did
not wait at least one tick. Will have to check this when time permits.

> 
> After I run the latency program, the timer turns to be oneshot again and 
> everything goes right.
> 
> What can I do to solve this problem?

Use oneshot mode in the meantime - or even longer ;). Why do you prefer
periodic mode for your application? Another workaround: reduce the tick
interval.

> 
> Thanks in advance,
> 
> Rodrigo.
> 

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]