IAR VisualState State machine code generation

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

Translate This Thread From English to

Threaded View
I have been using State machine based design tools for some time, and have =
seen UML modeling tools that allow you to execute your logic (call function=
s, do other stuff) inside a state. However, after spending a couple days wi=
th IAR VisualState, it appears that you cannot execute your logic inside a =
state without a trigger. I am confused as it does not make sense TO HAVE A =
TRIGGER for every single action inside a state !

Here is what I expect from a state chart tool: If I enter StateA, upon ente=
ring the state I set my values in entry section, then I would like to call =
a function (I just want to call it, NO TRIGGER), and inside that function, =
I want to trigger an event based on some logic, and that event would trigge=
t state transition from StateA to StateB or StateC.

Is there something wrong with this expectation? Is it possible in VisualSTA=
TE?

Help is greatly appreciated.

Re: IAR VisualState State machine code generation
Hi Rob,

[Please figure out how to configure your google groups interface
so it truncates lines at some nice number of characters.  I've taken
the liberty to discard everything that doesn't fit on my screen  :> ]

On 6/3/2011 3:54 PM, Rob wrote:
Quoted text here. Click to load it

Typically, states are "static" -- you "sit" in a state waiting for
something in the world to change (which, potentially, moves you to
*another* state).  "Triggers" (input conditions that the state
considers significant) are acted upon by the FSM and, IN TRANSITION,
effect some "action routine".  I.e., you do something WHILE MOVING
TO the "next state" (even if that state is the "same state")

Quoted text here. Click to load it

I like embodying all "control flow" in the state machine itself.
I.e., if there are two different courses of action, they should
be reflected by a "branch" at one or more "decision states" that
causes the FSM to "go this way" instead of "go that way".

The way I design state machines, the "triggers" can come from a
variety of places (e.g., something that monitors power status,
another thing that monitors for keystrokes, another thing that
monitors the position of a mechanism, etc.).  Since *everything*
that the FSM encounters is sourced *somewhere* by a piece of
code (i.e., a daemon that watches the status of the AC line and
battery, a driver that scans & debounces key closures, etc.).
So, it's no different to have a "transition routine" issue a
"trigger".

In this case, whatever gets you *into* state X generates a
trigger event that causes state X to transition to state Q.
The transition routine ("action") associated with that "to
state Q" trigger can make a decision and signal trigger A or
trigger B -- which state subsequently Q dispatches to states
R or S, respectively.

[I tend to have only the 'n' different decision outcomes acted
upon in a "decision state" to emphasize the role that the state
is performing.  So, for example, while the FSM is in state Q,
it won't notice that the power has failed, the building is on
fire or your bank account is overdrawn.  This is safe -- because
state Q is a transient state... it is departed as soon as it
is entered (because the routine that got us into Q had the
side effect of raising the trigger(s) that would move us on to
R or S.  Once in R (or S), the FSM can resume watching for power
failures, overdrawn bank accounts, etc.]

Quoted text here. Click to load it

Sorry, I don't use VisualSTATE so I can't attest to its perversions.

Quoted text here. Click to load it

<shrug>  HTH,
--don

Re: IAR VisualState State machine code generation
Don, Thanks for taking time to explain.

Re: IAR VisualState State machine code generation
Quoted text here. Click to load it

Why dont you ask IAR?

Leo Havm°ller.


Re: IAR VisualState State machine code generation
Quoted text here. Click to load it

That was my thought.... they are usually very helpful

Why do people insist on asking questions here about tools that would be
better (and more accurately) answered by the tool vendor (or in many
cases their distributors)


--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
We've slightly trimmed the long signature. Click to see the full one.
Re: IAR VisualState State machine code generation
Quoted text here. Click to load it

Not all vendors and distributors are equally helpful, or are equally
helpful in all countries.  Some are reluctant to give good support if
you are just using a demo or evaluation version (I know that makes poor
sense, but it happens nonetheless).  Sometimes vendors charge for
support cases.  People also sometimes want more independent or objective
replies (few vendors are keen to tell you when a competing product would
be a better choice).  Sometimes it makes more sense to get help from
other users rather than the vendors.  Sometimes people prefer a public
forum because they like to spread the knowledge and information around
for the benefit of others, rather than just themselves.  And sometimes
people prefer to ask in a sharing environment rather than burden the
vendor with the time and effort of replying (though that's more the case
for users of free or low-price software, rather than "big name" vendors).

In other words, there are /lots/ of reasons why people might ask here
about a tool rather than asking the vendor support line.

Still, if you think IAR support is the best way for the OP to get help,
then it is good that there are people here that say that.

Re: IAR VisualState State machine code generation
Quoted text here. Click to load it

Well that is a long list of excuses.  And that is all it is.



--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
We've slightly trimmed the long signature. Click to see the full one.
Re: IAR VisualState State machine code generation
Quoted text here. Click to load it

You asked for reasons - I gave you reasons.  If you have already decided
on your viewpoint and are uninterested in an answer to your question,
then I suppose you just see excuses - it's easier than reading or
thinking about other people's experiences or viewpoints.



Re: IAR VisualState State machine code generation
Hi David,

Quoted text here. Click to load it


I think sometimes people have different *expectations* about how
something (should) work and are, essentially, asking for clarification.
Even if you are reasonably sure of your position, it is often
better to have confirmation of that before approaching "whomever"
with the *claim* that something (they did) is "wrong".

I.e., my response to the OP (up-thread) reflects *my* understanding
of how FSM's "should" operate.  But, that's based on coming from a
hardware background and mapping those concepts onto a software
implementation (given that "code" is a transitory entity, the
typical "state" manifestation -- Mealy *or* Moore -- can't really
be reflected in "code execution" but, rather, "variable values".
Variables have *some* persistence; code, none).

Similarly, my complaint re: apparent HTTP "corruption" was,
essentially, a comment like:  "Isn't *this* true?  If that's
the case, how can *that* possibly happen?"

I recall being puzzled by a seemingly *huge* inconsistency in
Stroustrup's _The Design and Evolution of C++_ and posed a
comment to that effect in a public forum:

"<insert quoted text, here>  This seems entirely wrong!  What
am I missing?"

(to which, some Smart-Ass replied, "A Good (Reference) Book".
I guess he meant something *other* than one of Stroustrup's
writing?)

After forwarding my comment to Stroustrup directly, his reply
came back:  "Ooops!  You're entirely correct!  That's exactly
BACKWARDS!  I'll have to fix that in the next edition..."

(which the Smart-Ass -- had he been 7% as "smart" as he wanted
to consider himself -- *should* have been able to spot in a
heartbeat!)

There's nothing wrong with asking "obvious" questions -- as long
as it's equally obvious that you're not just looking for a way
for someone else to do your thinking/work for you.  Discourse
often leads to insights that might remain hidden, otherwise.

And, *language* is often very imperfect at conveying meaning.
I've had more than one argument with lawyers regarding the
*exact* intent of some of the gobbledygook that they try to
pass off in contracts/licenses.

The beauty of USENET is that one can IGNORE anything that might
displease your sensibilities.  Chances are, the querant(s) won't
"miss" the inattention...

Site Timeline