Programmer 7500/MAX_PROGRAMMERS.iso/PROGRAMS/UTILS/MOUSE/NO_INT.ZIP/SANSINT2.DOC

Text File | 1990-11-21 | 3.6 KB | 71 lines

To: Whom it may concern
From: Lauren A. Colby, 10 E. 4th St., Frederick, MD. 21701
November 26, 1990
Re: Avoiding interrupt conflicts between serial ports

     In an earlier memo, I presented a simple basic terminal
program to shut off the interrupts in a serial port and use
polling instead of interrupts, to operate the port. There was an
error in the comments in that program (SANSINT). The terms "LSB"
and "MSB" were reversed. The program still works; the comments
were simply incorrect.

     I have worked on the program and made some improvements.
With the new version (SANSINT2), the program looks for a
configuration file (SANS.PRO). If it doesn't find the file, it
asks you for the port address, baud rate, etc., and lets you
configure the port, any way you want. At my home, I have a
machine with add-on ports which use the IBM PS/2 standard. In
that standard (if you can call it a "standard"), COM3 is decimal
12832; COM4 is decimal 12840. I'm controlling a PAKRATT ham radio
interface on COM4, at 2400 BAUDS, and everything works just fine,
even though I have a mouse on COM1 and a modem on COM2!

     I'm giving you the files SANSINT2.BAS, and SANSINT2.EXE.
When you run SANSINT2.EXE for the first time, it will create
SANS.PRO. Be careful to answer the questions correctly; there is
no error trapping. Also, SANSINT2.BAS is written in Quick Basic,
so you'll need Quick Basic if you want to make modifications.

     While on the subject of interrupt conflicts, I ran into a
curious problem at my law office, which is worth mentioning. We
have two virtually identical 286 machines, used by the
secretaries. I installed Seiko smart label printers on both
machines. Both printers were installed on COM1.

     One of the machines worked perfectly from the start. With
the other machine, however, the machine would "lock up",
intermittently, when labels were printed. The machine that locked
up had a modem installed on COM2. The machine that worked OK had
no modem.

     I called Seiko tech support and was told that the only
solution was to remove the modem; according to the technician,
"ports have a tendency to 'spread out' and create conflicts". I
didn't believe that! I had a hunch that the problem had something
to do with the fact that COM1 uses IRQ4, which has a lower
priority that IRQ3, which is normally used by COM2, and that if I
could just reconfigure the devices to put the printer on COM2 and
modem on COM1, everything would work OK.

     In the course of doing the reconfiguring, I discovered that
the serial card which was installed would not work properly on
COM2 and I had to replace the card. With the new card installed
and the printer moved to COM2 and the modem reset to COM1,
everything has worked just fine. It's been six months since the
job was done, and there have been no more lockups. I can't tell
you whether the fix was the new card or the swap in port
assignments. However, because Seiko tech support has apparently
received many complaints about this problem, and there can't
possibly be that many bad cards, I'd guess that simply swapping
ports will work, in most cases.

     Incidentally, I don't mean to be critical of Seiko. Their
smart label printers are the greatest product since sliced bread.
If, however, they'd re-write their software to bypass the
interrupts, it would greatly simplify installations. The same is
true for the writers of mouse software and communications
software. At one time, when machines were slow and memory very
limited, the interrupts were useful to cut down on system
overhead. They really aren't needed any more except, possibly for
high speed applications.