Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #25771 > unrolled thread

Do you use FSMs or HSMs?

Back to article view | Back to comp.arch.embedded

Contents

  Do you use FSMs or HSMs? pozz <pozzugno@gmail.com> - 2017-02-06 10:43 +0100
    Re: Do you use FSMs or HSMs? Don Y <blockedofcourse@foo.invalid> - 2017-02-06 03:20 -0700
    Re: Do you use FSMs or HSMs? Dave Nadler <drn@nadler.com> - 2017-02-06 06:38 -0800
    Re: Do you use FSMs or HSMs? "QL" <80499@EmbeddedRelated> - 2017-02-06 08:56 -0600
      Re: Do you use FSMs or HSMs? Don Y <blockedofcourse@foo.invalid> - 2017-02-06 12:13 -0700
      Re: Do you use FSMs or HSMs? jim.brakefield@ieee.org - 2017-02-06 16:52 -0800
        Re: Do you use FSMs or HSMs? Don Y <blockedofcourse@foo.invalid> - 2017-02-06 18:11 -0700
        Re: Do you use FSMs or HSMs? Les Cargill <lcargill99@comcast.com> - 2017-02-06 23:32 -0600
      Re: Do you use FSMs or HSMs? pozz <pozzugno@gmail.com> - 2017-02-07 10:39 +0100
    Re: Do you use FSMs or HSMs? John Speth <johnspeth@yahoo.com> - 2017-02-06 09:17 -0800
      Re: Do you use FSMs or HSMs? Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-02-06 18:03 +0000
        Re: Do you use FSMs or HSMs? Don Y <blockedofcourse@foo.invalid> - 2017-02-06 11:56 -0700
          Re: Do you use FSMs or HSMs? Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-02-06 20:34 +0000
            Re: Do you use FSMs or HSMs? Don Y <blockedofcourse@foo.invalid> - 2017-02-06 14:19 -0700
              Re: Do you use FSMs or HSMs? Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-02-06 22:12 +0000
                Re: Do you use FSMs or HSMs? Don Y <blockedofcourse@foo.invalid> - 2017-02-06 15:29 -0700
                Re: Do you use FSMs or HSMs? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-02-08 12:15 -0500
                  Re: Do you use FSMs or HSMs? Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-02-08 23:52 +0000
                    Re: Do you use FSMs or HSMs? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-02-08 19:59 -0500
                Re: Do you use FSMs or HSMs? Steve Watt <steve.removethis@Watt.COM> - 2017-02-17 00:30 +0000
                  Re: Do you use FSMs or HSMs? Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-02-17 00:44 +0000
              Re: Do you use FSMs or HSMs? Clifford Heath <no.spam@please.net> - 2017-02-07 10:12 +1100
                Re: Do you use FSMs or HSMs? Les Cargill <lcargill99@comcast.com> - 2017-02-06 23:36 -0600
                  Re: Do you use FSMs or HSMs? George Neuner <gneuner2@comcast.net> - 2017-02-07 03:15 -0500
                    Re: Do you use FSMs or HSMs? Les Cargill <lcargill99@comcast.com> - 2017-02-10 17:41 -0600
                  Re: Do you use FSMs or HSMs? Clifford Heath <no.spam@please.net> - 2017-02-07 19:56 +1100
                    Re: Do you use FSMs or HSMs? Paul Rubin <no.email@nospam.invalid> - 2017-02-07 01:30 -0800
                      Re: Do you use FSMs or HSMs? Clifford Heath <no.spam@please.net> - 2017-02-07 20:42 +1100
                        Re: Do you use FSMs or HSMs? Paul Rubin <no.email@nospam.invalid> - 2017-02-07 02:46 -0800
                          Re: Do you use FSMs or HSMs? Clifford Heath <no.spam@please.net> - 2017-02-08 00:27 +1100
    Re: Do you use FSMs or HSMs? Paul Rubin <no.email@nospam.invalid> - 2017-02-06 18:35 -0800
      Re: Do you use FSMs or HSMs? Don Y <blockedofcourse@foo.invalid> - 2017-02-06 21:50 -0700
      Re: Do you use FSMs or HSMs? Les Cargill <lcargill99@comcast.com> - 2017-02-06 23:39 -0600
        Re: Do you use FSMs or HSMs? Paul Rubin <no.email@nospam.invalid> - 2017-02-06 23:20 -0800
          Re: Do you use FSMs or HSMs? Les Cargill <lcargill99@comcast.com> - 2017-02-10 17:47 -0600
            Re: Do you use FSMs or HSMs? Paul Rubin <no.email@nospam.invalid> - 2017-02-10 16:11 -0800
              Re: Do you use FSMs or HSMs? Les Cargill <lcargill99@comcast.com> - 2017-02-11 15:43 -0600
    Re: Do you use FSMs or HSMs? Les Cargill <lcargill99@comcast.com> - 2017-02-06 23:24 -0600

