bug#25398: stty: bug or feature?

[Pádraig Brady]

On 08/01/17 18:14, Dave B wrote:
> Hi.
> 
> While arranging to automate the startup and shutdown of my ham radio
> station, for safe remote control use, attempting to do as much as
> possible with native Linux commands and tools, I found stty has a rather
> annoying "feature", or even a bug..
> 
> This is on Linux Mint, 17.2 with the Cinamon desktop environment.  Mint
> 18.x seems to have more serious issues, but I'm not sure if it's the OS,
> PC or serial hardware on that system, hence reverting to a 17.x system.
> 
> Anyway.
> 
> After some hours experimenting, and a lot of Googling, I can see that
> many others have come across the same issue, in respect to using Linux
> to program and control Arduino devices, where more often than not, the
> devices are reset at inapropriate times.
> 
> This is all related to the way a serial port DTR control line is
> handled.   Arduino's use it as a reset line, my radio uses it as a
> "Transmit" command line.
> 
> In essence..
> 
> a bash script in the form...
> 
> #!/bin/bash
> 
> stty -F /dev/ttyUSB0 57600 -hupcl crtscts cs8 -cstopb -parity
> echo -n 'EX0270001;' > /dev/ttyUSB0
> sleep 1s
> echo -n 'PS0;' > /dev/ttyUSB0
> 
> Would once the port is open, send the command to prevent the radio from
> going into transmit, wait for 1s for that to process, then send the
> command to power off.   This is does..
> 
> But...
> 
> Other software that is used to do the real remote control work, PRIOR to
> me wanting to shut it all down with that script, obviously sets the
> serial port so that the DTR line can be used...
> 
> So, when the above script is run, DTR is immediately asserted, DESPITE
> "-hupcl" being specified.  (If I try using -cdtrdsr that results
> in:-     stty: invalid argument ‘-cdtrdsr’  )

That's because your kernel doesn't carry this patch:
https://lwn.net/Articles/293523/
That is available on RHEL6, though not on Centos 7 (I don't have access to 
RHEL7).

> Plus, is the cdtrdsr parameter actually allowed to b negated, as
> specified in the man pages.

The man pages (and stty --help) were improved recently
to not mention options not supported on the system

> Would it be possible "one day" for stty to parse the command line args,
> and only open the port when all the specified parameters are actualy in
> force?

That would be better. It's even mentioned as a FIXME:
https://github.com/coreutils/coreutils/blob/229431d/src/stty.c#L1182-L1185

> I and many have found, that if you "do something" with the port,
> specifying -hucpl, as the system boots, though at that time DTR is
> briefly asserted, for subsequent invocations it is not.   Unless, a
> third party program or tool sets it to be used again.

There seems to be some default kernel timing involved here,
which might be controlled with `setserial close_delay ...`.
Another option might be to hack a cable to connect DTR to CTS etc.
to allow using CTS/RTS hardward flow control settings to control things?

cheers,
Pádraig