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

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.

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.

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.

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.

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.

HTH, -=Dave -=Dave

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.

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.

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

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

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

Visual state can be run through command line. The command is "coder.exe"

That is nice to know.

Robert