Path: utzoo!mnetor!uunet!swlabs!jack
From: jack@swlabs.UUCP (Jack Bonn)
Newsgroups: comp.arch
Subject: Re: RISC != real-time control
Message-ID: <832@swlabs.UUCP>
Date: 8 May 88 13:38:06 GMT
References: <1534@pt.cs.cmu.edu>
Reply-To: jack@swlabs.UUCP (Jack Bonn)
Organization: Software Labs, Ltd., Easton, CT
Lines: 31

From article <1534@pt.cs.cmu.edu>, by schmitz@FAS.RI.CMU.EDU (Donald Schmitz):
> In article <1521@pt.cs.cmu.edu> koopman@A.GP.CS.CMU.EDU (Philip Koopman) writes:
> 
>>Real-time control programs often have a situation where only
>>X microseconds are available to perform a task.  .....
> 
> This may be straying somewhat from the original point, but what sort of
> applications really have such exact timing deadlines?  I have done a little
> real-time motion control, ....

The worst system for real time deadlines I ever worked on was one
that implemented the control functions for a bottle making machine.
This wasn't a bottler; it took molten glass and formed it into bottles.

We had a 2.5 MHz Z-80 and a periodic interrupt whose period was 1 msec.
Doesn't leave much time for background processing.

The worst case was if an output to the scoop was delayed.  Rather than
catching the molten gob of glass in flight, it would fling it across the 
plant floor.  If it hit anyone, it would stick to their skin and most likely
result in an amputation.

Since I had previously worked on central office software, this gave me
a much more clear view of real time.  I used to worry about what would
happen if a dial tone or compelled signaling tone was delayed.  Ah, the
good old days.

-Jack
-- 
Jack Bonn, <> Software Labs, Ltd, Box 451, Easton CT  06612
uunet!swlabs!jack