ong@d.cs.okstate.edu (ONG ENG TENG) (01/05/91)
Any one know how to set a serial port to 115k baud? I know how to set it up to 9600 baud and do i/o. But I have seen some software use it at 115k. How do you do it? Please also provide any general serial port hints you have (that is not found in Norton's PC Programmer book). Thanks in advance. E. Teng Ong (ong@d.cs.okstate.edu)
grege@gold.gvg.tek.com (Greg Ebert) (01/08/91)
ong@d.cs.okstate.edu (ONG ENG TENG) writes:
#Any one know how to set a serial port to 115k baud? I know how to
#set it up to 9600 baud and do i/o. But I have seen some software
#use it at 115k. How do you do it? Please also provide any
#general serial port hints you have (that is not found in
#Norton's PC Programmer book).
#
My 16450 data sheet says you can't do it. The AT runs the 16450 with a
1.8432Mhz clock, which is 16x 115Kbaud. Thus, the divisor in the 16450
is 1 (unity). But, the sheet says :
The maximum operating frequency of the baud generator is 3.1Mhz.
However, when using divisors of 3 and below, the maximum frequency
is equal to the divisor in megahertz. For example, if the divisor
is 1, then the maximum frequency is 1 Mhz. In no case should the
data rate exceed 56k baud.
(Reprinted w/o permission)
If you want to play with it anyway, set the divisor to 1. Because you are
exceeding the spec, there is no guarantee that it will work under all
operating conditions. Also, the data rate isn't EXACTLY 115KBps; it's
115.2KBps which is probably close enough.
What, pray tell, are you talking to at this speed ?
----- Boycott redwood products ---------------------------- Recycle -----
Read "The Emperor Wears No Clothes", by Jack Herer #####
{uunet!tektronix!gold!grege} Register to vote, then ## | ##
grege@gold.gvg.tek.com vote responsibly # | #
# /|\ #
Support high oil prices, waste tax $$ on war, evade domestic #/ | \#
problems, and die young on foreign soil- Just say YES to Bush #######williams@umaxc.weeg.uiowa.edu (Kent Williams) (01/08/91)
In article <1839@gold.gvg.tek.com> grege@gold.gvg.tek.com (Greg Ebert) writes: > > ong@d.cs.okstate.edu (ONG ENG TENG) writes: >#Any one know how to set a serial port to 115k baud? I know how to >#set it up to 9600 baud and do i/o. But I have seen some software >#use it at 115k. How do you do it? Please also provide any >#general serial port hints you have (that is not found in >#Norton's PC Programmer book). ># > >My 16450 data sheet says you can't do it. The AT runs the 16450 with a >1.8432Mhz clock, which is 16x 115Kbaud. Thus, the divisor in the 16450 >is 1 (unity). But, the sheet says : > > S T U F F D E L E T E D > >If you want to play with it anyway, set the divisor to 1. Because you are You can't run asynchronous communications with a divide by 1. The reason (which EE types all seem to know, but only tell software people after they bang their heads on the problem for a while) is that Async chips work by sampling the input stream at clock edges to find the start bit. Since there will be some drift between the clocks on two communicating systems, this sampling process has a window in which to operate, which is usually 1/2 a bit width at the current transfer rate. The idea is that you see a bit state two clock edges in a row, you know what it is. If you do a divide by one clock, then you only get the bit value right a certain regrettably low percentage of the time, since the sample frequency is the same as data frequency. It's the old A to D rule: sample at twice the maximum frequency to get an accurate sample. The effect I saw when I used a divide by one clock is that it garbled bytes about 1% of the time, which makes it worthless for any kind of reliable transmission. > >What, pray tell, are you talking to at this speed ? > Lots of things. Usually you go synchronous, though, in which case you wouldn't bother with a 16450; you'd use a Zilog SIO. I've heard of 115K baud fast-wire transfers, but I think they do that with bit-banging and timing loops. -- Kent Williams --- williams@umaxc.weeg.uiowa.edu "'Is this heaven?' --- 'No, this is Iowa'" - from the movie "Field of Dreams" "This isn't heaven, ... this is Cleveland" - Harry Allard, in "The Stupids Die"
wilker@descartes.math.purdue.edu (Clarence Wilkerson) (01/08/91)
Actually, some of the file transport pograms from laptops to pc's, etc use the 115k mode. With error catching protocols, perhaps the 1% error rate plus retries is better than 57.5 kbaud ? Clarence Wilkerson
williams@umaxc.weeg.uiowa.edu (Kent Williams) (01/08/91)
In article <3345@mentor.cc.purdue.edu> wilker@descartes.math.purdue.edu (Clarence Wilkerson) writes: >Actually, some of the file transport pograms from laptops to pc's, etc >use the 115k mode. With error catching protocols, perhaps the 1% error rate >plus retries is better than 57.5 kbaud ? >Clarence Wilkerson No they do some sort of hard-poll bit-banging. Plus, 1% error rate is fatal for any kind of transfer protocol -- 1 out of every hundred characters is garbage, so if you have 100 character packets, you can get into a situation where you get an error in every packet. So if you lower the packet size to 50 then you double the # of acks you need, and the acks get garbled too, so one out of every hundred acks gets nuked. Add that all up and your throughput approaches zero. Believe me -- I spent about 48 hours straight trying to get divide-by-one to work, and it don't. -- Kent Williams --- williams@umaxc.weeg.uiowa.edu "'Is this heaven?' --- 'No, this is Iowa'" - from the movie "Field of Dreams" "This isn't heaven, ... this is Cleveland" - Harry Allard, in "The Stupids Die"
ong@d.cs.okstate.edu (ONG ENG TENG) (01/08/91)
From article <3815@ns-mx.uiowa.edu>, by williams@umaxc.weeg.uiowa.edu (Kent Williams): > In article <1839@gold.gvg.tek.com> grege@gold.gvg.tek.com (Greg Ebert) writes: >> >> ong@d.cs.okstate.edu (ONG ENG TENG) writes: >>#Any one know how to set a serial port to 115k baud? I know how to >>#set it up to 9600 baud and do i/o. But I have seen some software >>#use it at 115k. How do you do it? Please also provide any >>#general serial port hints you have (that is not found in >>#Norton's PC Programmer book). >># >> >>My 16450 data sheet says you can't do it. The AT runs the 16450 with a >>1.8432Mhz clock, which is 16x 115Kbaud. Thus, the divisor in the 16450 >>is 1 (unity). But, the sheet says : >> >> S T U F F D E L E T E D >> >>If you want to play with it anyway, set the divisor to 1. Because you are > > You can't run asynchronous communications with a divide by 1. The reason > (which EE types all seem to know, but only tell software people after they > bang their heads on the problem for a while) is that Async chips work > by sampling the input stream at clock edges to find the start bit. > > Since there will be some drift between the clocks on two communicating > systems, this sampling process has a window in which to operate, which > is usually 1/2 a bit width at the current transfer rate. The idea is > that you see a bit state two clock edges in a row, you know what it is. > > If you do a divide by one clock, then you only get the bit value right > a certain regrettably low percentage of the time, since the sample > frequency is the same as data frequency. It's the old A to D rule: > sample at twice the maximum frequency to get an accurate sample. > > The effect I saw when I used a divide by one clock is that it garbled > bytes about 1% of the time, which makes it worthless for any kind of > reliable transmission. > >> >>What, pray tell, are you talking to at this speed ? >> > Lots of things. Usually you go synchronous, though, in which case you > wouldn't bother with a 16450; you'd use a Zilog SIO. I've heard of > 115K baud fast-wire transfers, but I think they do that with > bit-banging and timing loops. Well folks, thanks for all the info. I did run a wire between an XT and an AT with a program called FastWire II at 115kbaud (at least that is what the program indicate it was doing), and there were no errors with the final result (which may only mean that they have error-correction built-in). Put aside all the intellectual arguments, can it be ran at 55k baud (with a divisor of 2, I supposed) properly if not 115k baud? Thanks in advance. E. Teng Ong (ong@d.cs.okstate.edu)
w8sdz@vela.acs.oakland.edu (Keith Petersen) (01/08/91)
You may wish to review this program, which has been doing 115K bps serial file transfers since its introduction several years (and versions) ago. It does not require special hardware. WSMR-SIMTEL20.ARMY.MIL [26.2.0.74] NOTE: Type B is Binary; Type A is ASCII Directory PD1:<MSDOS.LAN> Filename Type Length Date Description ============================================== ZIP144.ZIP B 18294 901223 115K bps PC-to-PC serial file transfers! And this program which will set the serial port to high baud rates. Directory PD1:<MSDOS.SYSUTL> Filename Type Length Date Description ============================================== TOADMOD1.ARC B 4949 890427 Set COM 1-4 to 19200/38400/57600/115200 bps Keith -- Keith Petersen Maintainer of SIMTEL20's MSDOS, MISC & CP/M archives [IP address 26.2.0.74] Internet: w8sdz@WSMR-SIMTEL20.Army.Mil or w8sdz@vela.acs.oakland.edu Uucp: uunet!umich!vela!w8sdz BITNET: w8sdz@OAKLAND
grege@gold.gvg.tek.com (Greg Ebert) (01/08/91)
williams@umaxc.weeg.uiowa.edu.UUCP (Kent Williams) writes: >> >> S T U F F D E L E T E D >> { Regarding the 16450 ACE } > >You can't run asynchronous communications with a divide by 1. The reason >(which EE types all seem to know, but only tell software people after they > [...] If you were more familiar with the 16450, you would know that it has an *internal* divide-by-16 before the TX/RX shift registers. When you program a divisor of 1, you get the standard 16x internal clock. Even if you drive it with an external clock, it's STILL divided by 16. The device is also asynchronous, and at the mentioned speed, violates RS232C spec, which is why I asked -- >> >>What, pray tell, are you talking to at this speed ? >> >Lots of things. Usually you go synchronous, though, in which case you >wouldn't bother with a 16450; you'd use a Zilog SIO. I've heard of >115K baud fast-wire transfers, but I think they do that with >bit-banging and timing loops. ----- Boycott redwood products ---------------------------- Recycle ----- Read "The Emperor Wears No Clothes", by Jack Herer ##### {uunet!tektronix!gold!grege} Register to vote, then ## | ## grege@gold.gvg.tek.com vote responsibly # | # # /|\ # Support high oil prices, waste tax $$ on war, evade domestic #/ | \# problems, and die young on foreign soil- Just say YES to Bush #######
phil@brahms.amd.com (Phil Ngai) (01/09/91)
In article <3815@ns-mx.uiowa.edu> williams@umaxc.weeg.uiowa.edu.UUCP (Kent Williams) writes: |You can't run asynchronous communications with a divide by 1. The reason True, but the divide by 1 is AFTER the divide by 16. So everyone stop speculating about 1% error rates and similar type things, the only error is in Kent Williams. -- seifert@asylum.sf.ca.us is responsible for the Ethernet slide latch.
md@sco.COM (Michael Davidson) (01/09/91)
In article <3815@ns-mx.uiowa.edu> williams@umaxc.weeg.uiowa.edu.UUCP (Kent Williams) writes: >In article <1839@gold.gvg.tek.com> grege@gold.gvg.tek.com (Greg Ebert) writes: >> ong@d.cs.okstate.edu (ONG ENG TENG) writes: >>#Any one know how to set a serial port to 115k baud? >>My 16450 data sheet says you can't do it. The AT runs the 16450 with a >>1.8432Mhz clock, which is 16x 115Kbaud. Thus, the divisor in the 16450 >>is 1 (unity). But, the sheet says : >> >> S T U F F D E L E T E D >> >>If you want to play with it anyway, set the divisor to 1. > >You can't run asynchronous communications with a divide by 1. Read what Greg wrote!! (and a 16450 data sheet!) The clock frequency in this case is 1.8432Mhz - loading the 16450 divisor latch with a value of 1 gives an effective divisor of 16 - that's just the way the divisor latch is implemented on the 16450 .... You *can* run a 16450 at 115.2K bps but your mileage will certainly vary - the 16450 or 16550 will probably hold up OK but you may have some problems with with the RS232 drivers - and don't expect to get away with more than a few feet of cable at that speed. I regularly run a Sharp JX100 color scanner at 57.6K bps on a standard PC dumb serial card which has been upgraded from a 16450 to 16550. I have also successfully run it at 115.2K bps - I don't usually run it at 115.2 simply because the scanner itself can't actually make full use of that bandwidth and the link is certainly more error prone at that speed.
williams@umaxc.weeg.uiowa.edu (Kent Williams) (01/09/91)
In article <9493@scolex.sco.COM> md@sco.COM (Michael Davidson) writes: >Read what Greg wrote!! (and a 16450 data sheet!) The clock frequency >in this case is 1.8432Mhz - loading the 16450 divisor latch with a >value of 1 gives an effective divisor of 16 - that's just the way the >divisor latch is implemented on the 16450 .... > OK, you're right. I don't know the 16X50 series that well. With a Zilog SIO, the value you write to the divisor latch IS the clock divisor. Divide by 16 should work great; even divide by 2 works OK. >You *can* run a 16450 at 115.2K bps but your mileage will certainly >vary - the 16450 or 16550 will probably hold up OK but you may have >some problems with with the RS232 drivers - and don't expect to get >away with more than a few feet of cable at that speed. > Even with a 386, 115.2K is pushing the limit of what you can do with interrupt driven communication. The queue in the 16550 would help some. Has anyone at SCO run a dumb card under unix at 57K? -- Kent Williams --- williams@umaxc.weeg.uiowa.edu "'Is this heaven?' --- 'No, this is Iowa'" - from the movie "Field of Dreams" "This isn't heaven, ... this is Cleveland" - Harry Allard, in "The Stupids Die"
cox@software.org (Guy Cox) (01/10/91)
In article <3815@ns-mx.uiowa.edu> williams@umaxc.weeg.uiowa.edu.UUCP (Kent Williams) writes: > In article <1839@gold.gvg.tek.com> grege@gold.gvg.tek.com (Greg Ebert) writes: > > > > ong@d.cs.okstate.edu (ONG ENG TENG) writes: > >#Any one know how to set a serial port to 115k baud? I know how to > >#set it up to 9600 baud and do i/o. But I have seen some software > >#use it at 115k. How do you do it? Please also provide any > >#general serial port hints you have (that is not found in > >#Norton's PC Programmer book). > ># > > ... Deleted .. I seem to recall doing this several years ago using either Procom 4.2 or Kermit 2.6 and sending the data to a Mac Plus running Red Ryder. I cheated and converted the RS-422 on the Mac to an RS-423 and running a twisted pair 10 feet or so.... Worked like a champ. -- // //Remember; Tuesday is Soylent green day! // Guy O. Cox, Jr. Software Productivity Consortium. 2214 RockHill Rd Herndon, VA 22090 703-742-7219 cox@software.org
md@sco.COM (Michael Davidson) (01/12/91)
In article <3835@ns-mx.uiowa.edu> williams@umaxc.weeg.uiowa.edu.UUCP (Kent Williams) writes: >In article <9493@scolex.sco.COM> md@sco.COM (Michael Davidson) writes: >>You *can* run a 16450 at 115.2K bps but your mileage will certainly >>vary - the 16450 or 16550 will probably hold up OK but you may have >>some problems with with the RS232 drivers - and don't expect to get >>away with more than a few feet of cable at that speed. >> >Even with a 386, 115.2K is pushing the limit of what you can do with >interrupt driven communication. The queue in the 16550 would help some. >Has anyone at SCO run a dumb card under unix at 57K? Yes - I regularly run standard dumb serial cards (both a standard COM1 style port and an AST style 4 port dumb card) at 57.6K under SCO UNIX 3.2.2. In both cases these cards have been upgraded to have 16550 chips instead of 16450's. The 16 byte FIFO in the 16550 makes this quite practical - the default configuration of the 16550 under SCO UNIX 3.2.2 is to trigger an interrupt when the receive FIFO has 14 characters in it - this reduces the number of interrupts considerably (to much less than half the number you would get from a 16450 running at a continuous 9600 bps) - however, the maximum interrupt latency allowable is only 2 character periods (ie you get an interrupt when the FIFO has 14 characters in it so you have to start emptying the FIFO before it fills up completely 2 characters later) - this maximum interrupt latency doesn't seem to be a problem on a 25MHz 386 - if it does become a problem the solution is to reconfigure the FIFO to interrupt when it contains only 8 characters - this still reduces the interrupt load and gives a full 8 character periods (ie well over 1 millisecond at 57.6K) before the FIFO fills up and data overrun occurs - no 386 machine should have *any* problem getting the data in this case. A couple of comments here may be of help to anyone who wants to experiment with this: The standard SCO serial driver for dumb cards only supports baud rates up to 38.4K (B19200 and B38400 are both defined in /usr/include/sys/termio.h as alternatives to the traditional EXTA and EXTB baud rate definitions). The baud rate divisors for the 16450 or 16550 chip in the serial driver are stored in a 16 element array called "bauddivisor" in the sio driver. The divisor for 38.4K is stored in the last element of this array (at address "bauddivisor + 0x3c") and has the value 3 - if you want to experiment with 57.6K you should patch this value to be a 2. Then setting a tty line to speed EXTB will get you 57.6K. If you are attempting to receive data at 57.6K you may experience problems with the standard size of the raw character queue in the tty input processing code. By default this size is 256 and if more than 256 bytes are received before your application has time to read the data (which is very possible at 57.6K) then data will be lost. Fortunately this limit is patchable. The kernel variable ttyhog defines this value - the default is 256 bytes - I would suggest increasing this to at least 1024 if you want to handle high data rates. Please note that we do not *support* operation at these higher speeds but I thought that this information might be useful to anyone who wanted to experiment.