dave@dms3b1.uucp (Dave Hanna) (12/11/90)
Has anyone worked very much with programs under DesqView? Specifically, does anyone know what the maximum interrupt latency it imposes is? 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.) When I load the program up under DesqView, with options set to lock the program in memory, run in background, and optimize for high-speed serial operation, I begin getting overrun errors as soon as I do anything in DesqView besides just let the program run. I.e., as soon as I tap the Alt key to bring up the main menu window, I get a few errors, and everytime I press a key, I get a few more. I'm theorizing that DesqView is probably disabling all interrupts while it switches things around, and that that is taking long enough to cause problems. Does anyone have any experience with any similar situation that would either confirm this or suggest any ways around the problem? I thought about writing the serial buffering as a TSR, and getting it out of DesqView's way, but if it's disabling CPU interrupts, that wouldn't improve things any. Does anyone know if a TSR would have any advantage in interrupt response time over a program flagged to be locked in memory and run in background? Any help would be appreciated. Possibly relevant information: DesqView Version 2.25, MSDOS 4.01, code written in TurboC 2.0. -- Dave Hanna, Infotouch Systems, Inc. | "Do or do not -- There is no try" P.O. Box 584, Bedford, TX 76095 | - Yoda (214) 358-4534 (817) 540-1524 | UUCP: ...!letni!dms3b1!dave |
stever@Octopus.COM (Steve Resnick ) (12/13/90)
In article <1990Dec11.032154.18383@dms3b1.uucp> dave@dms3b1.UUCP (Dave Hanna) writes: >Has anyone worked very much with programs under DesqView? Specifically, >does anyone know what the maximum interrupt latency it imposes is? > >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.) > >When I load the program up under DesqView, with options set to lock >the program in memory, run in background, and optimize for high-speed >serial operation, I begin getting overrun errors as soon as I do >anything in DesqView besides just let the program run. I.e., as soon >as I tap the Alt key to bring up the main menu window, I get a few >errors, and everytime I press a key, I get a few more. > >I'm theorizing that DesqView is probably disabling all interrupts >while it switches things around, and that that is taking long enough >to cause problems. Does anyone have any experience with any similar >situation that would either confirm this or suggest any ways around >the problem? I thought about writing the serial buffering as >a TSR, and getting it out of DesqView's way, but if it's disabling >CPU interrupts, that wouldn't improve things any. Does anyone know >if a TSR would have any advantage in interrupt response time over >a program flagged to be locked in memory and run in background? > > >Any help would be appreciated. > > >Possibly relevant information: DesqView Version 2.25, MSDOS 4.01, >code written in TurboC 2.0. DESQview does disable interrupts during a task switch - it HAS to. I have a process control system written under DESQview (boy was that a mistake!) that uses serial I/O. Serial I/O is limited to 9600 baud on a 386/20. After that, I start loosing data, get overrun errors, etc. Generally bad news. This is not in real mode, however, but in protected mode under QEMM. I would suspect, if anything, for things to work a little better in real modes (QEMM isn't handling interrupts at that point). Hope this helps .... Steve -- ---------------------------------------------------------------------------- steve.resnick@f105.n143.z1.FIDONET.ORG - or - apple!camphq!105!steve.resnick Flames, grammar errors, spelling errrors >/dev/nul The Asylum OS/2 BBS - (408)263-8017 IFNA 1:143/105.0
Ralf.Brown@B.GP.CS.CMU.EDU (12/13/90)
In article <1990Dec12.190108.15079@Octopus.COM>, stever@Octopus.COM (Steve Resnick ) wrote: }In article <1990Dec11.032154.18383@dms3b1.uucp> dave@dms3b1.UUCP (Dave Hanna) 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.) }> }>When I load the program up under DesqView, with options set to lock }>the program in memory, run in background, and optimize for high-speed }>serial operation, I begin getting overrun errors as soon as I do }>anything in DesqView besides just let the program run. I.e., as soon }>as I tap the Alt key to bring up the main menu window, I get a few }>errors, and everytime I press a key, I get a few more. You need a 16550A UART instead of the standard 16450 (it's a pin-compatible replacement). The 550A has a 16-byte on-chip buffer which largely prevents overruns at high speeds. A necessity for any multitasker at 9600 or above, and useful even at 2400 bps on slower systems. Of course your software will need to know how to handle multiple characters per interrupt and how to turn on the buffer. The changes to support a 16550A are fairly trivial, so that isn't a problem, and much recent software does support it. -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=- 412-268-3053 (school) -=- FAX: ask ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: 1:129/3.1 Disclaimer? | I was gratified to be able to answer promptly, and I did. What's that? | I said I didn't know. --Mark Twain
mlord@bwdls58.bnr.ca (Mark Lord) (12/13/90)
In article stever@octopus.UUCP (Steve Resnick ) writes: <In article (Dave Hanna) writes: Serial port interrupt woes omitted.. If you are really strapped with this problem, try replacing the USART chip with a 16550 and enable the FIFOs. This can provide enough help to overcome the interrupt latencies, assuming that your interrupt routines are already clever enough to check for more data before exiting (DO this first if you have not yet tried it!). -- ___Mark S. Lord__________________________________________ | ..uunet!bnrgate!mlord%bmerh724 | Climb Free Or Die (NH) | | MLORD@BNR.CA Ottawa, Ontario | Personal views only. | |________________________________|________________________|
david@csource.oz.au (david nugent) (12/20/90)
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.) > DESQview does disable interrupts during a task switch - it HAS to. .. 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. BTW, has anyone heard of the release of a 16650? I've heard the same thing now for two sources but haven't had any firm confirmation yet. david -- Fidonet: 3:632/348 SIGnet: 28:4100/1 Imex: 90:833/387 Data: +61-3-885-7864 Voice: +61-3-826-6711 Internet/ACSnet: david@csource.oz.au Uucp: ..!uunet!munnari!csource!david
lbr@holos0.uucp (Len Reed) (12/22/90)
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