Date: Mon, 22 Jul 1996 12:32:03 +0200 (MET DST) From: schofiel@xs4all.nl To: hardware@freebsd.com Subject: The multiple COM ports discussion Message-ID: <199607221032.MAA27626@xs2.xs4all.nl>
next in thread | raw e-mail | index | archive | help
Hello there everyone. Well, I have to confess, I didn't realise I would cause so much controversy regarding my questions on multiple ports. I have to admit also, that I posted in advance of performing research, which is always a serious mistke. Thanks for everyone for answering; it seems we have a case of the blind men and the elephant - everyone has got one piece of the puzzle and they are interpreting it differently. Over the weekend, I have sat down and read up on it, and I believe I now have a good picture of how things work on the hardware and on the software level. As a result, I would like to suggest that I write an article andpost it here. If anyone would like this, willyou please post and I will be glad to oblige. Note, I am not backing out here; in the most cases, people do not have to know this to operate BSD successfully. However, if theere is sufficient interest, I can supply the information. A number of points before I go, just to clear a few misapprehensions I have seen here. 1) PC/AT/ISA and EISA interrupt lines are all logic HIGH in the steady state. 2) With no devices attached to any interrupt line coming from a PIC, the level is pulled weakly high by pullups inside the PIC itself. 3) There are two versions of the PIC, the original type and the enhanced "A" variant. The original does not allow for level/edge selection, the enhanced does. The original does not allow individual IRQ operation selection (ie. all interrupt lines must operate with the same mode), te enhanced does allow individual mode selection. 4) In the PC/ISA scheme, interrupts are POSITIVE-GOING, EDGE triggered. In the EISA scheme, interrupts are by the default compatible to this, but can be configured to be ACTIVE LOW, LEVEL triggered. 5) TRistate interrupt line drivers are not neccessary in this scheme. 6) Individual interrupt lines can not be programmed "off" at the PIC, only in the calling device. 7) Multiple ISA-type interrupting devices can be placed on a single interupt line, electrically. The ISA standard (no joke, there is one) does not however closely specify how interrupt drivers should be implemented for uniformity. 8) Multiple ISA devices can also be handled on a single interrupt, but again there is no closely defined method (only "recommended good practice") for doing this. 9) It is not possible to alter the way the interrupt line works simply by programming the PIC to which it is attached, this is determined by the design of the hardware device that is interrupting. Before you all go wacko and say "What does he know!!!" or "Garbage!", I have spent the weekend reading the ISA spec and the EISA spec, plus a few books dedicated to both architectures written by hardware designers at DELL, etc. They point out that the EISA architecture was designed to address the holes left by the ISA spec, whilst moving it on to the next logical stage (32-bit). ISA, is by definition, pretty c*** on a number of pretty important issues. In summary, you can stick as many ISA devices as you like on one IRQ line, but there's: 1) No guarantee all devices on the line will use the same interrupt drive hardware 2) No guarantee that all devices will fail safe on an IRQ 3) No guarantee that even if you have a driver able to scan for multiple devices interupting on a line, that it will be able to successfully handle them 4) No guarantee that simultaneously interrupting devices will BOTH be recognised The most likely scenario of success is if all devices on a shared ISA scheme are GUARANTEED not to interrupt at the same time. Thanks for all answers, sorry this went on so long; as stated, if anyone would like me to write a definitive article on shared interrupts, then please post or send mail to me at: schofiel@xs4all.nl Rob Schofield
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607221032.MAA27626>