On Tue, Jan 7, 2014 at 12:17 PM, Jurjen Oskam <[email protected]> wrote: > Thank you for the responses. I sort of figured out that the stty settings > are set to default each time the device is opened, but now that's confirmed > I ran into the problem that open() does not seem to be returning. > > I created the following simple shell script: > > #!/bin/sh > > ( stty 9600 sane parenb -parodd crtscts cs7 igncr > while read line > do > echo $line > done > ) <>/dev/ttyU0 >&0 > > Running it results in no output at all, without the prompt coming back. > Interrupting the process results in the following ktrace snippet: > > 486 sh 1389125130.342774 CALL > open(0x208ee2c50,0x202<O_RDWR|O_CREAT>,0x1b6<S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP > |S_IROTH|S_IWOTH>) > 486 sh 1389125130.342776 NAMI "/dev/ttyU0" > 486 sh 1389125151.417307 PSIG SIGINT caught handler=0x4214f0 > mask=0<> > 486 sh 1389125151.417312 RET open -1 errno 4 Interrupted system > call > > Looking at the timestamps, the open() only returns when I Ctrl-C the process.
This is where Remco's response comes into play. As described on the tty(4)/cua(4) manpage, /dev/ttyU* blocks on open until the external device signals that it's active via some hardware signal (DTR, iirc). If you want to initiate an outgoing connection to a potentially inactive device, use the matching /dev/cuaU* device. Philip Guenther
