On Wed, 13 Mar 2013, Richard Guy Briggs wrote: > On Wed, Mar 13, 2013 at 09:10:49AM -0400, Aidan Van Dyk wrote: > > kill -9 will absolutely prevent *minicom* from resetting the modem. With > > kill -9 (-KILL), minicom is gone, it can't reset it. That's the point of > > -KILL. > > > > But as the kernel device is closed when minicom is killed, whatever driver > > is responsible for it may be doing something... > > > > I know this is the whole "use the tool you know" thing, but it might be > > better to use something intended for "scripting" serial ports, or even fall > > back to setserial and if you don't like io in bash, expect (or perl even if > > tk isn't your thing). > > This is a very timely question Robert... > > A couple of days ago I was fighting with a ttyACM device. It is embedded in a Teensy3.0 that is now running this: > http://smart_panel.tricolour.ca/ > http://tricolour.ca/photos/2013/02/19/ > > I have been developing on and running Arduinos for more than a year on 3 > different ancient machines running Debian Squeeze or Wheezy and more recently > the Teensy3.0 without seeing this problem, then just this past weekend, I tried > to connect the Teensy to a different machine running Wheezy and I'd get one > line of text output (~350 chars), then after a 5 second pause in the output, > the line would lock up. I was using a perl script with a shell call to stty, > then open(), select(), read(), also using cat(1) and minicom(1) and all were > locking up. This also happenned on a brand new Thinkpad running bleeding edge > fedora rawhide, but not a brand new workstation running RHEL6.4. > > The stty call was: > stty -F /dev/ttyACM$deviceno 115200 -parenb -cstopb cs8 > > After beating my head on this for a while, someone suggested using "screen > /dev/ttyACM0", then killing that with "^Aky" which worked fine to initialize > that device in both places. Huh? > > The problem with killing minicom is it will leave behind a /var/lock/ttyACM0 > file that needs to be removed before some programs will try to talk to it. i'll be able to digest all this later, but i just discovered that the minicom that was running on the target system is an older version for which a newer version fixed this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610512 which is exactly what i was seeing -- i was testing initially on my ubuntu laptop and things worked pretty well where minicom is version 2.5, but the version of minicom on the target system is 2.3, so i'll be cross-compiling and testing shortly. but i'm certainly open to the suggestion of dumping minicom for something more appropriate. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================