🚀 go-pugleaf

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