rrw@naucse.cse.nau.edu (Robert Wier) (04/09/91)
Ok, you guys did really well with answers on my EGA gray scale
question (the general consensus was that you can get 4 shades of
gray with an EGA, but you really need to do to a VGA to get more).
Now, working on the same project I've run into a snag using the
COM port. We have a situation where we don't know when the
data will appear - it can be anywhere from 100 ms to 11 seconds
after the previous carriage return.
The problem we are having (my students are currently using
Quick-C) is that when you go out to read a character and there
isn't one there yet, the port seems to "time out" in 1.5 seconds
or so. I can't find any way to defeat this, although I certainly
see why in most circumstances it would be useful.
I know it CAN be done, because Kermit does it. The big K just
sits waiting patiently for something to arrive and display it on
the screen.
Does anyone know how to do this? Does it require going directly
to the UART and bypassing the built in routines? Or is there
something actualy in the hardware in the nature of a switch
which has to be reset?
Please E-Mail or post.
THANKS
- Bob Wier
-------------- insert favorite standard disclaimers here ----------
College of Engineering
Northern Arizona University / Flagstaff, Arizona
Internet: rrw@naucse.cse.nau.edu | BITNET: WIER@NAUVAX | WB5KXH
or uucp: ...arizona!naucse!rrwrkl@cbnewsh.att.com (kevin.laux) (04/09/91)
In article <3603@naucse.cse.nau.edu>, rrw@naucse.cse.nau.edu (Robert Wier) writes: > The problem we are having (my students are currently using > Quick-C) is that when you go out to read a character and there > isn't one there yet, the port seems to "time out" in 1.5 seconds > or so. I can't find any way to defeat this, although I certainly > know it can be done. The four bytes at 40:7Ch contain the timeout values for COM1-4. I'm not sure what the units are so you will have to relate the value to your 1.5 second timeout. -- ________________________________________________________________________________ R. Kevin Laux Email: rkl1@hound.att.com AT&T Bell Labs Voice: (908) 949-1160 Holmdel, NJ 07733 Fax: (908) 949-0959
nengle@copper.ucs.indiana.edu (nathan engle) (04/09/91)
In article <3603@naucse.cse.nau.edu> rrw@naucse.cse.nau.edu (Robert Wier) writes: [some stuff about EGAs deleted] > Now, working on the same project I've run into a snag using the > COM port. We have a situation where we don't know when the > data will appear - it can be anywhere from 100 ms to 11 seconds > after the previous carriage return. > > The problem we are having (my students are currently using > Quick-C) is that when you go out to read a character and there > isn't one there yet, the port seems to "time out" in 1.5 seconds > or so. I can't find any way to defeat this, although I certainly > see why in most circumstances it would be useful. The BIOS serial port routines use polling to monitor the state of the UART. Unfortunately, this method is inadequate for baud rates of greater than 300 baud or so unless you take full control of the PC (even disable timer and keyboard interrupts) and use assembly to drive the UART at max speed. I'm sure that this is the trick used by 115K baud transfer programs like laplink - I think that 9600 baud is about the fastest an original PC could accept using interrupt driven serial I/O. Interrupt driven I/O is really the answer to your problem. You can set things up so that the UART will yank an interrupt line whenever a character arrives. An interrupt character drops each character into the buffer, and rather than monitoring the UART, you just have to watch the buffer. There are a couple of libraries available for serial I/O that you can buy, or if you like I can post a sample program (simple terminal emulator) that uses interrupt driven I/O, and is written entirely in C including the interrupt handlers. Depending on what you're trying to get the students to learn, it might be educational to dig through my TERM code. One other thing I would recommend if they go that route is that you should get a copy of the 8250 data sheet which can be found in the National Semiconductor Communications/UARTS/LAN databook. > I know it CAN be done, because Kermit does it. The big K just > sits waiting patiently for something to arrive and display it on > the screen. The big K waits for the 8250 to generate RxData interrupts. > Does anyone know how to do this? Does it require going directly > to the UART and bypassing the built in routines? Or is there > something actualy in the hardware in the nature of a switch > which has to be reset? There are actually a couple ways to approach this problem. Some people like me have written programs that take direct control of the serial port since the BIOS services are so inadequate. A lot of pretty famous communications programs do the same thing. However there are also those people who want to try to repair IBM's bogus serial BIOS routines. Basically, it's possible to write a TSR routine (typically referred to as a FOSSIL driver - don't ask what it stands for) that replaces the Int 14h handler with routines that do interrupt driven I/O. Therefore, whatever program is using the brain- damaged Int 14h interface to get to the serial port will work about a thousand times better than the original Int 14h routines would allow. Myself, I prefer method #1 since I like getting more direct control of the hardware. Also, you end up with a self-contained program that doesn't require some other thing to be loaded before it will run. Nathan Engle Software Evangelist Indiana University Dept of Psychology nengle@copper.ucs.indiana.edu
dahlstr@hus.chalmers.se (Gunnar Dahlstrom) (04/10/91)
In article <3603@naucse.cse.nau.edu> rrw@naucse.cse.nau.edu (Robert Wier) writes: > Now, working on the same project I've run into a snag using the > COM port. We have a situation where we don't know when the > data will appear - it can be anywhere from 100 ms to 11 seconds > after the previous carriage return. > > The problem we are having (my students are currently using > Quick-C) is that when you go out to read a character and there > isn't one there yet, the port seems to "time out" in 1.5 seconds > or so. I can't find any way to defeat this, although I certainly > see why in most circumstances it would be useful. > > I know it CAN be done, because Kermit does it. The big K just > sits waiting patiently for something to arrive and display it on > the screen. > > Does anyone know how to do this? Does it require going directly > to the UART and bypassing the built in routines? Or is there > something actualy in the hardware in the nature of a switch > which has to be reset? > You can do this by first checking if there is a character to fetch and after that fetch the character! And how to check if there is somthing to fetch is simple, just check the com ports status register! // Gunnar =============================================================================== Gunnar Dahlstrom Chalmers University of Technology Div. Building Technology 412 96 Gothenburg, Sweden E-Mail: dahlstr@hus.chalmers.se ===============================================================================
john@jwt.UUCP (John Temples) (04/12/91)
In article <1991Apr9.160945.22325@bronze.ucs.indiana.edu> nengle@copper.ucs.indiana.edu (nathan engle) writes: > Myself, I prefer method #1 since I like getting more direct control of >the hardware. Also, you end up with a self-contained program that doesn't >require some other thing to be loaded before it will run. ... and you end up with every piece of software requiring knowledge of the hardware, and every piece of software being bloated with duplicated functionality that should be provided by the underlying system. Why reinvent the wheel? -- John W. Temples -- john@jwt.UUCP (uunet!jwt!john)
roy%cybrspc@cs.umn.edu (Roy M. Silvernail) (04/14/91)
rrw@naucse.cse.nau.edu (Robert Wier) writes: > The problem we are having (my students are currently using > Quick-C) is that when you go out to read a character and there > isn't one there yet, the port seems to "time out" in 1.5 seconds > or so. I can't find any way to defeat this, although I certainly > see why in most circumstances it would be useful. Although you don't say specifically, it would seem that you are using BIOS routines to read the comport. (perhaps bioscom()?) Put succinctly, the BIOS comport handling smells real bad! :-) I use an asynch package I snagged off the net recently. It's an ASM package callable from C, written by David Kessner. There is no timeout on a port... instead, it returns a NULL character when nothing is available on the port. > Does anyone know how to do this? Does it require going directly > to the UART and bypassing the built in routines? Or is there > something actualy in the hardware in the nature of a switch > which has to be reset? The ASM stuff goes right to the UART hardware. It's really the only way to handle comports and Do The Right Thing. BIOS routines, when they work at all, are only good at 300 bps, and barely work at 1200. -- Roy M. Silvernail -- roy%cybrspc@cs.umn.edu - OR- cybrspc!roy@cs.umn.edu perl -e '$x = 1/20; print "Just my \$$x! (adjusted for inflation)\n"' [space reserved for clever quote]{mail your submissions}