RM (resource manager)...

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

Hi!

What is the preferred way of accessing 16 physical hardware buffers on a PCI
card (through a PIC 9050 controller) using the QNX resource manager
functionality?

The limitations are as follows: Each buffer (FIFO) has an equal size 4k
deep, and each buffer can be addressed at an offset 0x0 + n*0x1000, where n
i buffer number n (0 to 15), but only one buffer can be accessed at one
time, i.e. 188 bytes must be written to one buffer before you can address
and write to another buffer. Buffer management can be either handled by
polling buffer status flags (empty, almost full) or handled by the hardware
generating an interrupt each time a buffer is nearly empty, or when there is
room for 1880 bytes.

The user (or client) of the RM will be a number of processes using the write
() POSIX API.

The scenario as I se it is as follows:

One RM process can handle all communication with the card, i.e. the process
can contain the interrupt service routine, and have a thread started each
time a new write message from the user appears.

or

One RM process for each buffer, i.e. 16 processes will handle the
communication with the card. In addition an 17th process will contain the
interrupt service routine and low level configuration functions for the
card. Since one buffer can be addressed at one time, synchronisation must be
used between the processes, maybe using the mutex functionality offered by
QNX kernel.

What is the best way of doing this?

Thanks!

Oystein Solvberg
Telenor Satellite Broadcasting AS
Norway

2

Rob Krten (?), written a nice book about QNX, and the RM topics
(the atoz.c example) gives a good idea about it.


Oystein Solvberg wrote:

Hi!

What is the preferred way of accessing 16 physical hardware buffers on a PCI
card (through a PIC 9050 controller) using the QNX resource manager
functionality?

The limitations are as follows: Each buffer (FIFO) has an equal size 4k
deep, and each buffer can be addressed at an offset 0x0 + n*0x1000, where n
i buffer number n (0 to 15), but only one buffer can be accessed at one
time, i.e. 188 bytes must be written to one buffer before you can address
and write to another buffer. Buffer management can be either handled by
polling buffer status flags (empty, almost full) or handled by the hardware
generating an interrupt each time a buffer is nearly empty, or when there is
room for 1880 bytes.

The user (or client) of the RM will be a number of processes using the write
() POSIX API.

The scenario as I se it is as follows:

One RM process can handle all communication with the card, i.e. the process
can contain the interrupt service routine, and have a thread started each
time a new write message from the user appears.

or

One RM process for each buffer, i.e. 16 processes will handle the
communication with the card. In addition an 17th process will contain the
interrupt service routine and low level configuration functions for the
card. Since one buffer can be addressed at one time, synchronisation must be
used between the processes, maybe using the mutex functionality offered by
QNX kernel.

What is the best way of doing this?

Thanks!

Oystein Solvberg
Telenor Satellite Broadcasting AS
Norway

3

Claudio Cardozo <cazo@bol.com.br> wrote:

Rob Krten (?), written a nice book about QNX, and the RM topics
(the atoz.c example) gives a good idea about it.

Thanks for the recommendation, Claudio :slight_smile:
BTW, you can get the examples from the book at www.parse.com

To answer Oystein’s question, I’d probably go with one process handling
all of the buffers; it’s just easier to manage the interrupt service
routine that way. This way, you’re not trying to coordinate multiple
different accesses to the same hardware over multiple processes; it’s
all centralized by the one RM…

I’m not sure you’d need to start one thread for each write(); this just
complicates things, in that now the (possibly) multiple threads need to
synchronize to each other. If I understand the situation correctly,
when a write is in progress, since you can’t have multiple accesses to
the hardware concurrently anyway, then why have multiple threads? They’d
all be waiting for the one thread that “owns” the hardware to finish
anyway – might as well serialize that with the one thread in the RM…

Cheers,
-RK

Oystein Solvberg wrote:

Hi!

What is the preferred way of accessing 16 physical hardware buffers on a PCI
card (through a PIC 9050 controller) using the QNX resource manager
functionality?

The limitations are as follows: Each buffer (FIFO) has an equal size 4k
deep, and each buffer can be addressed at an offset 0x0 + n*0x1000, where n
i buffer number n (0 to 15), but only one buffer can be accessed at one
time, i.e. 188 bytes must be written to one buffer before you can address
and write to another buffer. Buffer management can be either handled by
polling buffer status flags (empty, almost full) or handled by the hardware
generating an interrupt each time a buffer is nearly empty, or when there is
room for 1880 bytes.

