Re: Serial data delay

Replies are listed 'Best First'.
Re^2: Serial data delay by afoken (Chancellor) on Oct 24, 2018 at 06:08 UTC
I've found something that works on the bench. `sleep(4); # number will be decreased in production` [download] That looks quite scary. Seeing delays in code handling serial transmissions is usually an indicator for misconfiguration, i.e. lack of proper handshake. In Serial data delay, you explicitly disable all handshake: `$port->handshake("none")` [download] Check the documentation of the serial device. I would expect to find either handshake lines (RTS/CTS, sometimes DSR/DTR), or some kind of software handshake. XON/XOFF is common for software handshake, but people have been (and still are) very creative in re-inventing the wheel, especially with embedded devices. There are literally hundreds of strange software handshake protocols. Software handshake using XON/XOFF can be handled by the operating system or some low-level driver library, but you have to enable it. If you find the device sending unexpected 0x13 and 0x11 bytes, especially when writing much data to it, it may implement XON/XOFF. 0x13 = 19 = DC3 is XOFF, meaning that you should stop sending more data. 0x11 = 17 = DC1 is XON, telling you to continue sending data. For non-standard software handshake variants (i.e. everything but XON/XOFF), RTFM. Hardware handshake is usually easier. Some embedded devices implement only one half of the hardware handshake, a pin to indicate "input buffer is full, stop sending more data". That is usually labelled RTS (according to RS232E, it should be labelled RTR, ready to receive) and should be connected to CTS on the other side. The other pin, CTS, is omitted because they expect their communication partner (i.e. the PC) to be able to handle all incoming data at full speed. For hardware handshake, a three-wire connection (RxD, TxD, GND) is not sufficient, you need at least one extra wire from device RTS (or DTR) to PC CTS (or DSR). Use at least a five-wire connection (RxD, TxD, GND, RTS, CTS), preferably a cable with all signals connected. In Serial data delay, I see you using `/dev/ttyUSB0`. I know there are some USB RS232 converters that DO NOT implement the handshake lines. Make sure you don't have such a troublemaker device. FTDI FT232-based adapters should be fine. FTDI FT230 implements only RTS and CTS, but lacks support for DSR, DTR, DCD, RI. Prolific-based adapters cause a lot of pain on Windows due to crappy drivers, but work ok on Linux. At work, we have banned everything but FTDI, and we buy them only from major distributors. They costs a few cents more, but it's simply not worth fiddling with some random garbage chip that either crashes the system, stops transmitting data, or damages data in the middle of a 24 hour aerospace test procedure. The costs for supporting crap chips in that environment buy you a truckload of FTDI chips. For debugging, you also do not want a chip that is unreliable. Your development target is sufficiently unreliable to cause lots of trouble. You do not want to waste time debugging your debug tools. Also in Serial data delay, I see `/home/pi`. Are you using a Raspberry Pi? Its serial port does support RTS/CTS, but you have to enable it: https://ethertubes.com/raspberry-pi-rts-cts-flow-control/, http://www.deater.net/weave/vmwprod/hardware/pi-rts/. Remember that the Raspi uses 3.3V signals, you have to add a level converter. Using a MAX3232 or similar is quite easy, as they come as ready-to-use adapter boards, including pin headers for the Raspi side and DB9 connector for the RS232 side. Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: Serial data delay
by afoken (Chancellor) on Oct 24, 2018 at 06:08 UTC

I've found something that works on the bench.
sleep(4); # number will be decreased in production
[download]

That looks quite scary. Seeing delays in code handling serial transmissions is usually an indicator for misconfiguration, i.e. lack of proper handshake. In Serial data delay, you explicitly disable all handshake:

$port->handshake("none")
[download]

Check the documentation of the serial device. I would expect to find either handshake lines (RTS/CTS, sometimes DSR/DTR), or some kind of software handshake. XON/XOFF is common for software handshake, but people have been (and still are) very creative in re-inventing the wheel, especially with embedded devices. There are literally hundreds of strange software handshake protocols.

Software handshake using XON/XOFF can be handled by the operating system or some low-level driver library, but you have to enable it. If you find the device sending unexpected 0x13 and 0x11 bytes, especially when writing much data to it, it may implement XON/XOFF. 0x13 = 19 = DC3 is XOFF, meaning that you should stop sending more data. 0x11 = 17 = DC1 is XON, telling you to continue sending data. For non-standard software handshake variants (i.e. everything but XON/XOFF), RTFM.

Hardware handshake is usually easier. Some embedded devices implement only one half of the hardware handshake, a pin to indicate "input buffer is full, stop sending more data". That is usually labelled RTS (according to RS232E, it should be labelled RTR, ready to receive) and should be connected to CTS on the other side. The other pin, CTS, is omitted because they expect their communication partner (i.e. the PC) to be able to handle all incoming data at full speed.

For hardware handshake, a three-wire connection (RxD, TxD, GND) is not sufficient, you need at least one extra wire from device RTS (or DTR) to PC CTS (or DSR). Use at least a five-wire connection (RxD, TxD, GND, RTS, CTS), preferably a cable with all signals connected.

In Serial data delay, I see you using /dev/ttyUSB0. I know there are some USB RS232 converters that DO NOT implement the handshake lines. Make sure you don't have such a troublemaker device. FTDI FT232-based adapters should be fine. FTDI FT230 implements only RTS and CTS, but lacks support for DSR, DTR, DCD, RI. Prolific-based adapters cause a lot of pain on Windows due to crappy drivers, but work ok on Linux.

At work, we have banned everything but FTDI, and we buy them only from major distributors. They costs a few cents more, but it's simply not worth fiddling with some random garbage chip that either crashes the system, stops transmitting data, or damages data in the middle of a 24 hour aerospace test procedure. The costs for supporting crap chips in that environment buy you a truckload of FTDI chips. For debugging, you also do not want a chip that is unreliable. Your development target is sufficiently unreliable to cause lots of trouble. You do not want to waste time debugging your debug tools.

Also in Serial data delay, I see /home/pi. Are you using a Raspberry Pi? Its serial port does support RTS/CTS, but you have to enable it: https://ethertubes.com/raspberry-pi-rts-cts-flow-control/, http://www.deater.net/weave/vmwprod/hardware/pi-rts/. Remember that the Raspi uses 3.3V signals, you have to add a level converter. Using a MAX3232 or similar is quite easy, as they come as ready-to-use adapter boards, including pin headers for the Raspi side and DB9 connector for the RS232 side.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

[reply]
[d/l]
[select]