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/

Reply via email to