Page 2 of 2 — ← Prev page 1 [2]

#25835

On 17/02/17 00:30, Steve Watt wrote:
> In article <Xw6mA.154283$6N1.4638@fx09.am4>,
> Tom Gardner  <spamjunk@blueyonder.co.uk> wrote:
>> On 06/02/17 21:19, Don Y wrote:
>>> It's just like designing synchronous hardware.
>>
>> Oh, indeed.
>>
>> I like playing a game with people that think
>> there is a difference between hardware and
>> software: get them to try to provide a test to
>> distinguish one from the other. They always fail.
>>
>> It is best played in a pub, with a few pints,
>> after work.
>
> "I want to make these 15 changes.  Can I have the changed model working
> tomorow and deployable next week?"

Sometimes software can become ossified; typical
unit-testing practices (in XP/TDD/agile methods)
actively encourage that.

I've seen a company where the software turnaround
time was 6 *months*, due to software that had grown
like a cancerous tumour, and inept internal structure.


> OK, FPGAs have a fair shot at it, but most other hardware doesn't.

It largely depends on how many are required. One-off
is more likely to be do-able in hardware.


> Mind, the definition of "working" when it comes to software is quite
> notably different than it is for hardware.  Nothing quite like
> a fresh tapeout because the verification team didn't get enough time.

Ditto much hardware.

Summary: insufficient differences to be a useful test.

[toc] | [prev] | [next] | [standalone]

#25786

On 07/02/17 08:19, Don Y wrote:
> On 2/6/2017 1:34 PM, Tom Gardner wrote:
>> On 06/02/17 18:56, Don Y wrote:
>>> On 2/6/2017 11:03 AM, Tom Gardner wrote:
>>>>> I find that sometimes I'll sketch a FSM and then find out
>>>>> it's just too simple or too linear. ON the flip side, I've had
>>>>> project for
>>>>> which
>>>>> I'd have an extremely simple FSM documented and later it's starts
>>>>> to get
>>>>> elaborate and useful as new requirements emerge.
>>>>
>>>> Precisely.
>>>>
>>>> A large part of engineering is being able to
>>>> demonstrate which part of an design implements
>>>> each part of the specification.
>>>>
>>>> A good implementation of an FSM enables you
>>>> to easily see exactly what will happen when
>>>> any event occurs in any state. That can be very
>>>> difficult with if-then-else clauses.
>>>
>>> Exactly.  IME, they are excellent for representing UI actions
>>> along with other formal "protocols".  They allow you to verify
>>> by inspection that all possibilities are addressed and
>>> addressed in the manner intended -- without having to
>>> count nesting levels of conditionals, etc.
>>>    "Will this 'if' cover this condition in ALL states?  Or,
>>>     does it only apply to some subset of the states, based on
>>>     where it is syntactically anchored?"
>>>
>>> I'd *not* use one to implement a floating point package...
>>
>> Yes, but...
>>
>> They are very neat way of implementing parsing an ascii
>> string and turning it into a floating point number.
>
> Different problem -- and one that could be "automated" with a
> simple grammar/lex/yacc.

