Lpc2000

Good questions.  I will try to provide good answers.

First of all, let me say that a real-time system is one that waits.

If a CPU is too busy to service external stimuli, then the system is
no longer running in real-time. The antithesis of real-time
programming then, is the loop.  In sequential programming,
programmers ofter create temporary states by inserting polling loops
or spin loops in the sequence of a thread's execution to test
continuously for a certain condition whether it be a period of time,
or input condition.  This programming strategy flys in the face of
resource sharing as it ties up the CPU with a job better performed
in hardware.  As a consequence, RTOS's 'fix' this 'problem' by
introducing context swaps where a timed interrupt occurs and the
current processor and thread state are saved and a new one is
switched in.  This may seem like an good solution, but the real
problem was the loops in the first place.  The real solution is to
not use loops in the programming sequence, but let the thread be
broken up into a sequence of states which are run on their own
without looping.  So at a high level, the state machine paradigm is
introduced to the programmer giving them a better mechanism to
structure their sequential threads within and to better match
reality.  Each state has a set of conditions that are tested for,
and if true, then the consequent actions are exectuted and the next
state is made current.  A final program then, is a collection of
these state machines.  Better processing is achieved by tossing out
loops and getting rid of context switching mechanism.  The QF that
you mention, takes a similar approach but unlike IsoMax, requires
external tools to support it.  As for VHDL, I've programmed in that
as well but while it tries to be like embedded programming
languages, it is a lot more cumbersome to use and the target is
specifically hardware usually gate arrays.  One of the intended
future options will be to support hardware programming directly from
IsoMax using granular computers (the part that is missing from
VHDL).  For more on granular computers, see:
http://www.compusmart.ab.ca/rc/Papers/FCinGC.pdf

In addition, IsoMax supports both synchronous and asynchronous state
machines.  The synchronous state machines (SSM) are run from a
periodic clock that is settable according to the system's needs. 
Like hardware, SSMs are executed each clock period checking event
conditions, executing actions and changing states if conditions are
met.  All the SSMs that are active, are run each clock cycle by just
checking for state contexted events and processing is minimized. 
Asynchronous state machines (ASM) can happen at any time as they are
wired directly to the interrupts.  When an interrupt occurs, the ASM
tied to it will be executed.  In a sense, the SSMs are specific
sub-set of ASMs.  Data moving between any state machines can be put
into a queue (semaphore-less) or just a variable (short queue with
no elasticity).

While there is no explicit mechanism to support hierarchial state
machines, state machines can be controlled by other state machines
so that hierarchial state machines can easily be implemented.  In a
future release, OO extensions will be added to allow for better
pattern reuse from simple objects to state machines.

The only foreground activity is the command line which can be used
to interactively work with the running state machines, control the
processor or compile new state machines.

Rob

--- In lpc2000@yahoogroups.com, "microbit" <microbit@c...> wrote:
> Hi Rob,
> 
> Curiosity questions :
> 
> Does IsoMax use the princple of hierarchical State Machines like
> in eg. the QF - Quantum Framework - for State Chart programming ?
> 
> How do you intend to achieve better "parallel" processing as such ?
> State Machines on many occasions have worked much better for me than
> RTOS, but there's of course 1001 ways to write an FSM, and this has
> had my specific interest since a little while, using a more object oriented
> approach for State Machines.
> 
> Running many State Machines in "parallel", how does the CPU decide
> where its time is best spent, without having to fall back on a "polling"
> approach where the "foreground" actually really runs in the background ?
> 
> The challenge is certainly worthwhile, the only time this kind of
> programming has been possible for me in the past was in VHDL :-)
> 
> B rgds
> Kris
> 
> 
> ----- Original Message -----
> From: "chazeltopman" <rob@n...>
> To: <lpc2000@yahoogroups.com>
> Sent: Wednesday, November 03, 2004 5:18 PM
> Subject: [lpc2000] IsoMax for ARM
> 
> 
> >
> > For all those programmers out there that wish to explore a new
> > programming paradigm, IsoMax for ARM is available as a preliminary
> > release from New Micros on 2106 and 2129 development boards.  While
> > fully functional, the final set of features is still variable and
> > open to suggestions.  [www.newmicros.com]
[snip]