The user (or client) of the RM will be a number of processes using the write
() POSIX API.

The scenario as I se it is as follows:

One RM process can handle all communication with the card, i.e. the process
can contain the interrupt service routine, and have a thread started each
time a new write message from the user appears.

or

One RM process for each buffer, i.e. 16 processes will handle the
communication with the card. In addition an 17th process will contain the
interrupt service routine and low level configuration functions for the
card. Since one buffer can be addressed at one time, synchronisation must be
used between the processes, maybe using the mutex functionality offered by
QNX kernel.

What is the best way of doing this?

Thanks!

Oystein Solvberg
Telenor Satellite Broadcasting AS
Norway
\

–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.

4

Oystein Solvberg <oystein.solvberg@telenor.com> wrote:

Hi!

What is the preferred way of accessing 16 physical hardware buffers on a PCI
card (through a PIC 9050 controller) using the QNX resource manager
functionality?

The limitations are as follows: Each buffer (FIFO) has an equal size 4k
deep, and each buffer can be addressed at an offset 0x0 + n*0x1000, where n
i buffer number n (0 to 15), but only one buffer can be accessed at one
time, i.e. 188 bytes must be written to one buffer before you can address
and write to another buffer. Buffer management can be either handled by
polling buffer status flags (empty, almost full) or handled by the hardware
generating an interrupt each time a buffer is nearly empty, or when there is
room for 1880 bytes.

The user (or client) of the RM will be a number of processes using the write
() POSIX API.

Do all the buffers go different places, or are they just different
output buffers for the same final stream? That is, will the various
clients know of the different buffers, and get to pick which one?

The scenario as I se it is as follows:

One RM process can handle all communication with the card, i.e. the process
can contain the interrupt service routine, and have a thread started each
time a new write message from the user appears.

I would strongly suggest using one RM process. BUT, I would not suggest
creating a thread for each write() request. You would, in fact, probably
be better with a single-threaded resource manager, possibly with a 2nd
thread to handle the hardware side of things. (e.g. one thread block
in dispatch_block(), and one thread block in InterruptWait())

When data comes for a particular device, buffer it on the resmgr side,
and flag the hardware side that there is data available for output.
(This could be done with a condvar, mutex, semaphore, or just using
an atomic_set on some flag variable, or other method.)

You can look at the non-block flag (O_NONBLOCK) to determine what to
do with a client if they write more data than you want to buffer
(e.g. more than 4k for a particular stream).

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

5

Hi.

Thank you all for answer and recommendations to my question.

Oystein

Oystein Solvberg <oystein.solvberg@telenor.com> wrote in message
news:ad1v1h$p8d$1@inn.qnx.com…

Hi!

What is the preferred way of accessing 16 physical hardware buffers on a
PCI
card (through a PIC 9050 controller) using the QNX resource manager
functionality?

The limitations are as follows: Each buffer (FIFO) has an equal size 4k
deep, and each buffer can be addressed at an offset 0x0 + n*0x1000, where
n
i buffer number n (0 to 15), but only one buffer can be accessed at one
time, i.e. 188 bytes must be written to one buffer before you can address
and write to another buffer. Buffer management can be either handled by
polling buffer status flags (empty, almost full) or handled by the
hardware
generating an interrupt each time a buffer is nearly empty, or when there
is
room for 1880 bytes.

The user (or client) of the RM will be a number of processes using the
write
() POSIX API.

The scenario as I se it is as follows:

One RM process can handle all communication with the card, i.e. the
process
can contain the interrupt service routine, and have a thread started each
time a new write message from the user appears.

or

One RM process for each buffer, i.e. 16 processes will handle the
communication with the card. In addition an 17th process will contain the
interrupt service routine and low level configuration functions for the
card. Since one buffer can be addressed at one time, synchronisation must
be
used between the processes, maybe using the mutex functionality offered by
QNX kernel.

What is the best way of doing this?

Thanks!

Oystein Solvberg
Telenor Satellite Broadcasting AS
Norway