Lex is a language for describing a regular expression,
which it implements by turning it *into* an FSA.

You don't need yacc to parse FP numbers. Such parsers
are for handling languages that require unbounded state,
not finite state.

I'm also enthusiastic in using FSAs where appropriate,
but a lot of problems I face require unbounded state.
In either case, I tend not to do them long-hand - there
are good domain-specific languages to generate the code.

Clifford Heath.

[toc] | [prev] | [next] | [standalone]

#25794

Clifford Heath wrote:
> On 07/02/17 08:19, Don Y wrote:
>> On 2/6/2017 1:34 PM, Tom Gardner wrote:
>>> On 06/02/17 18:56, Don Y wrote:
>>>> On 2/6/2017 11:03 AM, Tom Gardner wrote:
>>>>>> I find that sometimes I'll sketch a FSM and then find out
>>>>>> it's just too simple or too linear. ON the flip side, I've had
>>>>>> project for
>>>>>> which
>>>>>> I'd have an extremely simple FSM documented and later it's starts
>>>>>> to get
>>>>>> elaborate and useful as new requirements emerge.
>>>>>
>>>>> Precisely.
>>>>>
>>>>> A large part of engineering is being able to
>>>>> demonstrate which part of an design implements
>>>>> each part of the specification.
>>>>>
>>>>> A good implementation of an FSM enables you
>>>>> to easily see exactly what will happen when
>>>>> any event occurs in any state. That can be very
>>>>> difficult with if-then-else clauses.
>>>>
>>>> Exactly.  IME, they are excellent for representing UI actions
>>>> along with other formal "protocols".  They allow you to verify
>>>> by inspection that all possibilities are addressed and
>>>> addressed in the manner intended -- without having to
>>>> count nesting levels of conditionals, etc.
>>>>    "Will this 'if' cover this condition in ALL states?  Or,
>>>>     does it only apply to some subset of the states, based on
>>>>     where it is syntactically anchored?"
>>>>
>>>> I'd *not* use one to implement a floating point package...
>>>
>>> Yes, but...
>>>
>>> They are very neat way of implementing parsing an ascii
>>> string and turning it into a floating point number.
>>
>> Different problem -- and one that could be "automated" with a
>> simple grammar/lex/yacc.
>
> Lex is a language for describing a regular expression,
> which it implements by turning it *into* an FSA.
>
> You don't need yacc to parse FP numbers. Such parsers
> are for handling languages that require unbounded state,
> not finite state.
>

Just to be pedantic :), it's deterministic vs. non deterministic FA.
Deterministic FA are equivalent to regular expressions. NFA
are not, and very often, NFA are what we use for program control flow.

> I'm also enthusiastic in using FSAs where appropriate,
> but a lot of problems I face require unbounded state.

This is where NFA shine - they're less formal than DFA.

> In either case, I tend not to do them long-hand - there
> are good domain-specific languages to generate the code.
>
> Clifford Heath.

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#25797

On Mon, 6 Feb 2017 23:36:01 -0600, Les Cargill
<lcargill99@comcast.com> wrote:

>Clifford Heath wrote:
>
>> Lex is a language for describing a regular expression,
>> which it implements by turning it *into* an FSA.
>>
>> You don't need yacc to parse FP numbers. Such parsers
>> are for handling languages that require unbounded state,
>> not finite state.
>
>Just to be pedantic :), it's deterministic vs. non deterministic FA.
>Deterministic FA are equivalent to regular expressions. NFA
>are not, and very often, NFA are what we use for program control flow.

Every NFA is equivalent to some DFA, and either can be mechanically
translated into the other.  However the DFA version, in general, will
have many more states: in the (theoretical) worst case, equal to the
size of the power set of states in the NFA.

