Date: Tue, 25 Nov 1997 03:16:08 GMT From: mouth@ibm.net (John Kelly) To: Bruce Evans <bde@zeta.org.au> Cc: hackers@freebsd.org Subject: Re: Status of 650 UART support Message-ID: <347d42b4.7857680@smtp-gw01.ny.us.ibm.net> In-Reply-To: <199711240628.RAA01234@godzilla.zeta.org.au> References: <199711240628.RAA01234@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 24 Nov 1997 17:28:47 +1100, Bruce Evans <bde@zeta.org.au> wrote: >simplest approach leads to 3 i/o's per byte of input instead of 2 >(IIR, LSR, RXDATA) instrad of (LSR, RXDATA). Not in my code. I can read the IIR once, and if checking the LSR reveals no errors, and the IIR indicates a FIFO interrupt (as opposed to FIFO timeout), I have a FIFO of bytes, full at least to the trigger level I previously set in the FCR, and I can safely read them all with one in-line assembler REP INSB instruction emitted by Turbo C (can GCC do that?). I've implemented a circular buffer which lets me write the burst into one contiguous area even in the case where it extends beyond the "virtual" end. With a 650 UART set for a FIFO trigger level of 24 bytes, I only add two INB's of overhead to a burst of 24 bytes. That's a worthwhile improvement. >>I changed my own copy of sioprobe to drive the IRQ output, letting >>each UART pull its line to ground during sioprobe. >You mean all at the start? It's not very nice to drive sio1-N in >the probe for sio0. Why not? That is exactly what you want to do if you have several inputs feeding an OR gate. You never want an OR gate input floating. True, If a user has the classic COM1/COM3 conflict neither one will probe correctly. But that's the way it should be. >>Anyway, I want to purse this issue of whether looping in siointr is >>"necessary to get an interrupt edge," because it has a direct impact >>on how siointr might be improved with UART burst mode input. > >It's certainly necessary for simple OR gates. The IRQ outputs of the >UARTs are independent True. > so there is no guarantee that a falling edge on one will make it to the > output of the OR gate. After building and testing such a device myself, I still don't understand what you're driving at here. Of what consequence is a falling edge on any of the UART INT outputs? The PIC which ultimately receives the electrical signal as output from the OR gate has no care for falling edges, only rising ones. >The code being discussed is for multiport cards >with (simple) hardware logic for IRQ sharing. Not-so-simple hardware >might have a way to force an edge, but siointr() is for the general >case so it can't have support for or dependencies on this. I don't understand this either. In the case of an OR gate which implements, as you say, "(simple) hardware logic for IRQ sharing," why is there a need to "force an edge" at all? The OR gate is simply going to alternate its output between +5v when any input is true, and ground when all inputs are false. When it changes its output from ground to +5v, the PIC sees the rising edge and recognizes an interrupt. The OR gate acts as a buffer between the independent UART INT outputs and the input of the PIC. It seems so simple to me. What am I missing? >>I wrote a code fragment ... if you want to see it. >Not really. I think I know what to do, butnot how to integrate it. As you wish. If I find some time to hack mine, I hope you won't mind more questions about sio.c. >>I'm never satisfied with my C code until I've eliminated all goto >> statements. > >There's only 3 in the standard version and they're just to get out >of error cases :-) I counted 16 in the -current version. John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?347d42b4.7857680>