How you guys consider of using a tool such as IAR's VitualState

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
hi,

i've already read though its feature list. but i still want to know
your personal opinions.  how about the product and how you think about
of using a WYSIWYG design tool in real life.

i personally prefer non-WYSIWYG tool.  for FSM, i like to write down a
plain-text transmission table ( a matrix ) such as below,

   StateFrom StateTo  EventA/doFoo
   ...

then have a tool draw any kind of graph for me, including postscript,
pdf or jpeg.

by doing job this way i found i can easily maintain graphs and focus on
core business problems without fussing on drawing and layout.

another benefit comes from version controlling. because the graph is
plain-text and human readable, it is so much more easier than binary to
be managed by a version control system such as CVS or Subversion.


another question is about code-generating.  VisualState can generate
code for a FSM.  in you opinions, how much benefits you can get from
the capability ?  and what is the possible drawbacks ?  ( i always
consider code-generating as pain for it introduces another kind of
dependence into code )

any comments will be appreciated.

-
woody


Re: How you guys consider of using a tool such as IAR's VitualState
On 1 Dec 2005 22:22:50 -0800 in comp.arch.embedded, "Steven Woody"

Quoted text here. Click to load it

It's a good tool, but it's not a magic bullet.  It doesn't save you
from coding, the drawing _become_ the code.  But the "language" is
powerful and practical.

I used the Composer version 4.something.  It was a little clunky, but
quite usable, about on par with Visio.  Newer versions might be
better.

Quoted text here. Click to load it

Over the past 20-some years, I've been intrigued by "graphical
programming languages," but generally unimpressed.  VisualState is the
only graphical programming tool that I feel is easier to understand
than code or pseudocode.

Quoted text here. Click to load it

You might look at Samek's book on statecharts.  Some of his ideas
might help you go the other direction as well, to automatically
generate some of your code.

Quoted text here. Click to load it

Agreed.  Managing different versions of the statecharts in VS is a
pain.  AFAIK, there's no plain-text output from VS to simplify
revision control.

Quoted text here. Click to load it

Even back at V4, VS generated good, tight state machine code.  It uses
a sensible table-driven architecture with low overhead (I estimate
about 2K Flash on an HC908), and it's quite fast. And no manager ever
asked me to flowchart code written in VS.

It does rely on the compiler supporting ANSI C, though.  One compiler
I tried to use did not support typedef of a pointer to function, so I
couldn't use it without hand-modifying the generated code.  I.e., I
couldn't use it.  At least not the generated code -- The statecharts
were done, so I mechanically translated them by hand.  A bit (or
more!) of a pain.

Quoted text here. Click to load it

HTH,
   -=Dave
                                        -=Dave

--
Change is inevitable, progress is not.

Re: How you guys consider of using a tool such as IAR's VitualState


I used it and I liked it a lot.
It takes short time to get used with it but then you save a lot of
coding time.
It gives you a better view of your problem and at the end you have a
nice description (state chart) of your work which anybody can
understand.
The best benefit is when it comes to modify older code, you see the
chart, you don't have to read tons of code lines to understand what's
doing, just few mouse clicks and you are in.
I used it with RCS versioning control with no problem.
And, after all the generated code is much smaller being based on
look-up tables. Of course you can write your own code using lookup
tables but it will be very abstract and very hard to modify later.
I would say that this software lets you concentrate on how to solve the
problem not on how to implement the solving.

Of course, it is efficient for large state machines with many states.
If you have small state machines with just few states, don't bother to
use it.

Another nice feature is the use of hierarchical state machines. Again,
I know that everything can be done by simply writing code, but why
think on how to move from a state to another in text code when a simple
arrow, drawn with the mouse, can do this for you. And, if you change
your mind and want to jump to another state, just drag the arrow to it.

Your specification is also updated for free.


Re: How you guys consider of using a tool such as IAR's VitualState
I have been using VS for about a year now, and I can't imagine going
back to manual.

I use it for the menu system on an embedded device. I did the last
project manually, but every time I had to make a change, it was
painful.  And the interaction of states was just getting too hard to
understand and manage.

I wouldn't bother with a smaller project, by I would hate to have to
implement my 12 page by 3 page drawing manually.

So far, the only thing I don't like is that if I am going to use a
variable internally, I have to define it internally.  I have a couple
of state-like indicators that I think should be defined outside VS, but
it won't let me if I'm going to make decisions based on them in the
state machine.  It's a pretty minor issue though.

BTW, VS now allows you to use "switch" if your compiler won't do a
pointer to function.


Re: How you guys consider of using a tool such as IAR's VitualState
snipped-for-privacy@gmail.com says...
Quoted text here. Click to load it

It's no more difficult to version control than binaries.  Although I
think a lot of these have move back to a textual representation.

Quoted text here. Click to load it

I evaluated VisualState at one time.  I preferred BetterState's code
generation (and a few other things) but I'm not sure that is even still
available, if so it's certainly seems to be being kept quiet.  If anyone
knows anything about it I'd like to hear.  Both systems have been updated
since I did the evaluation and it wasn't as if one was bad and the other
good they just had different approaches.

The big advantage I see to the visual layout of both products is the
capability to easily see that all transitions are properly accounted for.  
Also I find transitions to and from nested states are much much easier to
follow graphically than textually.

The biggest disadvantage I find is that both BetterState and VisualState
are dongled.  A secondary disadvantage is that neither, the last I looked
could have their code generation commandline driven so they are difficult
to itegrate into a makefile or othe build environment.  Actually that's a
criticism that can be levelled against a lot of these lower level case
tools, they all seem to think that the world should revolve around them.

I did a set of test systems in BetterState once.  They ran from 30 to 90
pages each as I recall each with somewhere between 2 and 5 or so states
on them.  They worked quite well and I found them to be reasonably
maintainable although the states really in many places were more of a
flow chart.  I ws probably pushing the upper end of the size scale
though.

Size of the generated code is not a problem generally although
BetterState at one point insisted it needed malloc even when it wasn't
necessary (that has been fixed).

I redid a set of interlock logic at one point, the code size was a little
larger but it was also more complete.  

Robert

Re: How you guys consider of using a tool such as IAR's VitualState
Quoted text here. Click to load it

Actually the VisualState files are not binaries, they are in text
format.


Re: How you guys consider of using a tool such as IAR's VitualState
Visual state can be run through command line. The command is "coder.exe"


Re: How you guys consider of using a tool such as IAR's VitualState
snipped-for-privacy@yahoo.com says...
Quoted text here. Click to load it

That is nice to know.


Robert

Site Timeline