Chuck_SirVAX_Staatse@cup.portal.com (02/11/88)
Does anyone know if UNIX supports a "Connect to Interrupt" facillity similar to VMS or RSX. Failing an "Out of the Box" solution, has anyone cobbled something together? Target system is a 68000 VME based system. Any takers?
avr@mtgzz.UUCP (XMRP50000[jcm]-a.v.reed) (02/16/88)
In article <3102@cup.portal.com>, Chuck_SirVAX_Staatse@cup.portal.com writes: > Does anyone know if UNIX supports a "Connect to Interrupt" facillity > similar to VMS or RSX. Failing an "Out of the Box" solution, has > anyone cobbled something together? Target system is a 68000 VME based > system. Any takers? UNIX provides a facility called "signals". Signals may be sent by processes, open device files, or by the kernel. Most interrupts are used within device drivers, but it is trivially simple to write a device driver which will send the appropriate signal, to processes that have opened it, when device receives an interrupt. Once the driver is installed, you open its device file to connect to the interrupt, and you close it to disconnect. You may use any signal - its your system - but it is good programming practice to restrict yourself to standard signal semantics: 01 Hardware termination (hangup) 02 Catchable interrupt 03 Quit and dump core 09 Kill absolutely and immediately (no cleanup!) 16 User defined signal 1 17 User defined signal 2 Adam Reed (mtgzz!avr)
mouse@mcgill-vision.UUCP (der Mouse) (03/13/88)
> In article <3102@cup.portal.com>, Chuck_SirVAX_Staatse@cup.portal.com writes: >> Does anyone know if UNIX supports a "Connect to Interrupt" facillity >> similar to VMS or RSX. Not out-of-the-box. A kernel hacker can build something of the sort. Presumably you need low interrupt latency. Good luck: UNIX has a tendency to spend large amounts of time (hundreds of microseconds) with interrupts blocked, because part of the design philosophy is that any amount of time a human can't notice is irrelevant. This is not the case if you are doing "real-time" work. >> has anyone cobbled something together? Target system is a 68000 VME >> based system. Any takers? At McGill here we built a fairly extensive system for robot control that required "real-time" response. We got it through the use of some horrible kludges and by throwing security completely out the window. I can provide details if anyone is really interested; the system is a MicroVAX-II running what started out as 4.3BSD. (I say "started out as" because we have had to do a good deal of hacking on it.) In article <3617@mtgzz.UUCP>, avr@mtgzz.UUCP (XMRP50000[jcm]-a.v.reed) writes: > UNIX provides a facility called "signals". Signals may be sent by > processes, open device files, or by the kernel. [suggests building a > driver to send the process a signal on a device interrupt] This will work fine, if you can tolerate the resulting latency. A signal can easily be delayed by twenty microseconds even if the process is in-core, which is probably more latency than can be tolerated if this application is such that it would use the connect-to-interrupt driver on VMS. And if the process happens to be swapped out to disk at the moment, forget it. der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu
beres@cadnetix.COM (Tim Beres) (03/25/88)
In article <991@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: > >At McGill here we built a fairly extensive system for robot control >that required "real-time" response. We got it through the use of some >horrible kludges and by throwing security completely out the window. I >can provide details if anyone is really interested; the system is a >MicroVAX-II running what started out as 4.3BSD. (I say "started out >as" because we have had to do a good deal of hacking on it.) > I've spent much time using RMX and VersaDos, both real-time OS's. What I want to know is why ya'll hacked up Unix. Why not just get RMX on an SBC, connect via ethernet to a UNIX system, and run with that? Cost is one concern no doubt. Plus the academic thrill of hacking UNIX. I've always thought marrying two systems, each of which is excellent (no flames, please) at what it does, would work nicely. Is anyone *out there* doing this type of thing? -- Tim Beres Cadnetix 303/444-8075 x221 5775 Flatirons Pkwy {uunet,boulder,nbires}!cadnetix!beres Boulder, CO 80301 beres@cadnetix.com <disclaimers: my thoughts != Cadnetix's>
berger@datacube.UUCP (03/28/88)
There are several vendors now who are offering the ability to connect
a Unix host to dedicated processors running "real-time" kernels either
via ethernet or on the same hardware bus. \
Heurikon has been offering a Unix host with other processors running
VRTX all on the same VME or Multibus.
Microware now offers the ability to connect processors running OS-9 to
Unix via TCP/IP / Ethernet.
Wind River Systems offers VxWorks which is an implementation of VRTX
with additional layers to serve as a connection between unix and the
dedicated processor via ethernet.
I'v have not worked with any of these systems except OS-9 and there we
have just started using the ethernet support. Its not clear what kind
of RPC capabilities or standards are used. I know the OS-9 version
lets you download programs, libraries and data from unix to os-9 as
well as allow telnet and ftp between os-9 and unix.
Microware: 515-224-1929 Andy Ball VP Marketing
Heurikon: 608-271-8700
Wind River Systems: 415-428-2623
Bob Berger
Datacube Inc. Systems / Software Group 4 Dearborn Rd. Peabody, Ma 01960
VOICE: 617-535-6644; FAX: (617) 535-5643; TWX: (710) 347-0125
UUCP: berger@datacube.COM, rutgers!datacube!berger, ihnp4!datacube!berger
{cbosgd,cuae2,mit-eddie}!mirror!datacube!berger