I saw Rennie already gave you a couple of good advices. I believe in this
particular case something is not quite right with hardware. Otherwise, I
think, changing priorities should have helped, or at least caused some
changes in behaviour.
The golden rule is: less parts - more reliable system. When you need
real-time you must be absolutely sure what every part (hardware or software)
of your system is doing in every particular moment.
I’m using a PLX9080 based FPMC (few of them per computer). The purpose of
the system is to collect data from 1 to 4 external intelligent devices (1
FPMC per device), do some math when data from all devices
is obtained and make the result available to clients connected to this box
via TCP/IP. I don’t measure the productivity of the system in KB/s or MB/s.
It is rather time needed to communicate to all devices. All
FPMC<->device transactions are synchronous: every so often computer sends a
request to all devices and waits fixed time for response. The amount of data
sent back and force is pretty small (about 100-4000
bytes), but “so often” has to be constant (late data is lost data). We
achieved 0.7ms rate on P III 1.2GHz (35% CPU load) and 1.3ms on P233MHz (95%
CPU load). 0.5ms of those times takes the external device to respond. The
good news is that the FPMCs transfer data from FPGA FIFO to computer memory
via DMA. No matter how many devices are connected, the data from all of them
is available practically simultaneously. The resource manager just puts all
data into one IOV.
One of the components of the success is to assign proper priorities to every
task. Make the priority of the tasks, which behaviour you cannot predict,
lower then critical tasks. In my case, for example, the system
has no other interface than network (telnet, ftp, MODBUS), but the network
is widely open for any authorized client at any time. So, the resource
manager priority is higher than io-net just by 1.
P.S. I used to read this newsgroup through the http://groups.google.com, and
sometimes I post messages via the same interface. I did the same with this
message a couple days ago. When I looked at the newsgroup from Outlook
Express I couldn’t find it. I believe that messages posted that way never go
to inn.qnx.com, but are just kept somewhere on google (i.e. everything
written with google can be read with google only). Sorry for this offtopic.
“Øystein Sølvberg” <email@example.com> wrote in message
Any answer greatly appreciated!
I have made a QNX 6.0 resource manager, following the QNX documentation. I
am working against a PCI card (using a PLX 9050 controller), writing data
using C function memcpy in a interrupt thread handler, which is unblocked
every time my ISR determines if the PCI card has generated the interrupt.
Interrupt handling, writing data to the card at high bitrates works great
nearly 40 Mbit/s! I am using a data analyser analysing what has gone
the PCI card, and verifies that the data coming through is correct. As
mentioned, I am using memcpy, copying 1880 bytes every time an interrupt
Strange things start to happen when I for example move a window (terminal
window in Photon). Also, occasional use of the printf() also cased the
problem. The problem seems to be that data copying, using the memcpy stops
or halts. The result is corrupted data at the output of the PCI card.
At low bit-rates this problem does not occur.
I am aware of that printf() or moving a window takes a lot of processor
resources, but is should not interfere with a memcpy function using the
bus for writing data to the PCI card. I would expect only a lower
I have also tried different priorities on the interrupt thread, but with
Have anyone gone through a similar problem, and solved it?
Telenor Satellite Broadcasting