What is the bestway for a realtime task to talk to a Photon task? I have a
serial link that need to act as a host to an embedded DSP system, and can’t
get hung in photon when doing hand shaking. The serial link manager will
also coordinate with high speed digital I/O, and do some analog outputs,
this is my realtime task. However I also need a display interface which,
due to the type of data, need to be graphical and thus should be written in
Photon. From going thru the docs, it sounds like Photon talks to other
photon apps just find, but does play well using normal QNX IPC. Are there
any good examples or info on realtime task talking to Photon task?
Pete Eddy
I would consider having your serial manager dump the data into shared memory
and let the display process grab it from there.
Larry
“Bob Smith” <bobsmith@home.com> wrote in message
news:am4mqm$mqq$1@inn.qnx.com…
What is the bestway for a realtime task to talk to a Photon task? I have
a
serial link that need to act as a host to an embedded DSP system, and
can’t
get hung in photon when doing hand shaking. The serial link manager will
also coordinate with high speed digital I/O, and do some analog outputs,
this is my realtime task. However I also need a display interface which,
due to the type of data, need to be graphical and thus should be written
in
Photon. From going thru the docs, it sounds like Photon talks to other
photon apps just find, but does play well using normal QNX IPC. Are there
any good examples or info on realtime task talking to Photon task?
Pete Eddy
Bob Smith wrote:
I would prefer to have some form of syncronization. I.e. DSP There is a
new waveform avaliable → HOST Tell the user interface to update the graph.
Assuming your “server” is a resmgr, then simply do a select
(i.e.PtAppAddFdPri)
from your photon application. Make sure the priority is lower than your
real-
time application. If your server is not a resmgr, then simply cook up
an equivalent scheme to select().
I would prefer to have some form of syncronization. I.e. DSP There is a
new waveform avaliable → HOST Tell the user interface to update the graph.
Pete
“Larry Sweet” <lsweet@fct.ca> wrote in message
news:am4o9s$o4q$1@inn.qnx.com…
I would consider having your serial manager dump the data into shared
memory
and let the display process grab it from there.
Larry
“Bob Smith” <> bobsmith@home.com> > wrote in message
news:am4mqm$mqq$> 1@inn.qnx.com> …
What is the bestway for a realtime task to talk to a Photon task? I
have
a
serial link that need to act as a host to an embedded DSP system, and
can’t
get hung in photon when doing hand shaking. The serial link manager
will
also coordinate with high speed digital I/O, and do some analog outputs,
this is my realtime task. However I also need a display interface
which,
due to the type of data, need to be graphical and thus should be written
in
Photon. From going thru the docs, it sounds like Photon talks to other
photon apps just find, but does play well using normal QNX IPC. Are
there
any good examples or info on realtime task talking to Photon task?
Pete Eddy
\
Bob Smith wrote:
What would an “equivalent scheme to select” be?
An equivalent scheme to select is:
- Photon app sends message to server declaring interest in some data.
- Inside above message is a pulse that was attached in your photon app.
- Server replies (non-blocking) to your photon app.
- At some point in the future, the data that your photon app is
interested in changes, and server does a MsgDeliverEvent (non-blocking).
- Photon app receives pulse, and sends a message to server requesting
data update.
- Server replies with modified data (non-blocking).
Since the server is never blocked (only non-blocking ops used to get
data to app), the real-time behaviour of the server is unaffected.
I had be contemplating something like this:
(Phab App)<–2 Named Pipes–>(Protocol application / not a res
mgr)<—>(SDLC Serial Driver)<–serial line–>(DSP)
Where the protocol manager would handle hand shaking a what not…
However using the named pipes seems a little flakey, and does not provide
good packetization. For instance the Photon app continously calls the
“callback” for the FD handler if the other task quits or dies. Repeatedly
hitting the callback with no delay is at best a waste of processor time, at
worst it causes bizarre behavior in the GUI.
On top of that named pipes just seem wrong when you have such a rich and
powerful set of IPC avaliable under QNX.
I agree, named pipes suck.
Rennie
What would an “equivalent scheme to select” be?
I had be contemplating something like this:
(Phab App)<–2 Named Pipes–>(Protocol application / not a res
mgr)<—>(SDLC Serial Driver)<–serial line–>(DSP)
Where the protocol manager would handle hand shaking a what not…
However using the named pipes seems a little flakey, and does not provide
good packetization. For instance the Photon app continously calls the
“callback” for the FD handler if the other task quits or dies. Repeatedly
hitting the callback with no delay is at best a waste of processor time, at
worst it causes bizarre behavior in the GUI.
On top of that named pipes just seem wrong when you have such a rich and
powerful set of IPC avaliable under QNX.
“Rennie Allen” <rallen@csical.com> wrote in message
news:3D85F25E.4090403@csical.com…
Bob Smith wrote:
I would prefer to have some form of syncronization. I.e. DSP There is
a
new waveform avaliable → HOST Tell the user interface to update the
graph.
Assuming your “server” is a resmgr, then simply do a select
(i.e.PtAppAddFdPri)
from your photon application. Make sure the priority is lower than your
real-
time application. If your server is not a resmgr, then simply cook up
an equivalent scheme to select().