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

> Thanks in advance,
> Rodrigo.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to