Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!wa4mei!holos0!lbr From: lbr@holos0.uucp (Len Reed) Newsgroups: comp.os.msdos.programmer Subject: Re: Serial input under DesqView Keywords: DesqView interrupts serial Message-ID: <1990Dec21.174010.4491@holos0.uucp> Date: 21 Dec 90 17:40:10 GMT References: <1990Dec11.032154.18383@dms3b1.uucp> <1990Dec12.190108.15079@Octopus.COM> <769@csource.oz.au> Organization: Holos Software, Inc., Atlanta, GA Lines: 63 In article <769@csource.oz.au> david@csource.oz.au (david nugent) writes: >In <1990Dec12.190108.15079@Octopus.COM> stever@Octopus.COM (Steve Resnick ) writes: > >> >Here's my situation: I have a program that takes serial input at >> >19200 baud. By experimentation, I've determined that, with code in >> >the interrupt service loop, I can spare about an additional 250 microsec. >> >of delay in the interrupt response before risking occasional overruns. >> >(This is running on a 25 MHz 386 in real mode.) How did you measure this? 19200 baud means you get a character every 521 microseconds. Are you saying that you're using half this time on a 25 Mhz 386? What are you doing in your handler, FFTs? >> DESQview does disable interrupts during a task switch - it HAS to. I don't buy this. Perhaps what you mean is that DESQview's design is such that interrupts must be disabled during a task switch. I just wrote a system that talks on COM2 at 38.4 K-baud *and* runs a background task. It works on a 10 Mhz 80286. (The COM2 port sends and receives packets in bursts; its throughput is about 2000 characters/second in the long run.) I'm using vanilla DOS 3.3 and 4.01, though; no DESQview. I sure don't disable all interrupts during a task switch. >... and of course the short solution is to get a better serial chip and >upgrade the software to take advantage of it. Namely, the NS16550A. Well, that's one solution. It wasn't available to me: the system had to run on an off-the-shelf PC. If DESQview is what's causing your long interrupt latency, though, you'll have to change it (good luck) or use this hardware solution. If you're trying to do too much in *your* handler, though, you can program your own FIFO. (The 16550 has an on-board FIFO that will 16 hold characters instead of the usual 2.) Program your interrupt handler with some variation of the following. 1) Read the UART. If it's a character, read it into a queue. 2) EOI the interrupt. (Processor still has interrupts masked.) 3) Check to see if re-entrancy flag is clear. If not, return from interrupt. 4) Set the re-entrancy flag and enable interrupts. 5) Copy all characters from the queue to wherever, with interrupts enabled, performing your FFT. :-) 6) Disable interrupts and clear the re-entrancy flag. 7) If queue is still empty, return from interrupt. If another character was sneaked in, go to #4. Step 6 can run almost like your original handler, except that it takes it's input from the queue instead of the UART. You may want to put the status registers into your queue as well as the characters. --- In my system *I* didn't go to this extreme. Each interrupt runs a C-language interrupt handler and I almost always keep up. (The 1/1000 packet Nak and retransmit I get is perfectly acceptable.) Such a scheme, with steps 1-3 in assembly language, should allow you to run the line maxed out (115.2 K-baud). -- Len Reed Holos Software, Inc. Voice: (404) 496-1358 UUCP: ...!gatech!holos0!lbr