Hello,
The scope traces that I sent are from 2 sources yes, the one with the
'short' RTS time is taken when the port was driven by the (Linux)
guest .
The trace with the correct RTS length was taken when the port was
driven by the (Linux) host.
Both times the same application. I looked in the so
Hello Friend,
I don't think so. He is referring to a normal modem with an AT command
set not responding
to incoming call, which is probably a setup issue.
I am referring to how the _hardware handshake_ signals from the guest
environment are passed to the host.
best regards
Kees
On 12/9/12, Koe
Hello,
I have attached 2 scope shots, SCR0002.BMP shows a failing
communication cycle, the upper trace is the RTS signal on the port,
the lower trace shows the databytes wriiten.
SCR4.BMP show how it had to be, RTS is active during the whole databytes.
In general an application will issue ioc
Hello,
It is a Linux host and a Linux guest. One serial port (/dev/ttyS0) is
passed from the host to the guest.
The application (on the guest) does Hart (r) communication, This is
done with a 1200 baud simplex modem (one side at a time).
The application raises RTS so that the modem goes in trans
Public bug reported:
When using a serial port with a Linux guest (and host) and the
application uses hardware handshake, this fails because the handling of
TEMT and/or THRE is not operating properly in such cases.
As long as it takes _time_ for the 'real' port to output the data TEMT
may not retu
