Lpc2000

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]

As an introduction to IsoMax, let's start with what most of us do
best: we write sequential programs.  This problem solving
methodology originated way before computers and is really an
extension of our thinking and the world we live in.   Since we live
in a time ordered universe, things unfold sequentially.  The most
widely used programming languages allow us to sequentially describe
solutions to problems that we are solving whether it be a blinking
LED, a motor control sequence, a protocol stack, etc.  We run into
limits though when the paradigm no longer fits.  This could be
memory, processor speed, or other resource limits.

Doing one thing at a time is easy.  The difficult side to
programming is doing many things at once.  Again, like the world we
live in, multiple things happen sequentially and also at the same
time.  This parallel dimension of the world makes programming much
more difficult and the nexus of solutions to manage the complexity
usually involves an RTOS or at least some multi-threaded,
time-sharing mechanism which takes the single processor resource and
shares it with multiple programs which operate like they are all
running in parallel.

IsoMax takes a different approach.  The world can be thought of as a
collection of state machines where each state machine runs
independantly of each other and can be used to locally describe
sequential events that cause actions and new states that describe a
changed state.  IsoMax embraces this state machine paradigm fully
and gives structure to your programs allowing you to program
sequentially and in parallel by partitioning a program into multiple
state machines each running independant of the others.  For
instance, in a sensor pod each sensor would have a state machine
which be responsible for the sensor and other state machines would
be added to further process the sensory data as needed.

Both synchronous and asynchronous state machines are supported. 
Synchronous state machines are ones that run according to a clock
while asynchronous state machines are ones that are triggered by
hardware events such as interrupts.  Even more difficult than
parallel programming is trying to get interrupts to work.  IsoMax
for ARM puts a thin layer on top of all the interrupts taking care
of the complexity and makes them easy to program, just like normal
programming.  Probably the most powerful way to get an ARM resource
up and running using interrupts is interactively.  Instead of
editing, saving, compiling, linking, downloading, testing, kaput;
imagine modifying and testing interrupt code using command line
access on the ARM while it is running.

The beauty of the whole system is all that you need to program
IsoMax for ARM is to have a serial COM port that runs at 115k or a
USB port, a terminal program and a text editor.  In addition to the
state machine support, the IsoMax for ARM system includes a command
line, a compiler and debugging tools.

Briefly, IsoMax for ARM includes a fully supported state machine
programming paradigm, 1 us timeouts, queues, high level interrupts,
fuzzy logic, random numbers, flash storage, full peripheral register
access, autobooting, floating point, interactive development, full
32 bit, double numbers for 64 bit, debug facilities and it runs real
fast.

If you are interested in trying out this system or would like to
participate in its final feature list, contact New Micros on the
web.

Thank you for your time.

