> > FSM is one of the few programming techniques that really
> > should be implemented in a graphical programming language.
>

Wouter van Ooijen wrote:
> I disagree:
> 1. A non-trivial state machine contains, beside the state-stuff itself,
> a lot of plain and (not so) simple code. I don't see how anything but a
> HLL (for asm lovers: assembler) would be usefull for that part.
>
Of course, once you get down into the *implementation* of what each
particular state represents and how it processes each "event" or condition
that it's supposed to react to... you'll have to deal with code (C, C++,
asm, whatever); that's a given.   But the _design_ of the FSM absolutely
doesn't have to be done at such a low level as to be tedious!  I've done
many such designs, and only proceed to write code after I've debugged the
"logic" on paper, with "bubbles" and "arcs" and "labels", using my brain
before getting near the simulator/emulator.  Sure, you can take what's in
your head and map it directly to code; but it's much more tedious and error
prone.

> 2. A non-trivial state machine contains far too many states, events and
> transitions to be reasonably represented in a graphical way. Think
> 10..20 states, same number of events.
  I will beg to differ on this, having developed many pieces of software
using FSM approaches.  The most recent that I did was a piece of
photographic equipment with interfaces to several buttons, sensors, display
and timers.  The state machine consists of 9 major states, each of which
breaks down into it's own FSM, some of which have 3 or 4 states, others up
to 8 states.  So there you've got about 60 unique states.  It's all
represented on about 10 pages of Visio documentation.  By careful choice of
naming convention, I can go from the diagram directly to the piece of code
that implements it.   It would have been VERY difficult (for me, anyway) to
"directly" capture this design in PIC asm without drawing it out very
methodically and debugging on paper first.
  In the pure "software" realm, I was a principal developer of a logic/fault
simulation tool when I was at DEC.  The kernel was designed as a FSM, with
30 major states and 256 event types.   Implementation was a HLL.  The
documentation (since we didn't have fancy tools then) covered 4 walls of a
12x12 room; without the visual representation, we'd *still* be there arguing
about how it should work! :^)
  The ASIC design groups I've worked with in the past have all used graphic
input tools rather than directly coding, even VHDL... which is in its own
right very adept at representing FSMs.  Why? because it's easier to draw
pictures and validate them (esp. as a team) and have the code generated by
the tools, than it is to plod throught it "manually".

I'm enthused about the idea that Anthony put forth!  I think there's a lot
of merit in "abstracting" those pieces of the design process that lend
themselves to it: FSM design is definitely one of those!

Jim

>
> -- -------------------------------------------
> Van Ooijen Technische Informatica: www.voti.nl
> consultancy, development, PICmicro products
>
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways.  See http://www.piclist.com/#archives for details.

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