Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!pur-phy.UUCP!piner From: piner@pur-phy.UUCP (Richard Piner) Newsgroups: comp.sys.m68k.pc Subject: Re: disabling interrupts under OS-9 Message-ID: <1141@pur-phy> Date: 9 May 88 09:28:13 GMT References:Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: uiucdcs!newton.physics.purdue.edu!pur-ee!pur-phy!piner@uunet.uu.net (Richard Piner) Organization: Purdue Univ. Physics Dept., W. Lafayette, IN Lines: 53 Approved: info-68k@ucbvax.berkeley.edu In article PEPRBV@CFAAMP.BITNET (Bob Babcock) writes: > >[The reason why I want to do this is that I have a background >process driven by a periodic interrupt reading A/D converters and >performing various display and control tasks. The foreground >task needs to be able to occasionally read a different channel >from the same converter without worrying about a time slice or >periodic interrupt coming at just the wrong time and messing >things up.] > >Has anyone developed a good solution to this problem? Microware >suggests that I write a trap handler, and put the critical code >in it. But that almost requires that I do some 68K assembly >language programming, and I would rather avoid that if possible. >The other option is to set up "in use" flags to coordinate access >to the hardware, but that seems much more complicated (there may >be more than two processes competing for the same hardware, and >also multiple devices to be shared). Well, it's a small world. A friend was asking the same questions just this weekend. He is trying to do it in Xenix, and I don't know how to solve the problem in Xenix, but in OS9 I think I know the best approach. First, you will have to do some assembly language programing. That's life when programing a device. The place to take care of this problem is at the device driver level. OS9 allows you to set up as many logical devices as you want. Make a device descriptor for each A/D line. These logical devices are all served by a single device driver. It is up to the driver to keep all the request in order, handle timing, interrupts, etc. There are several good reasons to take this approach. One, the driver runs in supervisor mode. Two, the driver can suspend interrupts to insure proper timing and things like that. Three, by channeling all request through a single driver, the driver can insure there are no conflicts. The driver can run in interrupt mode, or polled mode. In interrupt mode, the driver sets up a trap handler inside itself. The handler receives the results and puts them in a buffer, then clears interrupts, then sends a wakeup signal to the main part of the driver. Four, by using a driver like this, the applications programs need to know next to nothing about the device. It's just another serial device. You can open it as a file from any language, C, FORTRAN, Pascal, even BASIC. Improvements in device handling or a complete change of the device, is transparrent to the applications programs. Well, enough. I'll know just how well this method works in a few weeks, because that is the next job on my list of things to do. If anyone out there has an interest in the results, let me know, and I'll try to report on how well it works in a couple of months. Richard Piner piner@maxwell.physics.purdue.edu