You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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?
The text was updated successfully, but these errors were encountered: