IAR visualSTATE: Opinions wanted

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

Translate This Thread From English to

Threaded View
Hello,
Has anyone in this group tried IAR's visualSTATE?
This is a graphical tool that generates code from state charts, I messed
around with it a while back and thought it was very impressive indeed (I
don't work for them!), but never got as far as using it in a full scale
project.  Just wondering if anyone out there has, and how they found it?
Regards,
Richard.



Re: IAR visualSTATE: Opinions wanted
On Tue, 9 Sep 2003 22:00:37 +0100, "Richard Phillips"

Quoted text here. Click to load it

We used it for a project that eventually got cancelled (not because of
VisualState).

It works, and it works well.  The generated code was reasonably small
(less than 3k on an HC908 in our case, including the state machine
itself) and fast enough.  You never have to worry about statecharts
getting out of sync with the code because the statecharts generate the
code.

However, it's not magic.  Using VisualState means you are coding in
VisualState rather than C or Assembly.  You can't escape the
implementation details.

Regards,

                               -=Dave
--
Change is inevitable, progress is not.

Re: IAR visualSTATE: Opinions wanted
On Tue, 09 Sep 2003 23:50:10 GMT, snipped-for-privacy@hotmail.com (Dave Hansen)

Quoted text here. Click to load it

i evaluated it for a medium sized project .. the thing that kept us
from using it was that we could not close the loop .. could not make
changes in the generated code (debugging) that would then be merged
back into the design.  Having to always work forwards from the design
is, IMHO, a serious limitation.

however, my team did use the combination of IAR's IDE with
Mitsubishi's ICE, Beyond Compare and Understanding

BC - http://www.scootersoftware.com /
Understanding - http://www.scitools.com /

these latter two tools are invaluable in a multi-developer situation.


Re: IAR visualSTATE: Opinions wanted

Quoted text here. Click to load it

This kind of surprises me.  Could you please explain (in more detail)
what you were trying to do and how this affected your project.  

I'm not really one of the visualSTATE developers (I'm a compiler
developer), but have a personal intrest in it and can forward the
information to the right people.

Best wishes,
Mats Kindahl
--
IAR Systems in Uppsala, Sweden.

Any opinions expressed are my own and not those of my company.

We've slightly trimmed the long signature. Click to see the full one.
Re: IAR visualSTATE: Opinions wanted
Quoted text here. Click to load it

I totally agree with this comment.  Exactly the same happened to me with
Matlabs Embedded Workshop tool for Simulink.  Sure its great how you are
(theoretically) "able to modify, add your own and compile the generated
code", but as soon as you start to see some parts of the generated code
that you don't like or are not as efficient as you would like, then the
fun starts... First you find yourself fiddling with the pictures to try
and convince the code generator to make some specific changes, then when
you give up and hand modify the code, you end up losing the benefits of
the high-level graphical input system (such as flexibility, simulation,
representation of the system, auto-documentation and flow-charting) and
all you are left with is a framework of inefficient code dressed with
some correctly handcoded parts.  

Matlab has a facility to import your own blocks of code into the picture
(like a little box that says "your own code here"), but there's very
little you can do with it.  In my case, the imported code definitely
killed any simulation ability of the model.  And you can hardly blame
them for this, it would seem like an impossible task to make a simulator
graphically interpret arbitrary c code.

Six months into the project, after about 20% of the task had been
"graphically designed and implemented", we ran out of RAM and ROM space
- so we opted for a complete rewrite.  No RAM/ROM was added to finish
the work (just imagine our surprise, we only got 20% of it done the
other way).  

In the end I felt that these high level tools are good for only some
situations.  eg for huge projects where you have a massive amount of
resources (ROM/RAM/CPU, programmers) and the problem of coordinating
many programmers is a bigger issue than getting more hw resources, or in
an educational environment where you need great system flexibility and
graphical teaching tools (and possibly little or no optimisation) eg one
day you are simulation a rocket, next day you are designing a traffic
light controller.  

just my observations from a sample space of 1 project






Re: IAR visualSTATE: Opinions wanted

Quoted text here. Click to load it
:
:
Quoted text here. Click to load it
:
:
visualState and Matlab can be excellent for the broad middle-ground for
which
their code generators have been designed, and many projects can live with
the
design decisions that have been built into their hardwired into their closed
and
proprietary model transformation engines.  In this, they are like the
majority of
other modeling/simulation/implementation/execution enviroments in the
embedded
market.   Round-tripping doesn't really help this either, since the fixed
mapping
between model elements and their implementation precludes many design
choices
that the engineer may wish to consider.  Forward engineering isn't the
culprit here.
Rather, it's the inability to make choices about the implementation of the
model.

Portability and re-usability (not to mention usability) of the model is
significantly
degraded if the model (i.e. logical architecture, business logic, etc.)
cannot be
expressed platform-independently and the issue of implementation is not a
strictly
separate concern.  The best current approach to platform independence is to
express design choices regarding implementation separately from the model in
openly modifiable transformation templates expressed in an understandable
scripting language expressly designed for specifying model transformations.
You get precisely the implementation you want from the model.  You get
forward engineering that works.  You avoid the conflicts that arise when you
make changes in multiple places trying to round-trip the model and generated
code.

These, and related, ideas have been getting significant play at recent OMG
technical meetings and embedded systems conferences.  You can obtain tools
and related training and consulting that enable these capabilities from
Pathfinder
Solutions www.pathfindermda.com.  Note that this solution is vendor-
independent (as well as platform independent) in that their engine can in
principle
back-end any model editor that emits XMI or for which an XMI emiter can be
built.
Pathfinder has service relationships with several of the front-end tool
vendors and is
very agile regarding teaming and partnering arrangements.  See the website.
Read
some white papers.  Give us a call.
_________________________________________________
 Pathfinder Solutions       www.pathfindermda.com
 Put MDA to Work.                       888-662-PATH

 John A. Laws                  voice: +1 416-856-5227
  snipped-for-privacy@pathfindermda.com   fax: +1 508-384-7906
_________________________________________________




Re: IAR visualSTATE: Opinions wanted
Quoted text here. Click to load it
... snip ...

Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

You wrote something totally unreadable (at least to me) by
ignoring standards for line length in newsgroups.  You should
limit your lines to no more than 80 chars, preferably about 65.

In addition your sig line above is a violation of standards.  It
should be limited to 4 lines, prefixed with precisely "-- " line.

When you are trying to sell your software, I would expect you to
be extremely careful to follow standards.  The above problems do
not reflect well on your firm.

At least you are not using HTML. :-)

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline