RS485 Half Duplex Communication
-
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.