But such explosive growth is very rare.  In practice, the majority of
elements in the power set of NFA states will represent either unwanted
or redundant operations.


>> I'm also enthusiastic in using FSAs where appropriate,
>> but a lot of problems I face require unbounded state.
>
>This is where NFA shine - they're less formal than DFA.

Not "less formal" per se if you are concerned about correctness.
However, in general, NFA are easier to specify and to understand.  

Any particular state of the equivalent DFA may be simultaneously
representing multiple states of the NFA.  Consequently, the
transition/acceptance rules in the DFA may be extremely complex -
perhaps even incomprehensible to mere mortals.


George

[toc] | [prev] | [next] | [standalone]

#25819

George Neuner wrote:
> On Mon, 6 Feb 2017 23:36:01 -0600, Les Cargill
> <lcargill99@comcast.com> wrote:
>
>> Clifford Heath wrote:
>>
>>> Lex is a language for describing a regular expression,
>>> which it implements by turning it *into* an FSA.
>>>
>>> You don't need yacc to parse FP numbers. Such parsers
>>> are for handling languages that require unbounded state,
>>> not finite state.
>>
>> Just to be pedantic :), it's deterministic vs. non deterministic FA.
>> Deterministic FA are equivalent to regular expressions. NFA
>> are not, and very often, NFA are what we use for program control flow.
>
> Every NFA is equivalent to some DFA, and either can be mechanically
> translated into the other.  However the DFA version, in general, will
> have many more states: in the (theoretical) worst case, equal to the
> size of the power set of states in the NFA.
>

I've had perfectly good NFA deployed that I would hate
to have to translate into a regexp :)

As  a practical matter ( and as you note ) , there is a very
significant tactical difference.

> But such explosive growth is very rare.  In practice, the majority of
> elements in the power set of NFA states will represent either unwanted
> or redundant operations.
>
>
>>> I'm also enthusiastic in using FSAs where appropriate,
>>> but a lot of problems I face require unbounded state.
>>
>> This is where NFA shine - they're less formal than DFA.
>
> Not "less formal" per se if you are concerned about correctness.
> However, in general, NFA are easier to specify and to understand.
>

That's the key. As you say - there may be a (small) price in
the ability to demonstrate correctness.

The principal advantage is the ability to generate
nearly exhaustive test suites for them. It at least becomes a matter of 
exploiting combinators.

> Any particular state of the equivalent DFA may be simultaneously
> representing multiple states of the NFA.  Consequently, the
> transition/acceptance rules in the DFA may be extremely complex -
> perhaps even incomprehensible to mere mortals.
>
>
> George
>

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#25798

On 07/02/17 16:36, Les Cargill wrote:
> Clifford Heath wrote:
>> On 07/02/17 08:19, Don Y wrote:
>>> On 2/6/2017 1:34 PM, Tom Gardner wrote:
>>>> On 06/02/17 18:56, Don Y wrote:
>>>>> On 2/6/2017 11:03 AM, Tom Gardner wrote:
>>>>>>> I find that sometimes I'll sketch a FSM and then find out
>>>>>>> it's just too simple or too linear. ON the flip side, I've had
>>>>>>> project for
>>>>>>> which
>>>>>>> I'd have an extremely simple FSM documented and later it's starts
>>>>>>> to get
>>>>>>> elaborate and useful as new requirements emerge.
>>>>>>
>>>>>> Precisely.
>>>>>>
>>>>>> A large part of engineering is being able to
>>>>>> demonstrate which part of an design implements
>>>>>> each part of the specification.
>>>>>>
>>>>>> A good implementation of an FSM enables you
>>>>>> to easily see exactly what will happen when
>>>>>> any event occurs in any state. That can be very
>>>>>> difficult with if-then-else clauses.
>>>>>
>>>>> Exactly.  IME, they are excellent for representing UI actions
>>>>> along with other formal "protocols".  They allow you to verify
>>>>> by inspection that all possibilities are addressed and
>>>>> addressed in the manner intended -- without having to
>>>>> count nesting levels of conditionals, etc.
>>>>>    "Will this 'if' cover this condition in ALL states?  Or,
>>>>>     does it only apply to some subset of the states, based on
>>>>>     where it is syntactically anchored?"
>>>>>
>>>>> I'd *not* use one to implement a floating point package...
>>>>
>>>> Yes, but...
>>>>
>>>> They are very neat way of implementing parsing an ascii
>>>> string and turning it into a floating point number.
>>>
>>> Different problem -- and one that could be "automated" with a
>>> simple grammar/lex/yacc.
>>
>> Lex is a language for describing a regular expression,
>> which it implements by turning it *into* an FSA.
>>
>> You don't need yacc to parse FP numbers. Such parsers
>> are for handling languages that require unbounded state,
>> not finite state.
>>
>
> Just to be pedantic :), it's deterministic vs. non deterministic FA.
> Deterministic FA are equivalent to regular expressions. NFA
> are not, and very often, NFA are what we use for program control flow.

