Re: input lag on /dev/ttyACM0?
On Wed, 29 Oct 2025 at 00:48, Arina Lynn Grace
<arinalynngrace@protonmail.com> wrote:
> I'm trying to get serial data from a microcontroller board (Adafruit
> Feather RP2350) for debug purposes. My test code sends out an
> incrementing number every x seconds. If x == 1 second, it works no
> problem with any serial monitor (such as tio, minicom, or the Arduno
> IDE). However, if x >= 2.3 seconds, the data stops after a message or
> two. The serial port doesn't disconnect when the issue occurs, I only get
> disconnect alerts when I reset or physically unplug the board. I have
> tried multiple microcontroller boards from multiple brands, I've switched
> cables, USB ports, nothing works. This issue occurs on my Debian 12
> Framework 13 laptop and my partner's Debian 13 Thinkpad T480s, but not my
> Debian 10 server, my freshly reflashed Raspberry Pi 3, or my WIndows 10
> PC. Those computers accept the data just fine. I know the code is running
> properly on the boards because I set the built in LED to flash every time
> a serial message is sent out. The common factor seems to be our laptops.
> I have checked lsof /dev/ttyACM0 to rule out other software grabbing the
> serial port, I've checked udev and stty rules (well, my partner did) to
> the best of my (well, her) ability, everything is identical between the
> different computers serial settings. My partner updated her kernel to the
> latest version and it still occurs.
> I'm out of ideas, and this issue has completely stopped my personal
> projects. Does anyone have any ideas what could be going wrong?
Hi,
Is this your post?:
https://www.reddit.com/r/debian/comments/1ohvn18/serial_timeout_on_devttyacm0/
The additional information you give there about 'cat' sounds like
a buffering issue. Maybe someone here knows what you should be sending to
the port to flush the USB buffer, if that is possible.
But maybe it isn't possible, here's some info that looks relevant:
https://stackoverflow.com/questions/13013387/clearing-the-serial-ports-buffer
Quoting from one of the answers there:
The cause of this problem lies in using a USB serial port. If you use
a regular serial port, you will not have this problem.
Most USB serial port drivers don't support flushing properly, probably
because there's no way of knowing if there's still data in the internal
shift register, FIFO or in the USB subsystem.
See also Greg's [1] reply to a similar problem reported earlier here.
[...]
Unfortunately there is no solution other than using a regular serial
port.
At [1] Greg Kroah-Hartman, a leading Linux kernel developer, wrote this:
As for the flush command, this driver does not directly support that,
probably because it can not determine when the data is really sent out
the serial port at the end of the usb device (a common problems for
a lot of usb to serial devices.) So there's nothing we can do for that
here, sorry.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=5730
Reply to: