I have a question about connection lost detection in QNX serial ports. With the following simple program, the linux (or other unix) can return an error on an unconnected serial port, but QNX seems not. Is there a specific way to do it under QNX or I miss anything?
When this program is run, the QNX success with no error, and the linux prints the “failed to open serial port /dev/ttyS0”.
#if defined (QNX)
static const char strSerial[] = “/dev/ser1”; #elif defined (linux)
static const char strSerial[] = “/dev/ttyS0”; #endif
static const char strString[] = “This is a test string”;
int main(int argc, char * argv[])
{
int fd;
int written;
fd = open(strSerial, O_RDWR);
if (fd < 0)
{
printf("failed to open serial port %s\n", strSerial);
return 1;
}
written = write(fd, strString, sizeof(strString));
if (written < sizeof(strString))
{
printf("failed to write to serial port %s", strSerial);
close(fd);
return 2;
}
close(fd);
return 0;
If the driver (devc-ser*) is running and the port is ok, I don´t think you should get an error… you open the port, you write, you close it. What’s wrong with that?
There is no such thing as a “connection” that can be detected or lost with basic serial ports. The open will succeed if the driver (devc-ser*) is configured for (or is autodetecting) a serial port - otherwise not.
Thanks for your example. Does that mean if I am using null modem connection, I have no simple way of knowing the connection status of the serial port?
Sorry for my naive question. After the open call, the write call to the serial port returns exactly the correctly number of characters supposed to be written. Where are those character gone if the serial line is not connected? I was assuming if the write call returns n characters, the n characters are sent through the line and now awared the line was dropped.
Yes - connection status has to be detected by the application - e.g. by using handshake signals or simply by polling your device (sending characters and receiving an answer from the device). If you are free to define the protocol, you may add information to your data like the number of characters to be sent or a CRC.
Serial lines are a very, very old technology. You have to use USB if you want more comfort (and complexity…)
Yes, serial lines are very old technology. But they are not phased out. I still need to write applications to interface to at least half a dozen of different devices talking via serial communication lines, with protocols defined by different vendors. I am kind of surprise that the posix write call does not return error value if it does not have those character really written. I suppose at the devc-ser* device driver level, the error could be detected, couldn’t it?
Characters to be sent are written in a ring buffer. The UART is taking characters from the ring buffer and transmits them on the TX line. It can’t detect if there is someone (or maby more than one) is listening on the TX line - it’s broadcast (like radio). Of course, the ring buffer on your side can overflow if the UART is not fast enough.
I did some lookup on the web and found that UART provides a Transmitter Holding Register Empty Interrupt is to let you know that the output buffer has finished sending everything that you pushed into the buffer. Also there is a line status register that can give some information about the physical line. Also there is a Line Status Register that give you information on possible error conditions that may exist within the UART. I understand that the output ring buffer is normally large enough that no error could be detected on a single write. Does the serial device driver eventually aware the status of the serial line after some time from the interrupt and registers from the UART? If I select_attach to the file descriptor of the opened serial port, would I receive exception from the serial device driver?
The error conditions reported in the line status register are related to the incoming data on the RX line. If there is an error (e.g. parity error or framing error) you can get infomed about this. But you are concerned about problems with the outgoing data on the TX line. I’m sorry, but there is no way to know, if data has reached it’s destination - belive it or not!
The only possibility is to find a (device specific) method to query the device status (polling) for each of your devices.
(Did I already mention, that UARTs are very, very old technology?)
My aim is to find out how to detect the lost of communication. I tried to start with question of outputing data. Obvious it does not work out after all you explanations. Thats why I started asking question about inputs. My later questions were trying to see if the device driver can provide me anything help. Obviously polling is kind of resource wasting method and I would prefer something better if there is any. But you already mentioned there is nothing but polling.
Serial ports have a hardware method of checking that they are physically connected. Beyond that, all other checking involves some protocol, usually along with a check sum or crc. You can implement this yourself in a device driver, or through a resource manager, but both sides need to cooperate. In close range connections where there isn’t a lot of interference, once you have verified that transmission is working, you can usually get by without all this.
You mentioned serial ports have a hardware method of checking that they are physically connected. Does the QNX device driver poll or get notified from the hardware? If so, how can an application know from the device driver this checking result?
The hardware method is called DTR (Data Terminal Ready) DSR (Data Set Ready). This are voltage lines that indicate that the other side is connected. Also RTS (Ready To Send) and CTS (Clear to Send) may be used. The QNX device driver will respect these lines if set up properly. You can get the lines current state, but I think you would have to poll. I haven’t looked closely at how QNX 6 implements this, but QNX 4 gave you most of what you need. It would also be possible to modify the driver to inform you of such a change.
Thank you Maschoen. You have it explained to the point. If I want to have notification from driver, does that mean I need to download the source of driver and do the change and recompile the driver? If so, which is the correct driver and where can I download it? I don’t want to end up having polling codes in every serial communication applications.
We are talking about DTR, DSR and friends you already know from one of my previous posting (and you didn’t seem to like them…)
In theory it should be possible to use ionotify() with _NOTIFY_COND_OBAND in such situations - but you have to check if your serial driver supports this.
Thank you to all those who gave answer to my questions and those who patient to read my questions. I am not experienced in serial port communication programming and as I mentioned, I have over half a dozen different serial device to interface. Therefore I am not looking for one answer, one solution; but try to learn all possible solutions before I start. Although the cloud is not entirely clear, but I will stop my questions here. Thank you again.