I didn't mention determinism. Why did you?
I said "FSA", meaning Finite State Automaton.

>> I'm also enthusiastic in using FSAs where appropriate,
>> but a lot of problems I face require unbounded state.
>
> This is where NFA shine - they're less formal than DFA.

"FA" means Finite-state Automaton to me. What does it mean to you?

It certainly does not mean "non-finite-state", which is what
you need to process irregular grammars (things Yacc can do that
a regular expression cannot). That's what I mean by "unbounded state".

[toc] | [prev] | [next] | [standalone]

#25799

Clifford Heath <no.spam@please.net> writes:
>> This is where NFA shine - they're less formal than DFA.
> "FA" means Finite-state Automaton to me. What does it mean to you?

DFA = deterministic finite automaton.  For any node and symbol, there's
at most one edge labelled with that symbol coming out of the node.
E.g. if you are in state 15 and the next input symbol is X, go to state
37.

NFA = non-deterministic finite automaton.  Nodes can have more than one
outgoing edge labelled with the same symbol.  I.e. if the next input
character is X, go to states 23 and 94 at the same time.  You can
simulate it by keeping track of which subset of the states you might be
in, or else convert it to a DFA whose nodes represent subsets of the
nodes of the original NFA.

This is all classical compiler stuff.  There's a chapter about it in the
Dragon Book if anyone still reads that.

https://en.wikipedia.org/wiki/Dragon_Book

[toc] | [prev] | [next] | [standalone]

#25801

On 07/02/17 20:30, Paul Rubin wrote:
> Clifford Heath <no.spam@please.net> writes:
>>> This is where NFA shine - they're less formal than DFA.
>> "FA" means Finite-state Automaton to me. What does it mean to you?
>
> DFA = deterministic finite automaton.

You missed the point again. Determinism is not the point.

"Finite" in "finite state" is the point. You cannot parse
non-regular grammars using finite state. That's why we
have yacc as well as lex.

[toc] | [prev] | [next] | [standalone]

#25802

> "Finite" in "finite state" is the point. You cannot parse non-regular
> grammars using finite state. That's why we have yacc as well as lex.

I don't see what you're getting at.  You asked what the two
abbreviations meant and I explained.  Yes you need a stack to do what
yacc does, etc.

[toc] | [prev] | [next] | [standalone]

#25803

On 07/02/17 21:46, Paul Rubin wrote:
>> "Finite" in "finite state" is the point. You cannot parse non-regular
>> grammars using finite state. That's why we have yacc as well as lex.
>
> I don't see what you're getting at.  You asked what the two
> abbreviations meant

No, I didn't, go back and check. I asked Les C:

"FA" means Finite-state Automaton to me. What does it mean to you?

