RS485 Half Duplex Communication
-
Hello,
We are using Yocto BSP (based on Poky) and have developed a QT/QML based application. We are using Qt version 5.9.4.
-
This Qt application is running on a linux based board which is connected to a processor over RS485 half duplex.
-
This application has following configuration for half duplex communication:
int fd;
fd = open ("/dev/ttymxc2", O_RDWR | O_SYNC);
struct serial_rs485 rs485conf;
rs485conf.flags = SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND;
if (ioctl(fd, TIOCSRS485, &rs485conf) != 0)
{
return false;
} else{
return true;
} -
Application sends about 250 bytes of data and receives response from end processor within 100 ms.
-
We are using QSerialPort class for serial communication and have subscribed/connected to “bytesWritten” signal to confirm that Santino board application transfers complete data to end processor.
-
We are observing some queer behavior in this communication.
-
We observed that sometimes, even though complete 250 bytes of data is sent from our device (bytesWritten signal received with 250 and no error received), some old packets (which were sent earlier and for whose response was also received) are dumped on Serial port. This is visible only on Serial Port communication monitor tool like Docklight. Application logs never show anything extra bytes written to Serial Port.
-
We are making sure that serial buffer is cleared using clear() call before sending any data packet and flushing using flush() after sending the data packet over serial port.
-
Please note this doesn’t happen always, but randomly.
Is this a known issue where QSerialPort or QIODevice class dumps something on its own on serial Port?
Or are we doing something wrong? -
-
Hi and welcome to devnet,
Why are you mixing ioctl and QSerialPort ?
The 5.9 series is pretty outdated, would it be possible to run a more recent version of Qt ?
-
Which exact version are you using ?
You did not answer my question about mixing ioctl and QSerialPort. -
In my honest opinion this is not a problem related to QSerialPort. The 485 bus uses the enable (sometimes called direction) signal to write or read from bus.
When that signal is not managed directly by the 485 transiver we normally write a kernel driver so, after that, everithing has to work perfecly.
I suggest you to check who and how is managing the enable signal.
After that some devices make an echo in the bus to manage the anticollision feature.
If you send something and after that you receive back the same row of bytes that means that none has disturbed the comminication. If you receive a byte row different from that you have trasmit, that meas that someone in the bus has disturb the communication so you have to resend. -
Qt version used is 5.9.4
I didn't get what problem we can get by mixing ioctl and QSerialPort? And how we would be able to make same configuration as done using ioctl with QSerialPort.@HSKW said in RS485 Half Duplex Communication:
Qt version used is 5.9.4
I didn't get what problem we can get by mixing ioctl and QSerialPort? And how we would be able to make same configuration as done using ioctl with QSerialPort.The problem is not the mixing but how your are doing it. You're opening the same file twice so there might things that might get lost in between. You should open it with QSerialPort and then use the handle that it provides to call your ioctl.
-
In my honest opinion this is not a problem related to QSerialPort. The 485 bus uses the enable (sometimes called direction) signal to write or read from bus.
When that signal is not managed directly by the 485 transiver we normally write a kernel driver so, after that, everithing has to work perfecly.
I suggest you to check who and how is managing the enable signal.
After that some devices make an echo in the bus to manage the anticollision feature.
If you send something and after that you receive back the same row of bytes that means that none has disturbed the comminication. If you receive a byte row different from that you have trasmit, that meas that someone in the bus has disturb the communication so you have to resend. -
@HSKW said in RS485 Half Duplex Communication:
Qt version used is 5.9.4
I didn't get what problem we can get by mixing ioctl and QSerialPort? And how we would be able to make same configuration as done using ioctl with QSerialPort.The problem is not the mixing but how your are doing it. You're opening the same file twice so there might things that might get lost in between. You should open it with QSerialPort and then use the handle that it provides to call your ioctl.
@SGaist
Can you please let me know how to set RS485 mode with half duplex by opening with QserialPort and then using the handle for ioctl?Also, just an update on the issue:
- Yocto BSP with Kernel version 4.1.15, Qt version is 5.9.4
- It is observed that after exchanging some packets over RS485, even though Qt application is not sending or receiving anything, still on Docklight(connected to monitor serial communication) 4096 bytes of data (current byte sent - 4096) are seen.
- Looking at the signal over logic analyzer, we found that TX_ENABLE line remains high in such a case till these old 4096 bytes are dumped.
- We think that somehow kernel driver's TX buffer is getting corrupted and that is getting dumped, causing TX_ENABLE line to remain high.
Do we know if this as an known issue? Or is our application causing the TX buffer corruption - which we don't think, as we are clearing the buffer before sending data over SErialPort using clear() call and also calling flush() after sending data. Moreover, we always get bytesWritten signal indicating complete bytes written before we send next request.
any help is highly appreciated.
-
Use the handle returned by QSerialPort::handle to call your ioctls on.
-
Use the handle returned by QSerialPort::handle to call your ioctls on.
-
Use the handle returned by QSerialPort::handle to call your ioctls on.
-
I don't know which is your problem but I assure QSerialPort works perfectly, since 5.9 release up to now because I use it in a lot of projects, with half (485) and full duplex interfaces, in Linux, Windows, Mac and imx devices.
You should search the problem somewehere.
If the behaviour happens only with QSerialPort still the problem is somewhere.
If you want to make a test using something else than Qt you could find interesting this:
https://github.com/denisgottardello/ComPortServer
A console based application to test the serial interface and to convert it in a tcp socket, based on fpc. You shouldn't have problem to use it in you device. -
HI
We too have the same problem
We use QT 5.7 and instead of using QSerialPort we use open() write() and read()
Usually the communication is correct, then suddenly part of the packet is resent or even the same packet many times, in short I have to send nine bytes and instead up to eighty bytes come out.
Did you have a solution for this problem?
Ciao, Beppe
-
Hi, perhaps you could work around the bug by stuffing the data inside packets with a sequence number? So when the same data is randomly retransmitted the receiver can safely discard it because it already has that packet.
