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
