Hello,
I wrote a RT kernel module for a DAQ card. The DAQ card gets interrupts
every 200 us (5 kHz) and I've got a RT interrupt handler which wakes up a RT function
I guess, you mean a RT task. Is it a kernel or user space task? [...]
So basically, my question is: If I have rt_pipe_write() writing to a pipe from a kernel module with a 200 us period and I have a read() in a tight loop reading from that same pipe is user space, what could be the origin of the fact that sometimes my read() doesn't get woken up?
Xenomai does provide a Linux system with hard real-time support but it doesn't make the Linux kernel itself hard real-time, nor user-space applications which relies merely on the standard kernel services. Your task (here it even doesn't matter whether it's a linux or xenomai task) relies on read() so it's under control of the linux scheduler, hence it depends on the /scheduling latency/ provided by Linux, not Xenomai. Roughly speaking, with Xenomai you have 2 domains: primary (all time-critical activities must stay here) and secondary (Linux standard drivers, applications, xenomai tasks while executing linux system calls). So hard real-time support is provided only as long as your tasks/drivers work in the primary domain. To this goal, (1) drivers are developed with RTDM (preferable way); (2) applications (both kernel and user-space) are developed using one of the Xenomai skins (native, posix, ...). And as I mentioned above, it's not a case for your task with a read() loop. So you should probably reconsider your application design to clearly separate the parts that require hard real-time support from the rest. -- Best regards, Dmitry Adamushko
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
