Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!amdcad!ames!rutgers!bellcore!faline!ulysses!mhuxt!mhuxm!mhuxh!vxb From: vxb@mhuxh.UUCP (Vern Bradner) Newsgroups: comp.sys.ibm.pc Subject: Summary: PC Serial Communications in C (long) Message-ID: <995@mhuxh.UUCP> Date: 3 Jan 88 17:00:18 GMT Organization: AT&T Bell Laboratories, Murray Hill, NJ Lines: 128 I posted the following request for information on writing C routines to communicate through the PC serial port: Can anyone share their knowledge/experiences in writing C routines to communicate with remote systems via the PC serial port? I tried inp and outp without much success. Are there any C libraries that might make this job easier? I have seen requests for this information recently, but I have not seen the answers posted (I will post a summary if anyone is interested). A summary of the replies is listed below. Several people suggested using the Greenleaf communications library and Joe Cambell's book: " C Programmers Guide to Serial Communications". Also a couple people sent good descriptions on PC serial communications for beginners like myself. Thanks to all who helped me with this! Vern Bradner ihnp4!mhuxh!vxb ------------------------------------------------------------------------ Several people suggested this library: The easiest thing to do is purchase the Greenleaf communications library for your compiler. It includes all sorts of buffers and most (all?) of the routines you would need for most any communication (RS-232) program. ------------------------------------------------------------------------ Several people mentioned this book: There is an excellent book by Joe Campbell -- "C Programmer's Guide to Serial Communications." It covers IBM PC serial port (as well s the Kaypro CP/M machine serial port). It is published by Howard W. Sams & Company, Indianapolis. ------------------------------------------------------------------------ From: osm@metavax.UUCP (Owen Scott Medd) I've just glanced at the documentation on writing interrupt handlers in Microsoft C 5.0. This looks like a very nice facility to avoid coding serial drivers in assembler. Has anyone made an attempt to rewrite any of the public domain serial drivers in MSC5.0? ------------------------------------------------------------------------ From: rutgers!eddie.mit.edu!genrad!jpn (John P. Nelson) You don't say what you've already tried, so I don't really know what level to approach this at. Using DOS level functions to access a serial port is useless, except perhaps for writing to a serial printer. You have no control over baud rate etc, and DOS does not provide any buffering whatsoever. If IBM had done this right, the DOS serial driver would be interrupt driven, buffered, and you would use ioctl calls to change baud rate etc. The next level, the standard serial ROM BIOS routines, give you a better level of control. However, there are still problems. For instance, the standard IBM bios refuses to send characters (and the machine hangs) if DTR is not asserted. This is not a hardware problem, but a software problem. Another (more serious) problem is that polling the serial port can cause lost characters. Any lengthy operation (including scrolling the screen) may take so long that an overrun occurs. I found that even at 300 baud, a trivial communications program using the ROM bios routines would lose characters when scrolling the screen (XT class machine: your milage may vary). Any serious communications program MUST use interrupts. The serial port can be set up so that when a character is recieved, an interrupt occurs. Your interrupt handling routine can queue data so that long operations do not cause overruns. You must enable the interrupts in several places. First, in the interrupt enable register, you select which events will cause an interrupt to occur. Second, bit 3 of the MODEM control register (this bit is output to an interrupt ENABLE circuit) must be set to a 1. Third, you must enable the appropriate interrupt on the 8259A interrupt controller on the system board. When an interrupt DOES occur, you must service the 8250 (communications chip) so that the interrupt is no longer asserted, then you must send an EOI instruction to the 8259 interrupt controller. If you skip this last step, the system will hang, because no further interrupts will be processed. Since I don't know what level of expertise you are at, I don't know if I am answering your questions. I could send you some working Turbo C code fragments, if you want. >I tried inp and outp without much success. Are there any C libraries >that might make this job easier? Several libraries are advertized in all the magazines. I have no direct experience with any of them, though. ------------------------------------------------------------------------ From: manes@dasys1.UUCP (Steve Manes) Writing code to control the PC's serial port can range from fairly simple to gruesomely elaborate depending on what you want to do. However, in most applications you want to avoid the IBM's built-in ROM BIOS serial support because it doesn't support interrupt-driven character receipt, i.e. it doesn't buffer. If you're not all that experienced writing code for hardware and particularly the PC's 8250/16450 UART and 8259 interrupt controller the first thing you'll need to do is study how they work. did an excellent series on the IBM hardware interrupt structure several years ago. Another good source of reference is by Sargent & Shoemaker (Addison-Wesley). The 8250 can be tricky to work with if you're starting out with a blank page. I probably spent 6 months tweaking and refining (and fixing many subtle bugs) in my comm library. You can save yourself a lot of aggravation by purchasing the Greenleaf comm library, or equivalent. The downside is that you'll lose a valuable education in hardware programming. The upside: you'll sleep better knowing that you've got a predebugged library to work with. You can't just pop bits in and out of the comm port if you want an effective serial device controller. The UART has to be prepared and initialized beforehand. The Sargent/Shoemaker book explains this well.