From owner-freebsd-current@FreeBSD.ORG Sat Jul 5 21:50:57 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B72A01065672; Sat, 5 Jul 2008 21:50:57 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 3AA688FC12; Sat, 5 Jul 2008 21:50:57 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id m65LosZR096345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 5 Jul 2008 23:50:54 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id m65LoXNJ032132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Jul 2008 23:50:33 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id m65LoXGK042724; Sat, 5 Jul 2008 23:50:33 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id m65LoWHC042723; Sat, 5 Jul 2008 23:50:32 +0200 (CEST) (envelope-from ticso) Date: Sat, 5 Jul 2008 23:50:32 +0200 From: Bernd Walter To: Hans Petter Selasky Message-ID: <20080705215032.GG41487@cicely7.cicely.de> References: <20080703140719.GA72315@onelab2.iet.unipi.it> <200807050957.07900.hselasky@c2i.net> <20080705162426.GD41487@cicely7.cicely.de> <200807052256.15792.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200807052256.15792.hselasky@c2i.net> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.104, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: usb@freebsd.org, Luigi Rizzo , freebsd-current@freebsd.org, ticso@cicely.de, current@freebsd.org Subject: Re: may I commit this small umodem patch ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2008 21:50:57 -0000 On Sat, Jul 05, 2008 at 10:56:14PM +0200, Hans Petter Selasky wrote: > On Saturday 05 July 2008, Bernd Walter wrote: > > On Sat, Jul 05, 2008 at 09:57:06AM +0200, Hans Petter Selasky wrote: > > > > > > Yes, but you know that umodem can drop data, if the buffers overflow ? > > > > Do you mean the driver can loose data? > > It would be good if this is avoidable somehow. > > In fact those beasts have some kind of pseudo flow control in that they > > don't ack further packets. > > Basicly this is nothing more than using a pair of bulk pipes for raw > > data, but under the hood of CDC identification. > > I personally only use them for uploading firmware to AT91SAM7* > > controllers, as luigi does, but since Windows and Linux have generic > > drivers this is quite popular. > > From what I know the TTY layer which umodem uses will dump data when the > buffers are full. But it there is some kind of framing in the protocol used, > then this is no problem. Well - the problem is that there is not special protocol. This technology is used as a general purpose interface for almost every kind of application that. Most protocols are using smal transactions, but this is general purpos after all. This is quite similar as devices using embedded uart or something like the FT245 pseudo uart chips from FTDI. I asume even most modern cell phones don't use real uarts. I wonder what happens with real USB RS232 with activated RTS/CTS. The handshake is handled in the USB device and not under FreeBSD, because the USB devices have too large buffers for the OS to react fast enough. Can we loose data as well? If yes we have a problem there as well. If not, then there must be some kind of mechanism to sync TTY layer with the USB transport speed and we can use the same for pseudo uart. I don't think we should drop data ourself, since we have USB handshake for speed syncronisation. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.