From owner-freebsd-hackers@freebsd.org Thu Oct 19 16:58:38 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CFD21E40800 for ; Thu, 19 Oct 2017 16:58:38 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B72870EA7 for ; Thu, 19 Oct 2017 16:58:38 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: bef7f734-b4ee-11e7-a893-25625093991c X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id bef7f734-b4ee-11e7-a893-25625093991c; Thu, 19 Oct 2017 16:58:37 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v9JGwWFd008811; Thu, 19 Oct 2017 10:58:32 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1508432312.1383.18.camel@freebsd.org> Subject: Re: We do serial differently. From: Ian Lepore To: Zaphod Beeblebrox Cc: FreeBSD Hackers Date: Thu, 19 Oct 2017 10:58:32 -0600 In-Reply-To: References: <1508425713.1383.6.camel@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2017 16:58:38 -0000 On Thu, 2017-10-19 at 12:33 -0400, Zaphod Beeblebrox wrote: > On Thu, Oct 19, 2017 at 11:08 AM, Ian Lepore wrote: > > > > > > > Use the "callout" device, /dev/cuaXX, rather than /dev/ttyXX (which > > is > > the "callin" device).  The callin device waits for a call to come > > in, > > and that's implemented by blocking in open() until the modem/other- > > end > > asserts DTR (or DSR, I can never remember which end is which). > > > > So if it's hanging with /dev/ttyU0 use /dev/cuaU0. > > > Is the reverse true?  I have been using cuaU0. No, the reverse is not true.  If you're already using the cua* device the problem is elsewhere. My notes for the DTR pin on an FTDI chip say this: [3] Coming out of reset, this pin is driven high.  When the tty device is open it is driven low.  As long as the channel is in uart mode, this pin will be driven high when nobody has the tty open, and driven low while it is open. Note that that really describes the tty-layer behavior, it's what tells the ftdi chip to turn dtr on and off, so it should apply to other brands of usb adapter as well. Looking at that page you cited in your original message and how it talks about a dtr connection to reset, this might be the problem.  You can try "stty -f /dev/cuaU0 -hupcl" -- that will force the signal to be driven low continuously, regardless of whether anyone has the device open or not.  But there's no telling if that's the right behavior for your arduino, it might just be differently-wrong, like never doing the reset at all.  If the line needs to be pulsed to do a reset maybe you can use a wrapper script that does stty hupcl; sleep .1; stty -hupcl, then launches your program. -- Ian