Tue, 16 Jan 2001 Ren Yuhong wrote:
Hi, Dear All,
I am using Qt RT Linux to develop a package. I need to fetch data via
RTFIFO to be plotted within GUI designed by Qt. My three questions are
as follows :
/** Question 1**/
When I create RT FIFO using "rtf_create(fifo, size)", how can I decide
the "size" of the RT FIFO? I even don't know the unit of the size, is it
Byte?
The size of the FIFO should be at least MAX_WRITE_SIZE +
READER_WORST_CASE_LATENCY + some margin, so you don't occasionally lose data.
The unit is bytes, AFAIK.
/** Question 2**/
Also, say, I tried to create a FIFO by using "rtf_create(3, 300)",
however, I found that the data to be passed to the Qt plotter seemed to
be displayed contineously, sometimes the data shown is wrong. Could you
please kindly give me a clear idea about the RT FIFO's working
mechanism? If I take the data out of the FIFO, will it still stay in
the FIFO, or be deleted at once?
Well, that's implementation dependent, but although the data normally isn't
deleted or overwritten by the read() call (it's either a pointer or an offset
that is changed after the memory copy operation), you should consider it gone
once read() returns.
/** Question 3**/
In my kernel module, I set the "pthread" periodical time as 5ms, and
output one double data to RTF3, then I will fetch the data from RTF3 to
be plotted in GUI. I also set a 5ms QTimer event (plus a
QSocketNotifier) to plot the data, but sometimes the data shown is not
correct. My question is: Will the user space's 5ms match the kernel
module's 5ms well?
Normally, you'd sleep on the FIFO read(), and therefore wouldn't need another
timer. Your thread would just wake up as soon as there is data in the FIFO.
However, you'd need to use non-blocking reads not to freeze the application if
the driver stops writing data. (Shouldn't matter much in this case, but you
should be aware of it, especially if your application is talking to other
drivers as well.)
The problem with non-blocking reads is that they will read as much data as is
available in tho FIFO, and then return. That is, you *have to* check the read
size! The only exception is when you know that the writes are atomic, and
you're reading only one "block" at a time.
Not knowing much about Qt programming, my questions are;
* Does you thread reading code run in a separate thread,
and if it does,
* Is the interaction between that code and your Qt timer
code thread safe?
From what you describe, this seems to be some kind of synchronization problem,
so nonblocking reads and inter-thread communication are among the first things
I'd check.
//David
..- M A I A -.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`-- http://www.linuxaudiodev.com/maia -'
..- David Olofson ---.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`-- [EMAIL PROTECTED] -'
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/