This is a question for which I have been looking for an answer for quite some time but haven’t yet found one:
Is there a way to determine if a target serial device has issued an XOFF character when XON flow control is turned on?
Remote devices send ASCII codes 0x0D and 0x0B for XOFF/XON, respectively, causing the local serial port to halt transmission if XON flow control is enabled. As such, these characters are not received by the serial control, i.e. they neither throw a DataAvailable event nor end up in the receive buffer. Unlike hardware flow control where one can check the status of handshaking lines to determined if transmit flow has halted, there appears to be no way to make the same determination when software flow control is enabled. I have tried to monitor the BytesLeftToSend property while writing to the serial port, but even if transmission is halted due to the port having received an XOFF from the remote device, the BytesLeftToSend property eventually goes back to 0 as the control happily passes on the write data to the transmit buffer. As far as the Xojo code is concerned, the data has been sent, and there isn’t an apparent way to find out if the data has actually left the serial port. It is only once the transmit buffer is full (which might need quite a bit of data) that the BytesLeftToSend value starts to grow.
Has anybody come up with a solution to this problem?
I should clarify that this is an issue I’m having on Windows. On the Mac the XOFF and XON characters are actually received by the serial control when XON flow control is enabled, allowing the code to know if the remote device sent one of these characters. I haven’t tested this on Linux yet, but on Windows these characters are definitely trapped before they end up in the receive buffer of the serial port control.
It would be great if the state of XOFF/XON could be checked that way. Unfortunately, LineStateChanged can only be used with actual hardware lines, such as RTS, CTS, DTR, DSR, DCD, and RI. I would love for the Serial control to have an event that fires when the XON/XOFF state changes. Perhaps it’s time I created a feature request in Feedback.
Yeah, I tend to agree. I hope they don’t fix it . It does come in handy in this case.
My app is a serial utility that allows hobbyists and developers to communicate with their serial hardware, whatever that may be. Some may choose to use handshaking for their communication. For development and debugging purposes it is crucial to have visibility into what is going on. Hardware flow control can easily be monitored with both visual indicators in my tool as well as physically probing the status lines with e.g. an oscilloscope or LEDs connected to these lines. With XON flow control, however, there is no physical means to determine if the target has issued XOFF to halt transmission flow. Thus, one might argue that being able to determine the state of such a handshake in software is even more critical. Personally, I don’t use XON/XOFF for any of my own hardware, but some of my users do, and I would like to be able to offer the capability to monitor the status of XON/XOFF the same way I offer visibility into the physical status lines.
I have been using the Serial control for some time. I had some problems with it recently when I tried using DTR control to cause a reset of an Arduino. Aside from the fact the related properties were not well documented, also I may have come across a bug which I have not yet confirmed. That is, having toggled the DTR line (using the DataTerminalReady property), then the Serial.DataAvailable event would not fire on the port.
Also, I hired someone to figure out how to create a virtual serial port in OSX, which he succeeded in doing with some Posix calls in C. That was great, it worked fine opening another terminal and using “screen” to talk to it. But for some reason when I opened that virtual port in Xojo, Xojo would not transmit to the virtual port. The virtual port transmitted to Xojo just fine. So another mystery with regard to Serial.
My conclusion currently is that Serial is dodgy. I think the answer is to deal with serial comm at a lower level ie address the OS APIs directly. I don’t know how to do this but apparently I need to learn.
After testing different USB/Serial adapters, it appears that this is rather a “bug” with the USB/Serial hardware/driver as opposed to OS X. The behavior where XON/XOFF characters leak through when software flow control is enabled happens with FTDI and Prolific devices on Mac OS X but not with Keyspan and Silabs C2104. Thus, monitoring for XON/XOFF to determine if the target has issued a flow control character is not something one can depend on, not even on the Mac.
. It does come in handy in this case.