Dave Hansen wrote:

> On Fri, 06 Feb 2004 12:43:00 +0100, frank <frank36*2@inwind.it> wrote:
> 
>>Has anyone any experience in using the IAR VisualSTATE for developing,
>>verifing and testing of control software for 8 bit microprocessor?
>>
>>Thank in advance for any comment and suggestion.
> 
> I've used it on a couple projects.  Some random thoughts (my
> experience is with version 4.something):
> 
> It's not a silver bullet.  You'll still have to write code, and in
> fact, designing with statecharts is really just using a different
> programming language.
> 
> If you design with statecharts, your design and code will always be in
> sync.  The statecharts _are_ your code.
> 
> Editing statecharts is clumsy.  Restructuring C code in an editor you
> know is easier and faster than restructuring your statecharts.  But
> it's not a lot worse than modifying statecharts in, e.g., Visio.
> 
> It's a very powerful and flexible tool.  A means is generally provided
> to do anything you think you might need to do.  In fact, I'm still not
> sure what some of the transition options do.
> 
> I never found a bug in the generated code.
> 
> The generated code is reasonably efficient.  Example: a non-trivial
> system whose generated code occupied about 1800 bytes, with another
> 1200 bytes of "driver" code.  Usable on systems with 4k or more
> program memory.
> 
> Your C compiler better be pretty close to ANSI.  Cosmic C for the
> HC908 works well.  CodeVisionAVR doesn't work at all.  Avr-gcc can be
> made to work, though it is clumsy (e.g. declaring an array "const"
> does not put it into flash).  I expect it would work well with IAR
> compilers, but I've never tried it.
> 
> There is a statechart simulator/debugger included, though it is more
> effective to build a test harness, i.e., driver code that runs on your
> development PC that simulates your target platform.
> 
> You're better off using driver code to meet real-time requirements
> rather than trying to satisfy them in the statecharts.  It's not that
> they're slow, it's just that it's not obvious what the overheads are.
> 
> Summary: it's the only "CASE" system I've used whose generated code is
> usable as-is on small systems.  It may not make your systems work
> better, or make them any easier to maintain (unless you really think
> in sttecharts rather than C), but they will be well-documented.
> 
> HTH,
> 
>                                -=Dave

thank you very much.

On Fri, 06 Feb 2004 12:43:00 +0100, frank <frank36*2@inwind.it> wrote:

>Has anyone any experience in using the IAR VisualSTATE for developing,
>verifing and testing of control software for 8 bit microprocessor?
>
>Thank in advance for any comment and suggestion.

I've used it on a couple projects.  Some random thoughts (my
experience is with version 4.something):

It's not a silver bullet.  You'll still have to write code, and in
fact, designing with statecharts is really just using a different
programming language.

If you design with statecharts, your design and code will always be in
sync.  The statecharts _are_ your code.

Editing statecharts is clumsy.  Restructuring C code in an editor you
know is easier and faster than restructuring your statecharts.  But
it's not a lot worse than modifying statecharts in, e.g., Visio.

It's a very powerful and flexible tool.  A means is generally provided
to do anything you think you might need to do.  In fact, I'm still not
sure what some of the transition options do.

I never found a bug in the generated code.

The generated code is reasonably efficient.  Example: a non-trivial
system whose generated code occupied about 1800 bytes, with another
1200 bytes of "driver" code.  Usable on systems with 4k or more
program memory.

Your C compiler better be pretty close to ANSI.  Cosmic C for the
HC908 works well.  CodeVisionAVR doesn't work at all.  Avr-gcc can be
made to work, though it is clumsy (e.g. declaring an array "const"
does not put it into flash).  I expect it would work well with IAR
compilers, but I've never tried it.

There is a statechart simulator/debugger included, though it is more
effective to build a test harness, i.e., driver code that runs on your
development PC that simulates your target platform.

You're better off using driver code to meet real-time requirements
rather than trying to satisfy them in the statecharts.  It's not that
they're slow, it's just that it's not obvious what the overheads are.

Summary: it's the only "CASE" system I've used whose generated code is
usable as-is on small systems.  It may not make your systems work
better, or make them any easier to maintain (unless you really think
in sttecharts rather than C), but they will be well-documented.

HTH,

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