Date: Tue, 25 Nov 1997 20:10: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: <199711250910.UAA29294@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>>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 I was writing about the error case. >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 Yes, but you should use the standard i386 function insb() instead of raw asm (it gives the same code as good asm). I tried using it for output, but it was no faster than repeated outb()s on my system. >write the burst into one contiguous area even in the case where it >extends beyond the "virtual" end. Good trick. >>>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. Sorry, the usual ISA case is most important. >> 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. It does care. After an irq has been acked, the edge latch remains set until the irq goes low (or at least until it is low when sampled on the next bus clock cycle). The handler must not return with the edge latch set, at least for 16x50 devices, since if the edge latch is set then there must be a device irq and returning would give up the only chance of handling the irq. >>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 See above. >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. The CPU won't see the rising edge if the level is already high from an IRQ on another UART. >As you wish. If I find some time to hack mine, I hope you won't mind >more questions about sio.c. Not quite so many questions as before now, please. >>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. 3 in siointr1(). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711250910.UAA29294>