Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Les Cargill Newsgroups: comp.arch.embedded Subject: Re: Do you use FSMs or HSMs? Date: Mon, 6 Feb 2017 23:32:00 -0600 Organization: A noiseless patient Spider Lines: 67 Message-ID: References: <2d444841-11b7-470d-915b-4ee0dc8633ca@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Tue, 7 Feb 2017 05:27:40 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="0c3f843cc7080b873602f174ef60d8b0"; logging-data="1003"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+pizw75XAOGQfd2ZaynpaQeaA1bpNNq5Y=" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46 In-Reply-To: <2d444841-11b7-470d-915b-4ee0dc8633ca@googlegroups.com> Cancel-Lock: sha1:ya8MfL3Qxmvu6xnOPTrk6CoiWIs= Xref: csiph.com comp.arch.embedded:25793 jim.brakefield@ieee.org wrote: > On Monday, February 6, 2017 at 8:56:45 AM UTC-6, QL wrote: >> Let me start with the full disclosure: I'm the author of the book >> "Practical UML Statecharts in C/C++, 2nd Edition" and I run a company >> called Quantum Leaps that makes open-source state machine software >> frameworks and a free state machine modeling tool. The company website >> is: >> >> http://www.state-machine.com >> >> >> So, yes, I also strongly believe that hierarchical state machines (a.k.a. >> UML statecharts) combined with event-driven programming are the best way >> to go when it comes to developing real-time embedded software. >> >> From my two decades of experience, however, I see that the biggest >> obstacle in adopting state machines is the required paradigm shift from >> sequential programming based on blocking (like blocking on a semaphore or >> a time delay in a traditional RTOS or a "superloop") and the event-driven >> programming based on run-to-completion event processing without blocking >> (like in a state machine). >> >> Anyway, if you are seriously interested in (hierarchical) state machines >> for embedded real-time systems I would recommend to start with the key >> concepts: >> >> http://www.state-machine.com/doc/concepts.html >> >> >> You might also wish to try the free state machine modeling tool called QM, >> which allows you to draw hierarchical state machine diagrams and >> automatically generate production-quality C or C++ code from them: >> >> http://www.state-machine.com/qm >> >> >> Miro Samek >> www.state-machine.com >> >> --------------------------------------- >> Posted through http://www.EmbeddedRelated.com > > ]> Anyway, if you are seriously interested in (hierarchical) state machines > ]> for embedded real-time systems I would recommend to start with the key > ]> concepts: > > Not entirely enlightened on hierarchical state machines. > Gather that the lower level state "inherits" from the higher level state. A state of the higher level state can be another state machine. > E.g., unless over-ridden, the lower level state defaults to the actions of the higher level state? > Probably, but events may resolve to the higher level state machine. I am biased by the way ObjecTime/Rational did this. > Side issue: in communications many states use a timer to have a time-out action, and the methodology/diagrams accommodate this? > To my knowledge they all do. -- Les Cargill