I specifically did not mention D nor N, other than to point out
that Les describing determinism was not relevant to my point
about the limitations of *finite* state machines of any form.
Relevant to me, because as I said "a lot of problems I face
require unbounded state." An NFA doesn't help with that.

> and I explained.

Thank you. It wasn't necessary, but thanks anyway.

Clifford Heath.

[toc] | [prev] | [next] | [standalone]

#25790

pozz <pozzugno@gmail.com> writes:
> My post here is to understand if you really use HSMs to describe the
> beahviour of the system you are coding and how do you implement them
> in C or C++ (or whatever).

I looked up HSM in Wikipedia and see it's UML-speak for nested state
machines.  I don't see exactly how it applies to the calculator example
but I've preferred to use multiple communicating processes with the
appearance blocking operations, rather than explicit state machines.  Of
course you can simulate that with an event dispatcher and coroutines, or
alternatively do it with an RTOS and tasks.  I suppose there is overhead
compared to a FSM or HSM approach, but on the big processors I use, it
hasn't been an issue.

[toc] | [prev] | [next] | [standalone]

#25791

On 2/6/2017 7:35 PM, Paul Rubin wrote:
> pozz <pozzugno@gmail.com> writes:
>> My post here is to understand if you really use HSMs to describe the
>> beahviour of the system you are coding and how do you implement them
>> in C or C++ (or whatever).
>
> I looked up HSM in Wikipedia and see it's UML-speak for nested state
> machines.  I don't see exactly how it applies to the calculator example
> but I've preferred to use multiple communicating processes with the
> appearance blocking operations, rather than explicit state machines.  Of
> course you can simulate that with an event dispatcher and coroutines, or
> alternatively do it with an RTOS and tasks.  I suppose there is overhead
> compared to a FSM or HSM approach, but on the big processors I use, it
> hasn't been an issue.

IME its not the space/time efficiency but, rather, the conciseness of
expression.

Designing/debugging an algorithm ("machine") with a state diagram is
*so* much easier to sort out what is happening -- and what ISN'T,
that should!

There are tools that can take diagramatic representations and
convert them to code.  But, they make assumptions about the
implementation that constrain your solution space.  Using the
design concept without committing to a particular implementation
style is where the biggest wins lie.

