tarm / serial

BSD 3-Clause "New" or "Revised" License
1.6k stars 451 forks source link

windows serial read anomaly #90

Closed rayozzie closed 5 years ago

rayozzie commented 5 years ago

Hello. Thank you for this project; I've used in a number of test tools I've built, and it has saved me an immense amount of time.

Today I ported, from Mac to Windows, something that I've used for nearly a year that just does something incredibly simple: echo.

I've got a device on my pc/mac's serial port that intermittently transmits newline-delimited text messages. The transmit on the send side happens to be in 63-byte chunks, with a minor (tens of milliseconds) delay between the chunks, and then the final flushed segment typically less than 63 bytes.

In most cases the transmitter sends about a half dozen newline-delimited lines at a time, then pauses for about 30s, and then does it again.

On my receive side, I've got a super simple tarm serial.Read() loop that echos what it sees coming in. (I've validated this behavior with my code, and also with the stripped down simple serial loop in your basic_test.)

When I run the code on the mac, as I said, it works perfectly. It just echo's what I see coming in: a burst of newline-delimited lines, then a gap, then another burst of lines, etc. It looks something like this:

SYNC POWER ON: HIGH, USB, USART1, LPUART1, I2C3, DMA1, DMAMUX1 (was SLEEP) SYNC POWER OFF: HIGH, USB, USART1, LPUART1, I2C3, DMA1, DMAMUX1 (was NORMAL) SERIAL POWER ON: HIGH, USB, USART1, LPUART1, I2C3, DMA1, DMAMUX1 (was SLEEP) SERIAL POWER OFF: HIGH, USB, USART1, LPUART1, I2C3, DMA1, DMAMUX1 (was NORMAL) ...then a delay, and then... SYNC POWER ON: HIGH, USB, USART1, LPUART1, I2C3, DMA1, DMAMUX1 (was SLEEP) SYNC POWER OFF: HIGH, USB, USART1, LPUART1, I2C3, DMA1, DMAMUX1 (was NORMAL) SERIAL POWER ON: HIGH, USB, USART1, LPUART1, I2C3, DMA1, DMAMUX1 (was SLEEP) SERIAL POWER OFF: HIGH, USB, USART1, LPUART1, I2C3, DMA1, DMAMUX1 (was NORMAL) ..etc

When I run the code on windows, though, I see the burst of lines until the final line - but there's always a problem on that final line of the burst which appears as a partial line. It looks something like this:

SYNC POWER ON: HIGH, USB, USART1, LPUART1, I2C3, DMA1, DMAMUX1 (was SLEEP) SYNC POWER OFF: HIGH, USB, USART1, LPUART1, I2C3, DMA1, DMAMUX1 (was NORMAL) SERIAL POWER ON: HIGH, USB, USART1, LPUART1, I2C3, DMA1, DMAMUX1 (was SLEEP) SERIAL POWER OFF: HIGH, USB, USART1, LPUART1, I2C3, DMA1, DMA ...then the usual 30s gap, and then... MUX1 (was NORMAL) SYNC POWER ON: HIGH, USB, USART1, LPUART1, I2C3, DMA1, DMAMUX1 (was SLEEP) SYNC POWER OFF: HIGH, USB, USART1, LPUART1, I2C3, DMA1, DMAMUX1 (was NORMAL) SERIAL POWER ON: HIGH, USB, USART1, LPUART1, I2C3, DMA1, DMAMUX1 (was SLEEP) SERIAL POWER OFF: HIGH, USB, USART1, LPUART1, I2C3, DMA1, DMA ...etc.

I have added a 5-second read timeout and debugging code that shows that after that partial line is displayed, I properly get the read timeout - but the returned length is 0 of course, even though it is buffered somewhere.

The missing text always is received the moment the next single character comes inbound.

Thoughts?

rayozzie commented 5 years ago

NEVERMIND - this was a false report.

I finally resorted to using CoolTerm to actually watch the same output, and was amazed at seeing largely the same behavior.

I figured out that the issue was corrected in this way: 1) open Control Panel -> Device Manager -> Ports (COM & LPT) 2) right-click for USB Serial Device Properties on the appropriate port 3) Port Settings tab 4) Click Advanced... button 5) UN-CHECK "Use FIFO buffers"

I don't understand why, but...

Sigh. Apologies.