baumann@muon.uucp (Michael Baumann) (08/15/89)
In article <2472@orion.cf.uci.edu> mrichey@orion.cf.uci.edu (Mike Richey) writes: >In article <3017@bucsb.UUCP> apollo@bucsb.UUCP (Doug Chan) writes: >> >Depends on the UARTS you have installed in the RS232 cards. 8250s I believe are >good to 19.2K, then there's the 16450 and 16550. they're rated at 38.4K and >56K baud, i believe. But, the 19.2K for the 8250 must be programmed by >comm software such as procomm, or kermit, etc. I believe MODE only allows >for 9600. I have a few programs that transfer files between PCs using >the COM ports. Lap Link (by toshiba?) and Bridge by White Crane systems >are a couple that come to mind. They transfer data at a maximum of 115KBaud >using 2 wire connect. This is because the UARTS are programmable. They >become unstable at a particular speed, which dependant on the particular >UART that is being used. hope this helps. No. The UART does not "become unstable". However, a number of PC's do. Looking at the data sheets for the 8250B (the ones from Nat. Semi.) I find that the 8250B is rated to 56K W/ 1.8432 MHz clock. The following "error rates" are: at 110 baud 0.026%, at 134.5 baud 0.058%, at 2000 baud 0.69, and at 56K 2.86%. This is NOT an instability, this is a known error rate! It may be possible to squeeze 115Kbaud out of an 8250B by using a divide-by of 1, but that will probably give you an error percent of > 5%. Of course if both ends are off by 5% it doesen't matter, as their clocks are close enough. Remember that the error rate is "Percent Error Difference Between Desired and Actual" (quoted from the table). The real problem is that a number of XT class machines just can't handle the overhead associated with 19.2Kbaud, and greater, interrupt rates. Running at 19.2Kb, assuming 8-N-1, you can get up to 1.92K interrupts per second (assume 1 byte = 10 bits - 1 start,8 data, 1 stop). Since reading the UART takes 2.2us Min. for each read, not including software delays, and that if you have more than one interrupt enabled it takes 2 reads to get data out of the UART, one to ID the interrupt cause, and 1 to read Receive Buffer, and that there is a 1us max delay from the time the stop bit is recognized, and the interrupt is asserted, we are looking at around 5us in chip overhead per character just in the UART. This means that about .01 seconds are used in hardware overhead alone,at 19.2K, at 56K this jumps to almost 0.3, and at 115K you have 0.058. . This does not include the following: 1) time for the 8259 to get and resolve the interrupt, 2)time for the processor to be interrupted, ack the interrupt, and save/restore state, 3) the time to actually process the interrupt in software. Doesn't leave much time for anything else does it? Disclaimers: A lot of the above math was done off the top of my head, and I used both Best Case for read times and worst Case for internal interrupt latency. >Michael Richey Bitnet MRichey@UCI MRichey@orion.cf.uci.edu Michael Baumann ----------------------------------------------------------------------------- Radiation Research Lab |Internet: baumann%proton.UUCP@ucrmath.UCR.EDU Loma Linda Universtiy Medical Center | UUCP: ...ucrmath!proton!baumann Loma Linda, California. (714)824-4077|