realtime design

[Armin Steinhoff]

Tim Daneliuk <tundra at tundraware.com> wrote in message news:<013goa.m8c.ln at boundary.tundraware.com>...
> Will Stuyvesant wrote:
> > We would like to prototype a realtime system.  Is anybody doing this using Python?
> > 
> > '''
> > A lost ounce of gold may be found, a lost moment of time never.
> > '''
> 
> Much has already been posted here but I would add this:
> 
> There is an inherent problem with the term "realtime" if it is not
> further qualified.  All realtime systems must typically cope with external
> asynchronous events as their principal paradigm - i.e., Asynchronous
> events determine control flow of the code not some master algorithm.
> However, all such systems are not equal.  Generally, we can think about
> two classes of realtime systems:
> 
> 1) "Hard" realtime - cases where timing must be predictable and guaranteed.
      
Yes ... _and_ the application has to meet its deadlines, because in
hard real-time systems results must be provided in a timely manner.

>      For example, "You must respond to the Flabergast Interrupt in less than
>      100 us and guarantee it is serviced completely in 1ms."

No ... speed has nothing to do with hard real-time ... it is only a
technological attribute which says something about the possible time
resolution of a real-time system. The interrupt could be handled in
100h ... but the service _must_ be completed by meeting its deadline.

Only timely provided results a valid results ... that's simply hard
real-time.
 
>  This kind of
>      thing is common in machine control and military fire control systems.
> 
> 2) "Soft" realtime - cases where you must respond to external events in
>      a reasonable amount of time and preserve proper *sequencing*, but the
>      absolute amount of time is neither guranteed nor particularly important
>      unless it gets ridiculously long.  A good example of this is the
>      message processing and dispatching common in a GUI manager.

Results are valid in a soft real-time if the results are provided with
a defined jitter around a deadline.

> 
> I would argue that Python is possibly suited to 2) and probably poorly suited
> to 1).

Yes ... the CPU time for the garbage collection is completely
unpredictable, so Python could be used just for soft real-time
applications.

But ... when I remember rigth, there is a possibilty to switch off
Python's garbage collection .. isn't it?

> The reason I say this is that things like background garbage
> collection, interaction with lower-level system services like I/O and so on
> make guaranteed, predictable service times essentially impossible (unless
> the guarantees are so weak and the permissible times so long that it does
> not matter - but this is not ordinarily the case in hard realtime).
> 
> It might be possible to shoehorn Python into a hard realtime environment
> for some functions like dispatching if one wrote a sufficient amount of
> binder code in a lower level language like 'C' or Assembler, but why
> bother?  Python is a marvelous language with many merits, but it cannot do
> everything - no language can, nor should it be expected to. - Shameless
> promotion of my ideas on *that* subject can be found at:
> 
>                    http://www.tundraware.com/Technology/Bullet/

Under QNX you can use a C coded message passing extension in order to
communicate with an external process which can do the hard real-time
(HRT) stuff for Python. In such a case Python and the HRT process are
running in seperate protected address spaces. Sending a message with
~64 bytes and receiving it back takes 5 microseconds ... so it is
realy fast.

This is a very good alternative to build an other kind of dynamical
extensions for Python for robust and secure RT applications.

Use Python for the top level logic and RT extensions for the HRT
processing :)
 
> If you shudder at writing in Assembler or 'C', give Forth a good look
> for this sort of thing.

Pyrex is much better than Forth :)

Cheers

Armin Steinhoff

http://www.steinhoff-automation.com