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.

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...

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

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?

Thanks in advance,

Rodrigo.


_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora!
http://br.acesso.yahoo.com


_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to