gordon@prls.UUCP (Gordon Vickers) (03/02/90)
I am considering the use of several IBM ATs to replace some
ageing in-house designed boards. I am no expert on PC's but from
my initial study, it seems that my main problem will be trying to
get an RS232 serial port to communicate at 19,200 baud. One solution
would be to find a serial card that contains a uP as well as an
input and output buffer thus supporting the ability to read/write
as to a file. Does such an animal exist ?
My specific needs for this project :
allow keyboard input
text only output to monitor
allow stdin and stdout to be redirected to a serial port
(normal state for this application), baud rate would be 2400.
bidirectional second serial port at 19,200 baud, RS422
(preferred) or RS232
application program to load and run automatically after power
is applied.
possiable future addition of a third serial port at some lower
baud rate (1200 or 2400 baud)
possiable future additions of a hard disk, and eathernet (802.3)
What disturbs me about the AT is that the keyboard has such a high
interupt priority. Is this changable at the hardware level or software ?
If software, at what level is the software change made (boot, BIOS,
kernal )?
Any recommendations on how to do 19,200 baud on a serial port? One
advantage to this problem is I'll have some advanced warning that
no more than 80 charectors will soon need to be read.
Thanks for any assistance,
Gordon Vickers 408/991-5370, at Signetics (Sunnyvale, California, USA )
{mips|pyramid|philabs}!prls!facv01!gordon ** All disclaimers apply **
Earth is a complex array of symbiotic relationships: Every extinction, whether
animal, mineral, vegetable, or cultural hastens our own demise.kaleb@mars.jpl.nasa.gov (Kaleb Keithley) (03/02/90)
In article <32894@prls.UUCP> gordon@prls.UUCP (Gordon Vickers) writes: > my initial study, it seems that my main problem will be trying to > get an RS232 serial port to communicate at 19,200 baud. One solution > > Any recommendations on how to do 19,200 baud on a serial port? One > PC serial ports have no problem in general running 19200, and even 38400 baud, the problem lies in the BIOS, which (as a result of IBM's brain damaged lack of foresight) does not have the logic to set the hardware to do 19200. Five years ago I coerced a 5mhz XT to run 19200 and 38400 by getting the BIOS listing from the IBM Hardware Tech Ref, copying it into my own code, and modifying it to set the correct divisor for the higher rates of speed. The divisor starts out fairly large, for low baud rates, eventually getting to 4, for 9600, 2 is the divisor for 19200, and 1 for 38400. Like I said, it was five years ago, so I don't have the code fragment around anymore, or I'd send it to you. You might also check on simtel20 or some place for similar samples. I think the XTs I used were right on the hairy edge of working, i.e. not being able to keep up at 38400, but I'd *think* that an AT should have no problem. Chewey, get us outta here! kaleb@mars.jpl.nasa.gov Jet Propeller Labs Kaleb Keithley
wilber@nunki.usc.edu (John Wilber) (03/02/90)
I've got a few suggestions. First, you can get some VERY HIGH baud rates from a serial port, as high as 100+ kbaud, if memory serves me correctly. Programs such as LapLink, and the Norton Commander 3.0 do this with file transfers between PC's. My guess is that you can get around any BIOS limitations by writing directly to the registers on the 8250 controlling the serial port. The 8250 is called a UART (say YOO-art, stands for Universal Asynchronous Receiver/Transmitter) and is basically a serial port chip. Each serial port has an 8250. Check some literature from Intel (they make the chip) for WHAT to write to the registers, and check some PC documentation for what ports or memory locations to write to so you can access these registers. Hope this helped. /***********************************************************************\ * John J. Wilber * "Im Himmel gibts kein Bier zum trinken wir * * wilber@nunki.usc.edu * es hier" -German Proverb * * Student, partier, beer * "In heaven there's no beer, so we might as * * drinker, fun-loving guy. * well drink it here" -Translation * ************************************************************************* * "I woke up this morning and I got myself a beer" -The Doors * \***********************************************************************/
dougs@videovax.tv.tek.com (Doug Stevens) (03/06/90)
In article <8422@chaph.usc.edu>, wilber@nunki.usc.edu (John Wilber) writes: > ... you can get some VERY HIGH baud > rates from a serial port, as high as 100+ kbaud ... Specifically, you can get up to 115,200 baud by writing directly to the 8250. You do need to be careful -- not all 8250's are guaranteed to run with a divide-by-one in the oscillator control register with those crystal frequencies (Western Digital, if I remember, is one of these). You also need to play some software tricks to ensure that the transmitting end does not over-run the receiving end with these baud rates.
gordon@prls.UUCP (Gordon Vickers) (03/06/90)
In article <8422@chaph.usc.edu> wilber@nunki.usc.edu (John Wilber) writes: >I've got a few suggestions. First, you can get some VERY HIGH baud >rates from a serial port, as high as 100+ kbaud, if memory serves me >correctly. Programs such as LapLink, and the Norton Commander 3.0 do >this with file transfers between PC's. Yes, I was aware of this and programming the UART isn't a concern. My concern is weather or not I can maintain realiable communications at 19,200 baud to this port when this port is stdin/stdout and to also service COM2 at 2400 (or hopefully 4800) baud. Certainly, I can set up a UART for any valid baud rate that is within that part's range but this does not ensure realiabity. The OS presents some amount of overhead from its system interupts and my application program will also add some amount of overhead as will our communications protocol. Additionally, we may add still more overhead for network (802.3) support. My concerns also involve thoughput (or effeciantcy). On some machines, a data transfer at 4800 baud (for instance) will complete is less time than the same trasfer done at 9600 baud. The serial cards I have seen do not buffer the incoming data and this bothers me, I've written ALOT of serial communications code (on a variety of other machines) and have never liked dealing with charector interupt devices. What I would like to find is a serial card that does buffer the data and lets me know in some more polite manner that data is ready, and interupt me only if the high water mark is reached. If anyone knows of such a card then I would very much appreciate hearing about it since this type of solution would unburden the CPU enough to assure me that the PC will be a suitable platform. Ideally, I'm looking for an RS422 serial card that supports tri-stating the transmitters but I could live with RS232 becouse I've already designed and implimented an RS422 converter. I've never programmed an IBM PC, lots of other things, but not the PC. I'm not doing simple data transfers. I have to process packets, issue ACK/NACKs and process the records enclosed in the packets which will likely result in an outgoing packet. Gordon Vickers 408/991-5370, at Signetics (Sunnyvale, California, USA ) {mips|pyramid|philabs}!prls!facv01!gordon ** All disclaimers apply ** Earth is a complex array of symbiotic relationships: Every extinction, whether animal, mineral, vegetable, or cultural hastens our own demise.
alexande@drivax.UUCP (Mark Alexander) (03/07/90)
In article <8422@chaph.usc.edu> wilber@nunki.usc.edu (John Wilber) writes: >Each serial port has an 8250. Check some literature from Intel (they make the >chip)... Actually, the 8250 (and its very similar successor, the 16450 used in ATs) is made by National Semiconductor. Intel makes a serial chip called the 8251 which is quite different. Documentation on the 8250 and 16450 can be found in IBM's various PC and AT Technical Reference manuals, as well as other books about PC hardware. -- Mark Alexander (amdahl!drivax!alexande)
gardner@kodak.UUCP (Dick Gardner) (03/07/90)
In article <33150@prls.UUCP> gordon@prls.UUCP (Gordon Vickers) writes: [Deleted text to shrink message] > The serial cards I have seen do not buffer the incoming data and this > bothers me, I've written ALOT of serial communications code (on a variety > of other machines) and have never liked dealing with charector interupt > devices. What I would like to find is a serial card that > does buffer the data and lets me know in some more polite manner > that data is ready, and interupt me only if the high water mark is > reached. If anyone knows of such a card then I would very much appreciate > hearing about it since this type of solution would unburden the CPU > enough to assure me that the PC will be a suitable platform. Ideally, > I'm looking for an RS422 serial card that supports tri-stating the > transmitters but I could live with RS232 becouse I've already designed and > implimented an RS422 converter. > Gordon You might check out the following: Intellicon-2 (2 - RS232C or RS422/485 channels) Intellicon-4 (4 - RS232C or RS422-485 channels) Intellicon-8 (8 - RS232C channels) * Will run 38.4K on all ports (Intellicn-8 runs 19.2K on all ports) * Uses Z80B processor & DARTS * Requires block of memory between 640K & 1meg * Memory and port addresses switch-selectable * 16-bit card - uses IRQ 2-7,10,11,12,14,15 * Comes w/drivers for MANY operating systems Made by: Connect Tech Inc. 20-340 Woodlawn Road West Guelph, Ontario Canada, N1H 7K6 (519) 836-1291 FAX: (519) 836-4878 They have a U.S. distributor, if that is a problem. We've used these boards in a variety of machines with several operating systems with great success. #include <usual.disclaimer> I'm only a satisfied customer. =#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=# Dick Gardner -- Eastman Kodak Co. Rochester, New York 14652-4201 Phone: (716) 477-1002 UUCP: rutgers!rochester!kodak!gardner Net: gardner@kodak.com My new whiz-bang computer is SOOOOOOO fast ---- (How fast is it??) it executes an infinite loop in 50 msec!!! =#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#
paula@bcsaic.UUCP (Paul Allen) (03/09/90)
In article <33150@prls.UUCP> gordon@prls.UUCP (Gordon Vickers) writes: > > The serial cards I have seen do not buffer the incoming data and this > bothers me, I've written ALOT of serial communications code (on a variety > of other machines) and have never liked dealing with charector interupt > devices. What I would like to find is a serial card that > does buffer the data and lets me know in some more polite manner > that data is ready, and interupt me only if the high water mark is > reached. If anyone knows of such a card then I would very much appreciate > hearing about it since this type of solution would unburden the CPU > enough to assure me that the PC will be a suitable platform. Ideally, > I'm looking for an RS422 serial card that supports tri-stating the > transmitters but I could live with RS232 becouse I've already designed and > implimented an RS422 converter. > Here's something I saw in comp.unix.microport a year ago. It's a description of the National Semiconductor 16550 UART chip and a bit of (probably Microport-specific) code to turn on the chip's FIFO buffer. It's got to be a lot cheaper to replace a UART than to go out and buy a smart serial card! I don't have direct experience with this stuff, but I plan to put 16550's in my Minix machine at home as soon as I get done draining the swamp... Enjoy! Paul Allen pallen@atc.boeing.com ..!uw-beaver!bcsaic!pallen --------------------------------------------------------------------- >From ssc-vax!uw-beaver!cornell!mailrus!ncar!ames!killer!igloo!learn Fri Feb 24 18:56:36 PST 1989 Article 3094 of comp.unix.microport: Path: bcsaic!ssc-vax!uw-beaver!cornell!mailrus!ncar!ames!killer!igloo!learn >From: learn@igloo.Scum.COM (william vajk) Newsgroups: comp.unix.microport Subject: Igloopatch Revisited Message-ID: <1162@igloo.Scum.COM> Date: 22 Feb 89 20:51:33 GMT Reply-To: learn@igloo.UUCP (william vajk) Organization: igloo, Northbrook, IL Lines: 212 [... stuff specific to igloo and Microport deleted ...] /****************************************************************************** 16550 a utility that iturns on the FIFO of a NS 16550 chip by John Welch, of Igloo Computers Public Domain Software Hobbyists, feel free to use, abuse, pirate and re-distribute this program. Commercial use prohibited without consent of the author. Send fan mail to jjw@igloo Send flames to jjw@/dev/null ******************************************************************************/ #include <sys/types.h> #include <sys/io_op.h> #include <fcntl.h> int fd; void outb(); extern int errno; main() { /* I've waded through the NS 16550 docs for several days now, and what follows seems accurate enough. At any rate, the basic idea is that a 16550 with FIFO enabled has (*FINALLY!*) cured igloo's problems with losing newsfeeds. I thought I'd make this available to the net in the hopes that it may help other people who've been singing the 'microport lost character blues.' As microport has been unable to cure this, we finally fixed it ourselves. By the way, if you aren't tech-y, this may bore you to death. I've got it written to patch tty0 and tty1, and since on a 16450 or earlier this register isn't writable it should cause no problems. Just un-shar it by typing sh 16550.shar and compile this with cc -o 16550 -O 16550.c It might be a good idea to chmod this to 700, to prevent users from flushing the buffers on you. Adding this to the inittab file or some such place should be all thats needed. Run it once at boot-up and forget it. A bit of history here: Microport's serial port drivers are brain-dead. Apparently the problem is with the high-water mark in the kernel, and so it's *not* fixable with new drivers. What this means is that you lose characters sometimes. It is particularly noticable while doing a 9600-baud newsfeed on one serial line while another user on the other line is cat-ing a text file at 300 baud. Usually when this happens, you get many errors during the newsfeed and as often as not you lose the feed altogether. Microport has been told of this problem many times, and they've piddled and fuddled and moped around trying to fix it. At first they said we should get faster hardware because an 8Mhz AT couldn't handle 9600 baud. Fine, we found a place that loaned us a 20Mhz 0-wait 4Mbyte 386 board for a weekend. Guess what??? The problem was just as bad as before. Then they sent us new driver to install, which did not help the problem. They then suggested that we need a smart serial card, to the tune of around $1500 or so. They think that 9600 baud cannot be done on these machines. That's bull-squat, folks! XENIX does 9600 baud just fine. Microport is unable and unwilling to fix this problem. We had to explore alternate ways of doing it ourselves, preferrably without costing us hobbyists an arm and a leg. We feel we've found an acceptable solution with the 16550 UART chip. The 16550 is a half-way step between a 'smart' serial card and the usual 16450-type 'dumb' card. Using the FIFOs in the 16550 can not only prevent lost characters, but can result in more efficient CPU utilization, with less time wasted in processor overhead to read each character sent. It does this by a device called a FIFO buffer, a First-In, First-Out scheme. When receiving characters, the 16550 will only interrupt the CPU when one of two events happens: When enough characters have been received (you can define 'enough' to be 1, 4, 8 or 14) or when at least 1 character has been received and there has not been another character come through for 4 times the time 'width' of a character. In this manner, when the CPU finally gets interrupted, much more data can be dumped to the CPU at once, cutting down on all the overhead involved in context-swiching and so forth. In addition, if the CPU takes too long to read the FIFO, the 16550 will send its own flow-control to throttle back the incoming data, preventing buffer over-runs that have plagued microport from day one. The 16550 chip is a drop-in replacement for the 16450, and it costs about $25 or so (not much more than the 16450). With this chip and a trivial amount of software, you can not only cure microports brain-dead serial device driver problems, but you can also enjoy most of the benefits of a 'smart' card with very little cost. What follows is an explaination of what this program does and why it does it. If you have multi-port 'dumb' boards with 8250's, 16450's or whatever, you *should* be able to replace those chips with 16550s and modify this program to set (base+2) for each port. tty0's base address is 3f8. The FIFO control register is at base+2 (3fa). The byte written at this address is defined as follows: Bits 7 & 6 define at what level the 16550 interrupts the CPU. 11 is 14 bytes deep, 10 is 8 bytes deep, 01 is 4 bytes deep and 00 is 1 byte deep. Bits 5 & 4 are not used, so I set them to 00. Bit 3 defines the performance of some pins that are not used on the 16450, so it's not likely to be of consequence to anything we do. I've chosen to keep them performing the way a 16450 would, setting this bit 0. Bit 2 clears and resets the transmit FIFO. Bit 1 clears and resets the Receive FIFO. Bit 0 turns the FIFO buffering on. To turn on the FIFO at tty1 to a 4-byte level, one should write a 0x47 to port 0x2fa. To set tty0 at the maximum FIFO level, send 0xc7 to port 0x3fa. To disable FIFOs at tty1 send 0 to 0x2fa. */ if ((fd = open("/dev/mem",O_RDWR)) == -1) /* open memory device for read/write */ { perror("Open /dev/mem"); exit(1); } outb(0x3fa,0x87); /* this turns on tty0's FIFO, 8 characters deep */ outb(0x2fa,0x87); /* this turns on tty1's FIFO, 8 characters deep */ close(fd); /* all done setting up FIFOs. */ } void outb(portno, data) int portno; unsigned char data; { io_op_t iop; iop.io_port = portno; iop.io_byte = data; errno = 0; /* clear error indicator */ ioctl(fd, IOCIOP_WB, &iop); /* write the data to that port */ if (errno) printf("Error setting port %04x\n",portno); /* send to stdout so they can re-direct easier */ } -- ------------------------------------------------------------------------ Paul L. Allen | pallen@atc.boeing.com Boeing Advanced Technology Center | ...!uw-beaver!bcsaic!pallen