Hello Viktor,
I do understand the domain separation, but if I got things right, pipes
can only be read using read() in user space. That's also what the API documentation suggests.
Pipes are designed to connect actors from /different/ domains, normally a flow of data is from primary --> secondary (linux). The actor in the secondary domain must not be hard real-time latency dependent, for the obvious reasons I described before. Take a look at the queue interface (rt_queue_* for the native skin). 1) Why does it happen every 10000 cycles (2 seconds)? The fact that this
erratic behaviour is so deterministic makes me think that it might not be standard Linux related. I mean the fact that it happens every 2 seconds (and I mean 2e6 us, not just approximately 2 seconds) just makes it look like it's provoked by something which is RT.
Maybe yes, maybe no. Some periodic linux activity (ISR, long interrupt/preemption disabled section, hight priority task) may be a reason as well. 2) Even if my read() is scheduled, how comes I only get past the read()
after the second rt_pipe_write()? One would think that if my read() is scheduled I could be waking up after 250 us or 300 us, no? But I'm *always* woken up after 2 cycles (that is 400 us).
Maybe something has to do with your part (driver + rt task) in the primary domain.. Could you make a small sample program which still shows this "problem" and post it here? Additional option is to use the I-pipe tracer as Jan suggested. 3) Pipes seemed to be a good way to transfer data from kernel space.
What other (maybe more deterministic) way would you suggest? I'm not asking for a complete program architecture here just a half dozen words describing how you would have done it.
rt_queue_* Well, you may post your design briefly as well and ask for comments. Thanks in advance.
Best regards, Viktor STARK
-- Best regards, Dmitry Adamushko
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
