Date: Thu, 13 Nov 1997 18:37:56 +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: <199711130737.SAA02104@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>>>Did you know that the 650 UART has on-chip "auto" RTS flow control > >>On some (early? all?) 16650s it is said to be just a pessimization >>to use it, since it is invoked when the trigger level is reached, >>so it is invoked for almost every input interrupt. > >It may seem like a pessimization if your ISR always starts quickly >enough to avoid UART overruns. However, when using a 550 UART, My ISRs always do :-). >presumably the serial ISR could safely raise RTS as its first duty >when the FIFO trigger level has been reached, since the external >device would be expected to have a large buffer of its own. If true, >then why not have the 650 chip raise RTS automatically? That buys It is unkind to the external device. It would approximately triple the number of interrupts for a similar device that is only sending. E.g., for a sender that sends 32 bytes at a time, and a receiver with a trigger level of 28, there would be about two useless modem status change interrupts in the sender for every 32 bytes sent. >Does the sio.c ISR raise RTS when servicing a UART trigger level >interrupt, or does it simply drain the UART FIFO while letting the >external device keep streaming inbound bytes? If the latter is true, >>I don't know what happens when the driver sets RTS directly. > >The Startech databook says: > >> 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. >> RTS pin resumes it original state after content of the >> data buffer (FIFO) drops below the next lower trigger level. >> ... hardware ... flow controls can be enabled for automatic >> operation. During these conditions the ST16C650 will accept >> additional data to fill the unused ... recieve FIFO locations. This is OK. >2) Receive (not transmit) FIFO trigger levels, 550 vs. 650: > >=46CR bit 7 and 6 550 650 > 00 1 8 > 01 4 16 > 10 8 24 > 11 14 28 > >If the software driver sets FCR to "10" as you would expect in the >case of a 550 UART, the 650 trigger level will actually be 24 and the >next lower trigger level will be 16. The excerpt from the databook sio actually uses 11. This gives a useful reduction of input inputs vs. 10 and doesn't cause slo overflows for normal setups with <= 4 ports and no (broken) bus-hogging DMA controllers. >>I think the best available setup is to use 16550 mode with the tx fifo >>size set to match the flow control. The 16650 configuration is too >>specific - it forces 16650 flow control and a 32 byte tx fifo size. > >I don't follow you here. FCR bits 5 and 4 on the 650 allow setting >the transmit FIFO to 16, 8, 24, or 30. The default is 16. However, >none of these are in effect unless, as the databook says: > >> ... user can write to transmit trigger levels but activation will not >> take place till ST16C650 special mode is selected (EFR bit-4 >> is set to "1"). > >> ... to be compatible with ... 550, 1 bytes transmit trigger level is >> selected after reset. > >So if you don't set EFR bit 4, the 650 transmit FIFO is still only one >byte just like a 550. And I don't recall seeing any code in sio.c to >set EFR bit 4. It only sets the software tx_fifo_size to 32. This is apparently the default if the fifos are enabled in the 16550 way. This is 16550- compatible because the space in the fifo is not readable so 16550 drivers would only ever put 16 bytes in the fifo. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711130737.SAA02104>