From owner-freebsd-hackers@freebsd.org Fri Oct 20 14:00:13 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 BD069E362E4 for ; Fri, 20 Oct 2017 14:00:13 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: from mail-it0-f50.google.com (mail-it0-f50.google.com [209.85.214.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 88C9C77350; Fri, 20 Oct 2017 14:00:12 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mail-it0-f50.google.com with SMTP id r127so13503312itb.5; Fri, 20 Oct 2017 07:00:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WqPvvKTFXjPEwcGrvWFB4UMbnBwzh9S8DvZZxsL2s8w=; b=FFHVFsf7g3Q3aRlEu1t07k+Plw9B8fFrUvRUt7BdbDq5A8YJAhNNyc9fJNmeb8UsGs +IbHqSNZxojHhEqerW9Fy8NEHWDEHU7bg/B4XvF1C6VNIKMbhj5+YsoVJzbPC2nTM8Gx QvUmjc9r/+Sw4qcLuMqT+9A20CUK5ogAdhQBPDa+w3a0L/6hoTFPlFVufIzyV13S9j7F s0uCBgV1wIN1orpRzZDSmJg5TUG/MsLUFwtLj9pG2tPfzX3VJlhy+rJ+8DeZ209HYkNl 5iACxDDXMHBVwrldb1cyDzkDy9zi2M53hfLoF4zYgk7/QPt2+e3WecZyUlJLHjPWm3pj M/Rg== X-Gm-Message-State: AMCzsaXjL27jNCb8zLUlCejiywzQnZDzIiqLYwHxEqbvLJgwbu6lPGfs F3tOaGExfc/fJTs1rig1wH4XqXiWPPE= X-Received: by 10.36.124.197 with SMTP id a188mr2605620itd.53.1508506629617; Fri, 20 Oct 2017 06:37:09 -0700 (PDT) Received: from mail-it0-f50.google.com (mail-it0-f50.google.com. [209.85.214.50]) by smtp.gmail.com with ESMTPSA id v8sm511766itb.42.2017.10.20.06.37.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Oct 2017 06:37:09 -0700 (PDT) Received: by mail-it0-f50.google.com with SMTP id o135so13450104itb.0; Fri, 20 Oct 2017 06:37:08 -0700 (PDT) X-Google-Smtp-Source: ABhQp+RwZe6lFyyULE5m6qAcsMkDLFE6DS+nSBRew0dwltCQEEv72Oy87nEaX7L5dP7/JsSFcq4daRjSHu5VDpY362c= X-Received: by 10.36.178.19 with SMTP id u19mr2438288ite.64.1508506628708; Fri, 20 Oct 2017 06:37:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.23.129 with HTTP; Fri, 20 Oct 2017 06:36:48 -0700 (PDT) In-Reply-To: <20171019172246.GU2473@kib.kiev.ua> References: <1508425713.1383.6.camel@freebsd.org> <1508432312.1383.18.camel@freebsd.org> <20171019172246.GU2473@kib.kiev.ua> From: Kyle Evans Date: Fri, 20 Oct 2017 08:36:48 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: We do serial differently. To: Konstantin Belousov Cc: Ian Lepore , FreeBSD Hackers , Zaphod Beeblebrox Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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: Fri, 20 Oct 2017 14:00:13 -0000 On Thu, Oct 19, 2017 at 12:22 PM, Konstantin Belousov wrote: > On Thu, Oct 19, 2017 at 10:58:32AM -0600, Ian Lepore wrote: > > 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. > > For each tty device, including cuaU*, there are .init and .lock > devfs nodes which can be used to set the initial and permanent states of > the flags. It might be useful in this situation. > This doesn't seem to necessarily be true with ucom(4) bits. I put in a bit of effort to try and get devel/libserialport to stop setting DTR when it probes /dev/cuaU* to no avail. As a consequence, connected Arduinos constantly reset when devel/arduino18 is open unless the serial monitor/plotter is also open. I can appreciate that +DTR is a sensible default here, but it would be nice if it could be configured with the .init node.