Experimental Physics and
Industrial Control System

Dirk Zimoch <[email protected]> · Thu, 28 Jun 2012 13:44:17 +0200

Hi Eric,

Maybe the implementation of tyGSOctalStartup() is wrong?

I can see in the implementation of tyITx() that it fails if the device

had received an XOFF before. It fails too if there are no more bytes to

write in the output buffer. A failure simply says: no bytes to output.

This can be used in the interrupt handler. The "ready to transmit next

byte" interrupt calls tyITx() to get the next byte to output. If it

returns ERROR, it should disable this interrupt until the next time

the driver dependent txStartup function is called. Thus when there is

nothing to output (buffer empty or XOFF), tyITx() should not be called

again.

The txStartup function is called by tyTxStartup (from the generic ty

driver framework), which is called whenever transmission should be

enabled. That is at initialization, when the application wants to write,

when a byte is received and echo is enabled, and when flow control says

"continue sending", e.g. XOFF.

The implementation of the serial device I have (TIP866) enables

interrupts in that case in its txStartup function, eventually gets the

"ready to transmit" interrupt, polls tyITx() for the next byte, receives

an error (and stays silent), and finally disables the interrupt again.

vxWorks should probably optimize this by not calling txStartup as long

as XOFF is active. This would save some wasted interrupt time. But this

is probably hopeless. Thus I compared your driver with the one I have.

It seems that tyGSOctalStartup wants to fix this performance issue by

checking for available output first before enabling interrupts. Without

access to the internals of the generic ty driver framework, calling

tyITx() seems the only way to do the check. But tyITx removes a bytes

from the output buffer on success. Thus it must do what is normally done

in the interrupt handler: put the byte into the transmit register.

However ERROR return of tyITx() is completely legal and is handled

correctly (i.e. do nothing). I do not see any good reason for the error

message.

Thus my advise is: simply remove the logMsg call from tyGSOctalStartup.

Best regards,
Dirk

Bjorklund, Eric A wrote:

Hi Dirk & Eric,

Thanks for your replies.  Sorry it has take so long to get back to you.

(Original Post) Bjorklund, Eric A wrote:

For the first time in our experience, we have a serial device (Kepco power supply) that insists on sending XOFF/XON sequences.  We are using streamDevice and a Greenspring Octal IP module to talk to it.  StreamDevice and Asyn appear to have no problems with the XOFF/XON characters, however the tyGSOctalStartup routine in tyGSOctal.c puts out a continuous stream of
"tyITX ERROR, sr=0c" errors.  The cause of these errors turns out to be
that the tyITx() routine (a vxWorks function) returns ERROR if it is called to start a transmission and the transmitter is XOFF'd.
This causes the tyGSOctalStartup routine to log an error -- perhaps because it thinks someone is trying to send a zero-length buffer (no characters left to transmit is the other reason tyITx() will return ERROR).
The easiest way to fix the problem was just to remove the error message (see attached patch file -- which only comments out the offending code in case that turns out to be a bad idea).  As far as we can tell, there are no ill effects from this.  We seem to be talking to the power supply just fine.
Anybody see a reason why we should leave the error report in tyGSOctalStartup() ?

On Jun 25, 2012, at 7:07 AM, Dirk Zimoch wrote:

XON/XOFF should be resolved on a lower level than StreamDevice and even asyn. In asyn versions >= 4.17 you can control XOFF/XON behavior on the OS driver level:

asynSetOption ("port", 0, "ixon", "Y")

Now, the device should not forward XON to asyn/StreamDevice but instead block the write function until the device is free again (I hope).

Dirk

I agree that XON/XOFF should be resolved on a lower level than StreamDevice and Asyn.  The routines I was writing about (tyGSOctalStartup() and tyITx()) are indeed OS-level routines (the later being an interrupt-level routine).  We are using asynSetOption ("port", 0, "ixon", "Y"), and in fact, the empirical evidence so far seems to indicate that everything from StreamDevice to Asyn to the the OS driver is working perfectly -- except for the constant barrage of error messages whenever tyITx() returns ERROR to tyGSOctalStartup() because transmission is XOFF'd.

So, the point of the post is to inquire of all the tyGSOctal gurus out there (if there be any left):
1.  Can we get rid of that error message in tyGSOctalStartup() ?
2.  Is there something I'm missing about XON/XOFF handling in tyGSOctal that will bite me later?

On Jun 25, 2012, at 9:20 AM, Eric Norum wrote:

While ASYN/termios does support it, XOFF/XON is a notoriously unreliable flow control mechanism.
Is there really no way to disable this behaviour from the power supply?   Could you run at a slower serial line speed and avoid the handshaking?

Agreed.  In fact, I strongly suspect that the reason no one else has reported this problem is because most people have avoided using XON/XOFF in their protocol.

Looking through the manual, however, our options seem to be:

a) XON/XOFF
b) Wait for a prompt from the device before sending data (kind of like XON/XOFF, but without the XOFF)
c) Let the device echo back each character to the sender and restart the command if there was an error.

Option a) certainly seemed to be the lesser of three evils.

-Eric Bj.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System