ser2net
ser2net copied to clipboard
cminyard
Delay uart chars write
Hello, I do have an issue with ser2net, I am using it with uart without flow-control signals, specifically for the linux tty console and we do have issues with chars lost more or less in a systematic way.
The way we envision to workaround this would be to delay the write to the uart depending on some configuration parameter, port->dev_write_handler callback could be improved in a similar way as handle_dev_read to delay chars write with a timer.
What do you think about this feature request?
On Fri, Aug 12, 2022 at 06:21:31AM -0700, Francesco Dolcini wrote:
Hello, I do have an issue with ser2net, I am using it with uart without flow-control signals, specifically for the linux tty console and we do have issues with chars lost more or less in a systematic way.
The way we envision to workaround this would be to delay the write to the uart depending on some configuration parameter,
port->dev_write_handlercallback could be improved in a similar way ashandle_dev_readto delay chars write with a timer.What do you think about this feature request?
Well, that's kind of weird. You are basically going to send the characters at a slower rate. Why not just user a slower port speed? It would accomplish the same thing more reliably and more simply.
You should at least test with a slower port speed. If that doesn't solve the problem, slowing down the characters is not going to solve the problem, either.
If you are talking to the Linux console, that has a pretty deep buffer. If that can't keep up there may be other issues. I just would like to make sure it's really the problem before pursuing something like you are suggesting.
-corey
Yep, correct, we would limit the baudrate in software, in practice.
The specific issue we have is with LAVA, https://docs.lavasoftware.org/lava/debugging.html#differences-in-input-speeds, as you can read the issue there is pretty common.
Manual keyboard entry has noticeable gaps between every key press. Even the fastest typist will not approach the speed at which a computer can transmit the same string over a serial connection. In automation, strings will be sent as quickly as the connection allows. Some devices may then fail to process the characters correctly.
the standard lava solution would be to use test_character_delay, but this once you add ser2net into the mix will just not work as you can immagine since the delay is to a TCP socket, not the actual UART device.
Said that, for our specific environment, lowering the UART baud rate is not an easy option at the moment.
On Fri, Aug 12, 2022 at 07:41:16AM -0700, Francesco Dolcini wrote:
Yep, correct, we would limit the baudrate in software, in practice.
The specific issue we have is with Lava, https://docs.lavasoftware.org/lava/debugging.html#differences-in-input-speeds, as you can read the issue there is pretty common.
Manual keyboard entry has noticeable gaps between every key press. Even the fastest typist will not approach the speed at which a computer can transmit the same string over a serial connection.
the standard lava solution would be to use
test_character_delay, but this once you add ser2net into the mix will just not work as you can immagine since the delay is to a TCP socket, not the actual UART device.Said that, for our specific environment, lowering the UART baud rate is not an easy option at the moment.
Ok. Are you planning to do patches on this? ser2net already has a timer that does something similar, for incoming data, called chardelay. It's basically to collect characters before transmitting them on.
-corey
Ok. Are you planning to do patches on this? ser2net already has a timer that does something similar, for incoming data, called chardelay. It's basically to collect characters before transmitting them on.
Probably yes, but cannot commit to it in the short term. The first thing I was needing to asses if this is a kind of change you would accept a pull request for, and my understanding is that the answer is positive here.
On Fri, Aug 12, 2022 at 08:29:39AM -0700, Francesco Dolcini wrote:
Ok. Are you planning to do patches on this? ser2net already has a timer that does something similar, for incoming data, called chardelay. It's basically to collect characters before transmitting them on.
Probably yes, but cannot commit to it in the short tem. The first thing I was needing to asses if this is a kind of change you would accept a pull request for, and my understanding is that the answer is positive here.
Yes, something like that would be ok.
-corey
-- Reply to this email directly or view it on GitHub: https://github.com/cminyard/ser2net/issues/71#issuecomment-1213235464 You are receiving this because you commented.
Message ID: @.***>