Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect _COMMTIMEOUTS struct in serial_windows.go #7

Open
dmnef opened this issue Dec 24, 2014 · 4 comments
Open

Incorrect _COMMTIMEOUTS struct in serial_windows.go #7

dmnef opened this issue Dec 24, 2014 · 4 comments

Comments

@dmnef
Copy link

dmnef commented Dec 24, 2014

The correct field order should be like this:

type _COMMTIMEOUTS struct {
    ReadIntervalTimeout         uint32
    ReadTotalTimeoutConstant    uint32
    ReadTotalTimeoutMultiplier  uint32
    WriteTotalTimeoutConstant   uint32
    WriteTotalTimeoutMultiplier uint32
}

See comments there: http://msdn.microsoft.com/en-us/library/windows/desktop/aa363190%28v=vs.85%29.aspx

@lnmx
Copy link
Owner

lnmx commented Dec 29, 2014

Hi @dmnef, thanks for the report.

Both COMMTIMEOUTS and SERIAL_TIMEOUTS show the same field order, with the Multipliers before the Constants. The comments on COMMTIMEOUTS did not make it any clearer.

I would like to run a few tests on my Windows system to see if the fields seem to be swapped, and if so, I will make the change.

@dmnef
Copy link
Author

dmnef commented Dec 29, 2014

Ok, my story:

I tried to communicate with a bootloader residing in an MCU connected via standard FTDI-based USB-to-serial converter.
Communication was simple: my program would send a 12-byte command and wait for an 5-byte answer. I've set a timeout by defining ReadTotalTimeoutConstant to desired value (5000 milliseconds in my case) and zeroing the other fields. I've also set 1 millisecond timeout for VCP.
Because there was only one time-consuming command, most of the time MCU answered almost instantly (about 50us) and the interval between communication sessions was expected to be the same as VCP's timeout -- 1ms.
I have already tried the same setup using Python and pyserial lib and everything worked as expected.
But writing almost the same program in Go i've run into a strange performance problem: the interval was unstable and about 16ms (strange -- because VCP's default timeout value is also 16ms).

Problem was solved by swapping mentioned fields.

@lnmx
Copy link
Owner

lnmx commented Dec 29, 2014

Hi @dmnef, I added examples/timeout to test this out. With a USB-to-Serial adapter (nothing connected to the serial end), I set the timeouts and attempt to read some bytes. The Read() call should block for read_constant+(read_length*read_multiplier) before returning 0 bytes.

For read_constant=500, read_length=10 and read_multiplier=100, I get:

read = 0, time = 1500 ms, err = <nil>

...as expected. If the fields were backwards, I expect the timeout to happen at 5100ms.

Could you try this example in your environment and see if you get different results?

@dmnef
Copy link
Author

dmnef commented Jan 12, 2015

I tried. Got exactly same results. Sorry for misleading.

Although the problem i've mentioned still exists.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants