Rodrigo Rosenfeld Rosas wrote:
> Hi,
> 
> I just can't understand what is happening.
> 
> The above code on my driver initialization gives the following results.
> 
>         start_time = rtdm_clock_read();
>       rtdm_task_busy_sleep(43000);
>       temp_time = rtdm_clock_read();
>          rtdm_printk(KERN_INFO "%u - %u = %u\n",(unsigned int) temp_time, 
> (unsigned 
> int) start_time, (unsigned int) (temp_time-start_time));
> 
>          rtdm_printk(KERN_INFO "%u - %u = %u\n",(unsigned int) 
> (temp_time&0xffffffff), (unsigned int) start_time&0xffffffff, (unsigned int) 
> ((temp_time-start_time)&0xffffffff));
> 
> 
> As I expected, both printk gave the same (wrong?) result:
> 3175950208 - 2800623168 = 375327040
> 
> I was waiting something near to 43000, shouldn't I?
> 
> Please, can someone explain me what is going on...
> 

Basically confirmed:

I-pipe: Domain Xenomai registered.
Xenomai: hal/x86 started.
Xenomai: real-time nucleus v2.1-rc2 (Champagne) loaded.
Xenomai: starting RTDM services.
4194262080 - 2680902336 = 1513359744


But when I additionally load xeno_posix to get the system timer started:

Xenomai: starting POSIX services.
3899754503 - 3899706087 = 48416


The point is that rtdm_clock_read() relies on the nucleus timer being
started. Otherwise, it just returns plain wrong numbers.

This makes me scream again for that damn timer being started
AUTOMATICALLY! I guess Philippe knows what I'm talking about... ;)
Meanwhile, we should state this in the docs. At least for 2.0.x, this
will remain true anyway.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help

Reply via email to