Wolfgang Walter wine@stwm.de wrote:
When we send 17 bytes with 150 baud, no parity, one stop bit then we need to wait at least 17*10/150 seconds > 1000 ms
Under Windows with both real COM-port and USB-serial cable this test takes no longer than 890 ms, usually it's even shorter like 875 ms. Testbot VMs also don't fail this test. If under Wine it takes > 1000 ms for you then probably there is a bug somewhere.
On Thursday 05 September 2013 10:32:15 Dmitry Timoshkov wrote:
Wolfgang Walter wine@stwm.de wrote:
When we send 17 bytes with 150 baud, no parity, one stop bit then we need to wait at least 17*10/150 seconds > 1000 ms
Under Windows with both real COM-port and USB-serial cable this test takes no longer than 890 ms, usually it's even shorter like 875 ms. Testbot VMs also don't fail this test. If under Wine it takes > 1000 ms for you then probably there is a bug somewhere.
How can that be? If you send 17 bytes which expands to 170 raw bits and you only sent 150 bits/s?
Maybe you are using a virtual machine or your com port does not support 150 baud and chooses a different speed. Or you use a UART with a large buffer and which already signals TX-EMPTY even if it is still sending from an internal buffer. But one should not rely on that.
I used a real com-port, by the way, and had a com-port-analyzer adapted to it. It exactly sends 150 bits per second which means 15 data-bytes per second.
Regards,
Wolfgang Walter wine@stwm.de wrote:
When we send 17 bytes with 150 baud, no parity, one stop bit then we need to wait at least 17*10/150 seconds > 1000 ms
Under Windows with both real COM-port and USB-serial cable this test takes no longer than 890 ms, usually it's even shorter like 875 ms. Testbot VMs also don't fail this test. If under Wine it takes > 1000 ms for you then probably there is a bug somewhere.
How can that be? If you send 17 bytes which expands to 170 raw bits and you only sent 150 bits/s?
Maybe you are using a virtual machine or your com port does not support 150 baud and chooses a different speed. Or you use a UART with a large buffer and which already signals TX-EMPTY even if it is still sending from an internal buffer. But one should not rely on that.
I'm testing under 64-bit Windows 7 on real hardware.
Am Donnerstag, 5. September 2013, 17:51:18 schrieb Dmitry Timoshkov:
Wolfgang Walter wine@stwm.de wrote:
When we send 17 bytes with 150 baud, no parity, one stop bit then we need to wait at least 17*10/150 seconds > 1000 ms
Under Windows with both real COM-port and USB-serial cable this test takes no longer than 890 ms, usually it's even shorter like 875 ms. Testbot VMs also don't fail this test. If under Wine it takes > 1000 ms for you then probably there is a bug somewhere.
How can that be? If you send 17 bytes which expands to 170 raw bits and you only sent 150 bits/s?
Maybe you are using a virtual machine or your com port does not support 150 baud and chooses a different speed. Or you use a UART with a large buffer and which already signals TX-EMPTY even if it is still sending from an internal buffer. But one should not rely on that.
I'm testing under 64-bit Windows 7 on real hardware.
Then it is your UART or it's driver. As I sad: you need 1133 ms to transmit 17 bytes and I think one should not wait less. Otherwise one depends on hardware, driver internals (linux as windows) and scheduling. One should even wait longer (that is the reason I add TIMEOUT).
Regards,
-
Dmitry Timoshkov -
Wolfgang Walter