COM3 & COM4 under SCO Xenix ?

Stuart Lynne sl at van-bc.UUCP
Thu Mar 22 06:59:03 AEST 1990


In article <683 at sixhub.UUCP> davidsen at sixhub.UUCP (bill davidsen) writes:
>In article <5275 at scolex.sco.COM> md at sco.COM (Michael Davidson) writes:
>
>| Now, consider the situation where COM1 has just interrupted on line
>| 3 causing the line to change from the inactive to the active state.
>| The interrupt controller sees the transition and latches the interrupt.
>| Suppose that COM3 then attempts to interrupt on the same line
>| *before* the line has returned to it's inactive state - the line is
>| already active so you can't get an inactive -> active transition,
>| there is no transition for the interrupt controller to see and
>| you lose the interrupt.
>
>  What you say is true, but you can get by it with a little clever
>programming which polls the status of both uarts and servicea all
>devices which have tbe or rda set. This is how some multiport cards
>support use of a single interrupt.
>

Something like the following is required to support multiple 8250 type
devices on a single interrupt.

	#define MAXDEV	?
	int notfinished;
	int devno;

	do {
		notfinished = 0;
		for (devno = 0; devno<MAXDEV; devno++ ){
			if (checkstatus(devno)) {
				notfinished = 1;
				dowork(devno);
				break;
			}
		}

	} while (notfinished);


You must be able to complete the for loop without seeing any activity on any
8250 device to guarantee that the interrupt controller get's reset.

For small numbers of devices, with a low traffic level it is slightly faster
to break from the for loop than to continue once you have found something.
Because you are usually just seeing one interrupt from one device. 

-- 
Stuart.Lynne at wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)



More information about the Comp.unix.xenix mailing list