Rob

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@...>
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]
>
> As an introduction to IsoMax, let's start with what most of us do
> best: we write sequential programs.  This problem solving
> methodology originated way before computers and is really an
> extension of our thinking and the world we live in.   Since we live
> in a time ordered universe, things unfold sequentially.  The most
> widely used programming languages allow us to sequentially describe
> solutions to problems that we are solving whether it be a blinking
> LED, a motor control sequence, a protocol stack, etc.  We run into
> limits though when the paradigm no longer fits.  This could be
> memory, processor speed, or other resource limits.
>
> Doing one thing at a time is easy.  The difficult side to
> programming is doing many things at once.  Again, like the world we
> live in, multiple things happen sequentially and also at the same
> time.  This parallel dimension of the world makes programming much
> more difficult and the nexus of solutions to manage the complexity
> usually involves an RTOS or at least some multi-threaded,
> time-sharing mechanism which takes the single processor resource and
> shares it with multiple programs which operate like they are all
> running in parallel.
>
> IsoMax takes a different approach.  The world can be thought of as a
> collection of state machines where each state machine runs
> independantly of each other and can be used to locally describe
> sequential events that cause actions and new states that describe a
> changed state.  IsoMax embraces this state machine paradigm fully
> and gives structure to your programs allowing you to program
> sequentially and in parallel by partitioning a program into multiple
> state machines each running independant of the others.  For
> instance, in a sensor pod each sensor would have a state machine
> which be responsible for the sensor and other state machines would
> be added to further process the sensory data as needed.
>
> Both synchronous and asynchronous state machines are supported.
> Synchronous state machines are ones that run according to a clock
> while asynchronous state machines are ones that are triggered by
> hardware events such as interrupts.  Even more difficult than
> parallel programming is trying to get interrupts to work.  IsoMax
> for ARM puts a thin layer on top of all the interrupts taking care
> of the complexity and makes them easy to program, just like normal
> programming.  Probably the most powerful way to get an ARM resource
> up and running using interrupts is interactively.  Instead of
> editing, saving, compiling, linking, downloading, testing, kaput;
> imagine modifying and testing interrupt code using command line
> access on the ARM while it is running.
>
> The beauty of the whole system is all that you need to program
> IsoMax for ARM is to have a serial COM port that runs at 115k or a
> USB port, a terminal program and a text editor.  In addition to the
> state machine support, the IsoMax for ARM system includes a command
> line, a compiler and debugging tools.
>
> Briefly, IsoMax for ARM includes a fully supported state machine
> programming paradigm, 1 us timeouts, queues, high level interrupts,
> fuzzy logic, random numbers, flash storage, full peripheral register
> access, autobooting, floating point, interactive development, full
> 32 bit, double numbers for 64 bit, debug facilities and it runs real
> fast.
>
> If you are interested in trying out this system or would like to
> participate in its final feature list, contact New Micros on the
> web.
>
> Thank you for your time.
>
> Rob
>
>
>
>
>       Yahoo! Groups Sponsor
>             ADVERTISEMENT
>
>
>
>
>
> --------------------------------------------------------------------------
------

> Yahoo! Groups Links
>
>   a.. To visit your group on the web, go to:
>   http://groups.yahoo.com/group/lpc2000/
>
>   b.. To unsubscribe from this group, send an email to:
>   lpc2000-unsubscribe@yahoogroups.com
>
>   c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>

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]

Hi Rob,

The IsoMax approach seems rather innovative.
I don't have a direct need for such thing on ARM, as I'm quite tied
up with my RF product on MSP430 (but it's ready to port to ARM).

This is something I'd certainly be interested to visit at a later stage.

Another question : Does IsoMax assist with identifying dead states
and the like ? Or is this completely left to the user ?

Some other comments :

[snip]
> 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.  

Taste again I guess :-)
I prefer it over Verilog because you can have functions.
It is indeed rather verbose though :-)

> 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

I'll take a look at this.
So much to learn, so little time :-)

-- Kris

--- In lpc2000@yahoogroups.com, "microbit" <microbit@c...> wrote:
> Hi Rob,
> 
> The IsoMax approach seems rather innovative.
> I don't have a direct need for such thing on ARM, as I'm quite tied
> up with my RF product on MSP430 (but it's ready to port to ARM).
> 
> This is something I'd certainly be interested to visit at a later stage.
> 
> Another question : Does IsoMax assist with identifying dead states
> and the like ? Or is this completely left to the user ?

 No direct tools but it is easy enough to build your own although it depends
 on the speed of the states and how you want to detect it.  An easy way is
 to print to the display but this can easliy overload the display with 
 too much text.  Another way would be to OR bits in a variable and then
 after testing, the variable could be queried.  A third way is to use the
 three LEDs to display one of eight conditions.  When I was building a
 state machine for the soft UART, I wired up all the transitions to different
 LED settings.  Just observing the flashing LEDs gave me a visual
 indication of how the state machine was running and enabled me to
 debug it.
 
> 
> Some other comments :
> 
> [snip]
> > 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.  
> 
> Taste again I guess :-)
> I prefer it over Verilog because you can have functions.
> It is indeed rather verbose though :-)

 Agreed.  I also get burned tho when something works in simulation
 but won't compile for the target because the target lacks resources.
 This happened for division.  I could use it fine in simulation but for
 the hardware, I had to define my own division module.  Ack!  When
 programming a micro, this doesn't happen.

 Rob