screen-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Screen Disconnects From Serial Port With No Message


From: R0b0t1
Subject: Re: Screen Disconnects From Serial Port With No Message
Date: Sat, 26 May 2018 23:00:33 -0500

On Fri, May 25, 2018 at 2:35 PM, Amadeusz Sławiński <address@hidden> wrote:
> On Sun, 20 May 2018 02:00:18 -0500
> R0b0t1 <address@hidden> wrote:
>
>> Hello,
>>
>> When using pyserial, I believe the error is something like "device
>> notified ready but no bytes to read." Screen may or may not be
>> encountering the same condition.
>>
>> This is happening over a USB serial adapter connected to an embedded
>> system. During early boot the connection will be interrupted 2 or 3
>> times in quick succession. Afterwards the connection is much more
>> stable but disconnects still occur.
>>
>> The cause isn't something obvious such as crossed wires or me touching
>> something.
>>
>>
>> Based on the error I received with pyserial I think it may be possible
>> to write some C code to get around this problem, but that will quickly
>> become more trouble than it's worth as many many programs have no
>> uniform interface to disable their output of terminal control
>> characters.
>>
>> Cheers,
>>      R0b0t1
>>
>> _______________________________________________
>> screen-users mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/screen-users
>
> Hi,
>
> well, I can't do much without knowing the exact nature of problem, and
> it sounds more, like your serial device is behaving in unspecified way
> than that screen is broken.
>

I think the serial device is sending "interrupts" via USB because some
serial state changed. That or the connection is bad. Regardless - a
read of zero is not an error. It might be strange, especially from an
actual USART, but a USB coupled UART can send a USB packet of length
zero back to the host.

It's not really clear to me how the Linux driver stack would handle
this, but USB TTY devices do some strange things or leave
functionality out. E.g., no need for a speed ioctl implementation if
you never drive an actual USART, and this ends up needing workarounds
in kernel code.

> Anyway if you want to take a look at it, check win_readev_fn function in
> window.c
>
> Seeing that pythons tells that no bytes to read, maybe look at that
> line:
> https://git.savannah.gnu.org/cgit/screen.git/tree/src/window.c?h=screen-v4#n1913
> or maybe check if it returns some errno in checks above.
>

Thank you for the pointer, I will try my best to remember to follow up
with this. It is entirely possible I will find a workaround and
forget.

Cheers,
     R0b0t1



reply via email to

[Prev in Thread] Current Thread [Next in Thread]