I’m trying to explore some of the distributed capabilities of QNX, particularly in terms of having IO processes on one node and control processes on another node.
My test rig is as follows:
1 P3 1Ghz (node name P3)
1 P4 2.4GHz (node name P4)
1 scope, dual channel, channel 1 connected to a data pin on P4’s parallel port, channel 2 connected ti a data pin on P3’s parallel port.
I wrote a simple server that waits for a msg and either turns the parallel port data lines high or low depending on the msg contents.
Ran this program on both nodes at the same time.
Wrote a client program that receives timer pulses at say 128Hz. This program sends a msg to the parallel port servers on nodes p3 and p4 (so one is local, the other one is over the fast ethernet via qnet).
All programs run at priority 30.
The local parallel port produces a nice steady fixed frequency pulse train.
The remote parallel port has a lot of non-deterministic behavior (i.e. pulse lenghts vary quite a bit). I am guessing this is due to qnet. The fast ethernet connection is full duplex, and it is an isolated segment - point to point between the 2 pcs.
Is there any way to reduce this non-deterministic behavior of qnet?
Note that first I tried a resource manager and just opening the file locally and remotely (same deal 2 resource managers) - found I had to fflush to push the msgs out at the rate I was trying to run at (128Hz). When using a res mgr seemed like both parallel ports exhibited the non-deterministic behavior (varying length pulses). I figured it was due to qnet / res mgr library.
Then I traid the simple 3 way handshake using MsgSend()/Receive/Reply and acheived the results I mentioned first (deterministic local respons, non-deterministic remote response).
The motivation for all this was to allow implementation of an intelligent IO controller as a QNX pc with a simple native QNX messaging interface (or preferably a posix file based interface using a resource manager).