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.
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.
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 -
these latter two tools are invaluable in a multi-developer situation.
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. Spam prevention: Contact me at mNaOtSkPiAnM@acm.org, removing the *NO SPAM* from the address.
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
: :
: : 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
John A. Laws voice: +1 416-856-5227 snipped-for-privacy@pathfindermda.com fax: +1 508-384-7906 _________________________________________________
... snip ...
... snip ...
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 (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
USE worldnet address!
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.