Date: Tue, 14 Nov 1995 13:35:16 -0800 (PST) From: Julian Elischer <julian@ref.tfs.com> To: imb@scgt.oz.au (michael butler) Cc: uhclem%nemesis@fw.ast.com, current@freebsd.org Subject: Re: Serial HW flow control [was ISP state their FreeBSD concerns] Message-ID: <199511142135.NAA28568@ref.tfs.com> In-Reply-To: <199511141704.EAA17910@asstdc.scgt.oz.au> from "michael butler" at Nov 15, 95 04:04:26 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > Frank Durda IV writes: > > > One of the ISPs is trying to let me borrow his communications monitor > > so I can see exactly what they are talking about. They claim it will > > show that they drop CTS and the processor has sent as many as 14 additional > > characters after CTS was deasserted. If true, it sounds like our > > hardware flow control does not "call-back" bytes already in the 16550 FIFO > > like it should. > > You can't anyway .. once loaded with 16 bytes for transmission, the > withdrawal of CTS only generates an interrupt. To quote the NS spec for the > device "/CTS has no effect on the transmitter". This is quite different to > the behaviour of, say, a Z80 SIO or Z8x30 SCC which disable the transmitter > after the current character has been shifted out. > > There is also absolutely no mechanism provided to discover exactly how many > characters were transmitted prior to the modem status interrupt. Ordinarily, > an interrupt occurs only when the FIFO and shift-register are (completely) > empty. > > > The EIA rules for CTS allow you one more full character plus any partial > > character to be transmitted before the data must cease .. > > Then the 16550 itself is in breach of this spec. and there's nothing anyone > can do about it in software other than to feed it one byte at a time (and > you really don't want to do that!). > > If this actually is the problem, then *every* PC-based O/S must display the > same failing with these devices, not just FreeBSD. The only other possible > issue in this area is the speed with which FreeBSD's driver responds to CTS > changes, There is I believe no hard definition of how many quickly the dropping of CTS will affect the arrival of data.. Most decent devices have a parameter that is effectively "How much headroom should we allow for characters that arrive after CTS is dropped" If your device doesn't have this it's broken.. 14 characters? most such devices have headroom figures of 128 bytes or 256 bytes.. Once you've filled the fifo on the 16550, you can't stop it, you can only NOT feed it more characters when it says's it's hungry again.. > > michael >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511142135.NAA28568>