Date: Fri, 14 Nov 1997 20:28:05 +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: <199711140928.UAA25820@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>>>> RTS pin will be forced to high state regardless of its original >>>> state when receive FIFO reaches to the programmed trigger level. >> >>So the pessimization is standard on Startechs :-(. The RTS trigger >>level should be slightly higher than the FIFO trigger level. > >Not standard. It's only activated if you set EFR bit 6 to 1, which >sio.c apparently does for a 650. That's not much help. You get either no auto RTS flow control or pessimized auto RTS flow control. Auto CTS flow control is more useful. >I have a near worst case scenario. I have an interrupt-sharing >multiport serial adapter with eight 650s all sharing one interrupt. >The clock for each UART can be individually set (via hardware jumper) >to 1.8432MHz, 3.6864MHz, or 7.3728MHz, for a maximum port speed of >115.2k, 230.4k, or 460.8k. You'll need bigger buffers and maybe smaller fifo trigger levels for this, at least above 115.2k. The extra headroom provided by the 16650 may be enough at 115.2k. >I seem to recall from sio.c that in the case of a multiport serial >adapter, the ISR itself will look at every port and try to drain it. =20 I don't like it much, but decided to leave it alone because it is efficient enough and if many ports are concurrently active, and otherwise you probably have cycles to spare. >Since reducing input interrupts is a worthy goal, why not enable auto >RTS and simply run the 650 receive FIFO in polled mode? You could >start up in normal interrupt driven mode and jump to polled mode when >data starts streaming in. With the auto RTS feature activated, the I'm not sure what you mean here. If you mean a low priority polled mode, then it won't work because ports with data streaming in must be given high priority so that the polling doesn't get interrupted. If you mean a really normal (non-fast) interrupt driven mode and a high priority polled mode (essentially fast interrupt mode with CPU interrupts disabled), then it won't work because normal interrupt driven mode doesn't have enough priority to always get the polling started early enough. Complicated variations of these schemes (based on scheduling all interrupt handlers to limit latency) can work. >650 will suspend the inbound data stream from the external device when >necessary to prevent UART overruns, as the external device would be >expected to have a large (2k? 4k?) buffer of its own to accumulate >inbound data until the 650 gives it the green light again. The external device may not be able to stop in time, and you lose input. If it stops, then you lose throughput. You don't want either unless you are overloaded. Then losing throughput automatically is good, and the amount of lost input may be smaller. >In the case of a multiport serial adapter, each port could have a flag >in sio.c which tells whether it's working in polled mode or interrupt >mode. Whenever you poll the ports which are streaming data in, you >would only have to check the ones which have their polling flag on, >because any of the other ports not being polled would still get your >attention by means of an interrupt. I don't see how to make this work with edge-triggered interrupts. E.g., suppose no ports are active and we get an interrupt. Then all ports must be in interrupt mode and we have to check them all and turn off the interrupt enables for those that are generating an interrupt. Then we return from the interrupt and switch to polled mode. This costs more than the current checking. We still have to check all ports (an average of 1.5 times around the loop for an average active port found half way round the loop). There are extra costs for context switching and toggling the interrupt enables. >With a multiport serial adapter, that would eliminate some of the >present overhead in the ISR where you have to check each port for >inbound data every time the ISR runs. The ISR would still have to >check each port which does not have its polling flag on, but as port >usage increases, that ISR overhead would decrease. There should be an average of signifcantly less than 1 port with its polling flag on! An average of 1 means that the system is polling serial ports almost 100% of the time. The relative overhead for searching for active ports also decreases as the port usage increases. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711140928.UAA25820>