Checking CTS at the exact time that a character is received

We have an application that needs to check the status of the CTS line
every time a character is received in the UART of the serial port
/dev/ser1. In this application, we are not using hardware nor software
flow control, so the meaning of DTR, DSR, RTS, and CTS is
application-specific. We are talking to an RF modem which sends
information over the serial port, but assigns a special meaning to the
CTS line.

If a character is received from the modem when the CTS line is clear,
the character is interpreted as a DATA byte.

If a character is received from the modem when the CTS line is set, the
character is interpreted as a COMMAND byte.

We cannot change the operation of the RF modem.

We need to be able to reliably read the status of the CTS line at the
time the character was received.

Is there a guaranteed way to do it?

Thx!
Alain.

You can check the status lines by sending the DCMD_CHR_LINESTATUS devctl to the serial driver, but this
is probably going to kill your performance if you have to do it on a byte by byte basis, since it involves
a message send. In fact that isn’t going to work since the status is not going to be the same as when the character
was actually received from the hardware.

You’ll probably have to end up writing your own modified serial driver, where the status is checked in the
interrupt receive routine.

You can either buy the io-char ddk or roll your own driver, based on the resmgr framework.

Alain Achkar wrote:

We have an application that needs to check the status of the CTS line
every time a character is received in the UART of the serial port
/dev/ser1. In this application, we are not using hardware nor software
flow control, so the meaning of DTR, DSR, RTS, and CTS is
application-specific. We are talking to an RF modem which sends
information over the serial port, but assigns a special meaning to the
CTS line.

If a character is received from the modem when the CTS line is clear,
the character is interpreted as a DATA byte.

If a character is received from the modem when the CTS line is set, the
character is interpreted as a COMMAND byte.

We cannot change the operation of the RF modem.

We need to be able to reliably read the status of the CTS line at the
time the character was received.

Is there a guaranteed way to do it?

Thx!
Alain.


cburgess@qnx.com

Colin Burgess <cburgess@qnx.com> wrote:

You’ll probably have to end up writing your own modified serial driver,
where the status is checked in the interrupt receive routine.

You can either buy the io-char ddk or roll your own driver, based on
the resmgr framework.

Actually, I think the io-char ddk (it’s called the Character Driver
Development Kit on the website) is a free kit, rather than one that
needs to be bought.

I’d go that way, modify the incoming data stream to be one byte of
data, followed by a 2nd byte that reflects the status of CTS. That
will probably be the easiest way to go. In fact, for flexibility,
you might want to encode all of DTR, DSR, RTS, and CTS in the
byte in case you need the others at the application level, later.

-David


Alain Achkar wrote:
We have an application that needs to check the status of the CTS line
every time a character is received in the UART of the serial port
/dev/ser1. In this application, we are not using hardware nor software
flow control, so the meaning of DTR, DSR, RTS, and CTS is
application-specific. We are talking to an RF modem which sends
information over the serial port, but assigns a special meaning to the
CTS line.

If a character is received from the modem when the CTS line is clear,
the character is interpreted as a DATA byte.

If a character is received from the modem when the CTS line is set, the
character is interpreted as a COMMAND byte.

We cannot change the operation of the RF modem.

We need to be able to reliably read the status of the CTS line at the
time the character was received.

Is there a guaranteed way to do it?

Thx!
Alain.

\

cburgess@qnx.com


David Gibbs
QNX Training Services
dagibbs@qnx.com

BTW the status bits are defined in /usr/include/sys/dcmd_chr.h just under the DCMD_CHR_LINESTATUS devctl.

David Gibbs wrote:

Colin Burgess <> cburgess@qnx.com> > wrote:


You’ll probably have to end up writing your own modified serial driver,
where the status is checked in the interrupt receive routine.


You can either buy the io-char ddk or roll your own driver, based on
the resmgr framework.


Actually, I think the io-char ddk (it’s called the Character Driver
Development Kit on the website) is a free kit, rather than one that
needs to be bought.

I’d go that way, modify the incoming data stream to be one byte of
data, followed by a 2nd byte that reflects the status of CTS. That
will probably be the easiest way to go. In fact, for flexibility,
you might want to encode all of DTR, DSR, RTS, and CTS in the
byte in case you need the others at the application level, later.

-David



Alain Achkar wrote:

We have an application that needs to check the status of the CTS line
every time a character is received in the UART of the serial port
/dev/ser1. In this application, we are not using hardware nor software
flow control, so the meaning of DTR, DSR, RTS, and CTS is
application-specific. We are talking to an RF modem which sends
information over the serial port, but assigns a special meaning to the
CTS line.

If a character is received from the modem when the CTS line is clear,
the character is interpreted as a DATA byte.

If a character is received from the modem when the CTS line is set, the
character is interpreted as a COMMAND byte.

We cannot change the operation of the RF modem.

We need to be able to reliably read the status of the CTS line at the
time the character was received.

Is there a guaranteed way to do it?

Thx!
Alain.


\

cburgess@qnx.com


cburgess@qnx.com

Alain Achkar wrote:

We need to be able to reliably read the status of the CTS line at the
time the character was received.

You need to clarify exactly when CTS changes state for a given COMMAND/DATA byte but yes, looking at a 16550 datasheet http://focus.ti.com/docs/prod/folders/print/tl16c550c.html , the Modem Status Register (MSR) seems to provide the needed info that you want.

The status bits are not stored in the FIFO so you’ll need to work at the ISR level. However, you can keep the FIFO if you really want/need it, you just have to get your head around using the MSR as a regular interrupt source. If not wanting the FIFO then simply checking CTS level after each byte is received should suffice.


Evan