Date: Thu, 20 Nov 1997 18:37:00 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, mouth@ibm.net Cc: hackers@freebsd.org Subject: Re: Status of 650 UART support Message-ID: <199711200737.SAA28030@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>>Altogether, with saturated input and no output it takes at least about >>8*37 =3D 296 usec.=20 > >Where you say 2*32 + 1*32 +5, I thought you meant two I/O for each >input byte and one I/O for each output byte. But later you say 37 (32 Right. >+ 5) I/O for saturated input, which would mean only one I/O for each >input byte, so now I wonder if you meant the opposite -- two I/O for >each output byte and one I/O for each input byte. I mean 2*16 + 5. This assumes a trigger level of 16. There will always be 16 bytes for saturated input and no interrupts except for input. There may be up to 16 more bytes if we can barely keep up. >But that doesn't sound right -- don't I need to read bit 0 of the line >status register before trying to read a byte from the receiver FIFO, >so that I'll know when I've emptied the receiver FIFO? That would >give two I/O per input byte. I think you can actually ready bit 7 to see if there is a full fifo (with no parity/framing/overrun errors) and, if it is set, read the entire fifo before reading the LSR again. This gives close to one I/O per input byte. It is a bit tricky to handle error cases and quitting properly - we don't want to fall back to two I/O's per input byte. Another character may have arrived, and if the fifo is larger than we know about, there may be many more characters to process. ISTR that there is more setup overhead but can't see it now. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711200737.SAA28030>