PEPRBV@CFAAMP.BITNET (Bob Babcock) (05/08/88)
There has been mention in Info-C of disabling interrupts when executing sections of code which cannot be safely interrupted. Usually the sample code uses something like protect()/unprotect() around the critical statements. I would like to be able to do this under OS-9/68K, but Microware does not provide the necessary protect/unprotect functions. The obvious way of implementing these by moving the appropriate bits to the status register does not work in user state because the machine opcode is privileged, and if the entire program is run in supervisor state, OS-9 turns off time slicing, which I don't want to do. [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).
piner@pur-phy.UUCP (Richard Piner) (05/09/88)
In article <PEPRBV.880507.234659.B0@CFAAMP.BITNET> 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