🚀 go-pugleaf

tonyn@tiac.net (Tony Nelson) wrote:
>
>Deterministic real-time processing is difficult to do with interrupts. 
>You really can't tell when all the interrupts will stack up at the same
>time, causing the lowest priority interrupt to wait a long time.  Coupled
>with the overhead of context switching, this makes interrupt-driven
>programming impractical for device controllers (such as, say, a car or a
>wheelchair).  Polling with a heartbeat timer is used instead.  The most
>time-critical tasks are polled oftenest.  Processing of different tasks is
>distributed in time by spreading out the polling.  Such systems can more
>easily be proved to work, which is comforting for the person in the
>wheelchair who is crossing a busy street.

In this case I'd use a different hardware scheme and still use interrupt
processing in the controlling OS.

 1. Distribute the intelligence by using separate processors
    wherever very frequent or critical events are occuring.
 2. Use DMA, to accumulate the data rather than pass it through
    the controlling OS.
 3. Restrict the controlling OS's interrupt handling to noting
    the location of the data and setting a flag.
 4. Design for peak loads. If doing this still isn't fast
    enough then iterate heirarchically over 1-3 above.

Note that the above scheme can generally use much simpler hardware
at each stage.  Caching hardware is not advised.  Of course, such
a machine would make a horrible number cruncher.

-- 
Sphere.

Find a Linux/GNU Group for you: http://www.tiac.net/users/williams/lugnuts/
Buy Free UNIX!
Microsoft is prohibited from examining any packet containing data
originating on any machine which I am using. (Not that I can stop them.)