[And, there are "mechanical" ways that you can reduce the complexity
of state machines once you've settled on one that works]

However, just approaching the problem in a way that lends itself
to this sort of visualization makes a huge difference vs. trying to
trace paths through code (in potentially different process containers
or on different physical processors).

It also lends itself to having others (Manglement) review the
(planned) behavior without requiring them to understand the
latest implementation language, modeling language, etc.:
     "What if a power fail event is signalled while I'm OVER HERE?
     How is it handled if the user stalls his interaction at this
     point -- which doesn't RECOGNIZE the event until after he has
     done X, Y or Z?"

[toc] | [prev] | [next] | [standalone]

#25795

Paul Rubin wrote:
> pozz <pozzugno@gmail.com> writes:
>> My post here is to understand if you really use HSMs to describe the
>> beahviour of the system you are coding and how do you implement them
>> in C or C++ (or whatever).
>
> I looked up HSM in Wikipedia and see it's UML-speak for nested state
> machines.  I don't see exactly how it applies to the calculator example
> but I've preferred to use multiple communicating processes with the
> appearance blocking operations, rather than explicit state machines.  Of
> course you can simulate that with an event dispatcher and coroutines, or
> alternatively do it with an RTOS and tasks.  I suppose there is overhead
> compared to a FSM or HSM approach, but on the big processors I use, it
> hasn't been an issue.
>


It's always dangerous to generalize, but anything I can easily
make non-blocking I will.

Some FSM oriented systems use an "actor" model where actors can be 
threads or even pseudothreads[1], communicating with sequential
message passing.

[1] looks like a thread, but may not map to an O/S thread.

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#25796

Les Cargill <lcargill99@comcast.com> writes:
> It's always dangerous to generalize, but anything I can easily
> make non-blocking I will.

Ok, you prefer to handle the event dispatch manually, with callbacks or
a switch around the protocol state.  I know some people find that
intuitive but I've never gotten the hang of it.

> Some FSM oriented systems use an "actor" model where actors can be
> threads or even pseudothreads[1], communicating with sequential
> message passing.

Yes, that's what I'm used to doing under the covers.  Each thread waits
for some action while appearing to block, and moves forward when the
action occurs.  Erlang is designed for programming in this style and
some very complex, highly reliable systems (phone switches) have been
programmed in it.

[toc] | [prev] | [next] | [standalone]

#25820

Paul Rubin wrote:
> Les Cargill <lcargill99@comcast.com> writes:
>> It's always dangerous to generalize, but anything I can easily
>> make non-blocking I will.
>
> Ok, you prefer to handle the event dispatch manually, with callbacks or
> a switch around the protocol state.  I know some people find that
> intuitive but I've never gotten the hang of it.
>

There are a small legion of approaches. It depends on the problem
domain.

But yeah - you dispatch event messages to a machine of some sort.

>> Some FSM oriented systems use an "actor" model where actors can be
>> threads or even pseudothreads[1], communicating with sequential
>> message passing.
>
> Yes, that's what I'm used to doing under the covers.  Each thread waits
> for some action while appearing to block, and moves forward when the
> action occurs.  Erlang is designed for programming in this style and
> some very complex, highly reliable systems (phone switches) have been
> programmed in it.
>

Most/many of the protocols for circuit switched phone systems
have explicit FSM drawn in the standards.

It's possible to have "pseudothreads", where the event sink
dispatches based on event type to whoever is waiting on that event.
This does not require a separate, O/S thread each. You maintain the
advantages of run-to-completion and in cases, can be done on
something which is too small for an O/S.

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#25821

Les Cargill <lcargill99@comcast.com> writes:
> It's possible to have "pseudothreads", where the event sink
> dispatches based on event type to whoever is waiting on that event.

Yes, this is what the Erlang runtime does under the hood.  From the user
program's perspective it looks like OS processes, but they are very
lightweight--you can have many 1000s of them on a small computer, or
millions on a big one.

[toc] | [prev] | [next] | [standalone]

#25824

Paul Rubin wrote:
> Les Cargill <lcargill99@comcast.com> writes:
>> It's possible to have "pseudothreads", where the event sink
>> dispatches based on event type to whoever is waiting on that event.
>
> Yes, this is what the Erlang runtime does under the hood.  From the user
> program's perspective it looks like OS processes, but they are very
> lightweight--you can have many 1000s of them on a small computer, or
> millions on a big one.
>

ObjecTime did the same, as did Rational Rose.

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#25792

pozz wrote:
> I often encounter many problems when I have to implement a "behaviour"
> in a microcontrollor. For example, I have some analog/digital inputs and
> some user commands. Based on that, the logic should set some outputs
> (digital or analog).
>
> Most of the time you (the developer) must understand what is the good
> behaviour of the machine, because noone is able to describe it in a good
> way. I usually heard the sentence: when the user presses the ON button,
> you switch on the engine.
> After some short implementation, you understand that the engine should
> be on only if the interlock input is closed.
> And so on...
>
> I think the best method to describe a machine behaviour is a
> state-machine, mainly a hierarchically state-machine (HSM). Do you agree?
>

It all depends. This being said, I do like state machines, mainly 
because they lend well to comprehensive unit/regression test suites
and have some advantage in coverage measurement.

Hierarchical may or may not help that much.

> My post here is to understand if you really use HSMs to describe the
> beahviour of the system you are coding and how do you implement them in
> C or C++ (or whatever).
>

I have implemented them in multiple languages and programing paradigms.

-- 
Les Cargill

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.arch.embedded

csiph-web