Date: Wed, 15 Nov 1995 22:17:24 +1100 From: Bruce Evans <bde@zeta.org.au> To: imb@scgt.oz.au, julian@ref.tfs.com Cc: current@freebsd.org, uhclem%nemesis@fw.ast.com Subject: Re: Serial HW flow control [was ISP state their FreeBSD concerns] Message-ID: <199511151117.WAA00366@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> > 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. Up to 17 characters may be received after CTS is deasserted (1 currently in flight and up to 16 in the FIFO). >> 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. An interrupt normally occurs when the FIFO becomes empty. This allows one character time for the interrupt handler (if any) to refill the FIFO without loss of transmission time. Since there is no way to tell how many characters are in the FIFO, it isn't useful to flush the FIFO and backtrack when a CTS drop is detected. >> > 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!). Well, disabling the FIFO is sort of supported (set 0x0002 in the driver flags) and has "only" 4 times as much overhead for output on a 486DX2/66 (12% vs 3% for 115200 bps) and only 2.5 times as much overhead for input (16% vs 6.5%). It would be easy to change the effective output FIFO size in software (change tx_fifo_size in sio.c from 16 to a smaller value). >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.. I learned how to write serial drivers on old Televideo terminals. They had a 256 byte buffer with 64 bytes headroom IIRC. >14 characters? >most such devices have headroom figures of 128 bytes or 256 bytes.. The Televideo's couldn't handle much faster than 9600 bps. 128 or 256 is about right for 115200 bps. sio itself (as a receiver) allows for 64 (worst case) and (256 - speed_in_cps / 100) (usual case). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511151117.WAA00366>