IAR VisualSTATE

Started by frank February 6, 2004
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.

Roberto. 
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.
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.