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
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomaifirstname.lastname@example.org https://mail.gna.org/listinfo/xenomai-core