Wouter van Ooijen wrote:

> > So I have decided to make an FSM compiler, you define the FSM in a
> > structured language, and the resulting ASM makes the pic behave as
> > described.
> >
> > Is there any need for this?
>
> What would be the advantage over coding the FSM in another HLL, let's ay
> C or Jal? IMHO all the features of a normal HLL would be needed, both
> inside the FSM 'event-handling' and outside it (initialisation,
> interrupt handling). And the logical of a FSM is very simple. So if your
> plan makes any sense at all it would be as an add-on to a HLL, maybe as
> a preprocessor, but I would never use it, learning a new tool would be
> more trouble than coding the FSM myself. (NB I have coded lot's of
> FSM's, for instance datacommunication protocols).
>
> Wouter van Ooijen

Hi Wouter,

A good state machine programming tool is like a powerful high level language
compared to machine code. Yes we can all write a few lines of assembler and hand
code it into machine code but life is so much easier if we use an assembler and
it is much easier still if we use a good compiler.

When you code a state machine directly into a program using variables, constants
and sequences of code, you keep the important information in your head. The
compiler or assembler cannot validate the use of this information or generate
code based on it because it does not have access to it. The harder you try to
encapsulate this information with your program, the harder it is to do something
simple with your program. Overheads start to get bigger, debugging gets harder
and your overall view of the solution gets cloudy. Consider a loop construct in
a high level language such as C. If you implement this with "if" and "goto"
statements the compiler will try to optimise your code. If you use a "for"
statement the compiler will be able to perform MUCH better optimisation because
it can look for things inside this section of code which it could not look for
in the hard coded "if" / "goto" section.

A good state machine programming tool is infinitely better than this. It will
let you experiment in ways you probably would not normally dream of. The only
way I can describe it is like this: you have a simple idea you want to test, 10
lines of complicated 'C' a few "printf" calls and a few minutes of tinkering
gives you the answer. Maybe your few minutes of tinkering takes you in other
directions. The high level representation of your code combined with the
feedback lets you see something. Now try to do the same thing in assembler.
Maybe a few hours work building a 200 line equivalent or maybe the equivalent is
a 1000 lines long and takes you a few days to build. Then you have to run it
through the simulator to get your feed back. Are you going to see the same
connection between your code and the results? Are you going to tinker with it
for a few weeks to see where it leads?

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising structured PIC BASIC compiler

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.