Direct Manipulation of Serial Port Handshaking Signals?

I’ve been asked to look into the possibility of adding a gamma-ray
spectroscopy multichannel analyzer (Amptek MCA8000A “Pocket MCA”) to
one of our existing, QNX4 driven, data acquisition systems. The
interface to the MCA is via RS-232. The trouble is Amptek has
implemented an unusual handshaking protocol that uses all four of the
hardware handshaking/flow-control signals (DTR, DSR, RTS & CTS) but
not in the “usual” way. By “usual” way I mean a scheme where DTR and
DSR are both asserted to indicate each side is there and willing to do
business and RTS and CTS are used to provide flow-control.

The Amptek scheme is difficult to describe but suffice it to say it
won’t work using normal hardware flow control under QNX (or any other
operating system for that matter). I talked to an Amptek engineer
about the problem yesterday and he confirmed the protocol was…
ummmm… “bizzarre” and in order to successfully implement it one
would require direct control over the DTR, DSR, CTS and RTS signals.

In the Windows based software that Amptek supplies with the MCA they
apparently bypass whatever serial drivers Windows has and manipulate
the UART directly. I’ve done that many times under DOS (and hated it
every time) and could probably do it under QNX as well but I hate that
idea and would rather manipulate the handshaking signals through the
existing QNX serial driver. After combing through the help files and
other “serial port” posts to this newsgroup, I’m beginning to get the
impression that’s not possible.

Have I just missed the magic set of library functions or am I really
going to have to program and control the UART directly?


Any comments and suggestions will be most appreciated!



Regards,


Charlie Hubbard

<charles.hubbard@pnl.gov> wrote in message
news:9ob1mvs8oc4kiomd84o520apo9c8tp8vun@4ax.com

I’ve been asked to look into the possibility of adding a gamma-ray
spectroscopy multichannel analyzer (Amptek MCA8000A “Pocket MCA”) to
one of our existing, QNX4 driven, data acquisition systems. The
interface to the MCA is via RS-232. The trouble is Amptek has
implemented an unusual handshaking protocol that uses all four of the
hardware handshaking/flow-control signals (DTR, DSR, RTS & CTS) but
not in the “usual” way. By “usual” way I mean a scheme where DTR and
DSR are both asserted to indicate each side is there and willing to do
business and RTS and CTS are used to provide flow-control.

The Amptek scheme is difficult to describe but suffice it to say it
won’t work using normal hardware flow control under QNX (or any other
operating system for that matter). I talked to an Amptek engineer
about the problem yesterday and he confirmed the protocol was…
ummmm… “bizzarre” and in order to successfully implement it one
would require direct control over the DTR, DSR, CTS and RTS signals.

In the Windows based software that Amptek supplies with the MCA they
apparently bypass whatever serial drivers Windows has and manipulate
the UART directly. I’ve done that many times under DOS (and hated it
every time) and could probably do it under QNX as well but I hate that
idea and would rather manipulate the handshaking signals through the
existing QNX serial driver. After combing through the help files and
other “serial port” posts to this newsgroup, I’m beginning to get the
impression that’s not possible.

Have I just missed the magic set of library functions or am I really
going to have to program and control the UART directly?

It’s possible, via qnx_ioctl(), look at the ioct header file there is a
description of
which bit does what.

Beware that changing control line is asynchronous to rx/tx operation.

write(…)
ioctl()…

The ioctl may actually flip control in the middle of the transfer
requested by write.

You need to make sure buffer are flushed and/or use unbuffered io.


Any comments and suggestions will be most appreciated!



Regards,


Charlie Hubbard

charles.hubbard@pnl.gov wrote:

Have I just missed the magic set of library functions or am I really
going to have to program and control the UART directly?

As Mario suggested, the qnx_ioctl() routines MIGHT give you the
access you need. But, they might not – especially if there are
timing issues, etc.

Any comments and suggestions will be most appreciated!

Start with the source to Dev.ser for the serial handling code, rather
than writing it from scratch?

ftp.qnx.com:/usr/free/qnx4/os/samples/Dev_drivers/Dev.ser.tgz

(Its interface to dev is a bit out-dated, but the serial handling
code won’t have changed much. I’d use that, with either a custom
message-passing interface, or in simple io-manager framework.)

-David

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