rickman <gnuarm.deletethisbit@gmail.com> writes:> Why is this structure hard to understand?It's just that the decomposition into state transitions obscures what the program is supposed to do at a higher level. As an extreme example, consider compiling a regular expression into a DFSM and look how opaque the DFSM is by comparison to the original regex.
When exactly do you choose to use a RTOS (instead of a non-OS approach)?
Started by ●December 9, 2017
Reply by ●January 4, 20182018-01-04
Reply by ●January 4, 20182018-01-04
rickman wrote:> rickman wrote on 1/4/2018 3:33 AM: >> Les Cargill wrote on 1/3/2018 6:59 PM: >>> rickman wrote: >>>> Les Cargill wrote on 1/3/2018 7:07 AM: >>>>> rickman wrote: >>>>>> Ed Prochak wrote on 12/19/2017 11:19 AM: >>>>>>> On Saturday, December 16, 2017 at 12:56:31 PM UTC-5, Les Cargill >>>>>>> wrote: >>>>>>>> Mike Perkins wrote: >>>>>>>>> On 09/12/2017 16:05, pozz wrote: >>>>>>>>>> >>>>>>>>> >>>>>>>>> I use it where I have a number of 'tasks' which then interact >>>>>>>>> with each >>>>>>>>> other. >>>>>>>>> >>>>>>>>> If your system is a pure state machine then there is no need >>>>>>>>> for an >>>>>>>>> RTOS. >>>>>>>>> >>>>>>>> >>>>>>>> Indeed. Indeed. >>>>>>> >>>>>>> If it is just one state machine. Then yes, indeed. >>>>>>> ed >>>>>> >>>>>> It can always be one state machine. The only issue is how complex >>>>>> the >>>>>> combined state machine is. >>>>>> >>>>> >>>>> It's always a case of "how long should a man's legs be?" Lincoln >>>>> is alleged to have said "long enough to touch the ground." >>>>> >>>>>> Actually the issue is not how many state machines you have. It is >>>>>> the >>>>>> timing requirements of the various state machines. If your timing >>>>>> is lax, >>>>>> sequential operation of multiple machines is easy. But this often >>>>>> becomes >>>>>> a huge discussion with everyone talking past each other. >>>>>> >>>>> >>>>> They should use state machines to keep track then :) >>>>> >>>>> If your system can be decomposed as roughly events cross >>>>> state, you have a snowball's chance of "understanding" it. >>>> >>>> Sorry, I don't know what this means "roughly events cross state". >>>> >>>> >>> >>> You are in state A. Event 42 occurs. Lookup.... ah, here - >>> if we get event 42 whilst in state A, we move to state B >>> and send message m. >> >> So what makes that so hard to understand? > > To be more explicit, I think every FSM I've ever coded was along the > lines of a case statement on the state with IF conditions on all the > interesting inputs. I find this structure to be self documenting if the > signal names are chosen well. > > Why is this structure hard to understand? >I agree with you - but I have been told by others that it is hard to understand. -- Les Cargill
Reply by ●January 4, 20182018-01-04
Rob Gaddi wrote:> On 01/04/2018 11:31 AM, rickman wrote: >> rickman wrote on 1/4/2018 3:33 AM: >>> Les Cargill wrote on 1/3/2018 6:59 PM: >>>> rickman wrote: >>>>> Les Cargill wrote on 1/3/2018 7:07 AM: >>>> >>>> You are in state A. Event 42 occurs. Lookup.... ah, here - >>>> if we get event 42 whilst in state A, we move to state B >>>> and send message m. >>> >>> So what makes that so hard to understand? >> >> To be more explicit, I think every FSM I've ever coded was along the >> lines of a case statement on the state with IF conditions on all the >> interesting inputs. I find this structure to be self documenting if >> the signal names are chosen well. >> >> Why is this structure hard to understand? >> > > I think I've used the function pointer variation a couple times, where a > the current state is a pointer to a function that returns the new state > (function pointer), but that's the same thing with different variable > scope. > > State means "follow this execution path". Execution path examines > inputs, updates outputs, and possibly updates state. That's sort of the > hallmark of what it means to be a state machine. > > Les, are you talking about doing where input creates Event, Event causes > dispatch function, dispatch function does something that's a function of > current state (possibly including updating state)? Basically > event-driven programming? >Basically, yes - although event creation may or may not be very separate from the FSM. I've also used tools like ObjecTime and Rational Rose for this - probably a decade or more ago. -- Les Cargill
Reply by ●January 4, 20182018-01-04
Paul Rubin wrote:> rickman <gnuarm.deletethisbit@gmail.com> writes: >> Why is this structure hard to understand? > > It's just that the decomposition into state transitions obscures what > the program is supposed to do at a higher level. As an extreme example, > consider compiling a regular expression into a DFSM and look how opaque > the DFSM is by comparison to the original regex. >Oh, I get that but IMO, it's generally easier ( albeit time consuming ) than trying to enumerate all the side effects rampant in other methods. -- Les Cargill
Reply by ●January 5, 20182018-01-05
On 04/01/18 19:31, rickman wrote:> rickman wrote on 1/4/2018 3:33 AM: >> Les Cargill wrote on 1/3/2018 6:59 PM: >>> rickman wrote: >>>> Les Cargill wrote on 1/3/2018 7:07 AM: >>>>> rickman wrote: >>>>>> Ed Prochak wrote on 12/19/2017 11:19 AM: >>>>>>> On Saturday, December 16, 2017 at 12:56:31 PM UTC-5, Les Cargill wrote: >>>>>>>> Mike Perkins wrote: >>>>>>>>> On 09/12/2017 16:05, pozz wrote: >>>>>>>>>> >>>>>>>>> >>>>>>>>> I use it where I have a number of 'tasks' which then interact with each >>>>>>>>> other. >>>>>>>>> >>>>>>>>> If your system is a pure state machine then there is no need for an >>>>>>>>> RTOS. >>>>>>>>> >>>>>>>> >>>>>>>> Indeed. Indeed. >>>>>>> >>>>>>> If it is just one state machine. Then yes, indeed. >>>>>>> ed >>>>>> >>>>>> It can always be one state machine. The only issue is how complex the >>>>>> combined state machine is. >>>>>> >>>>> >>>>> It's always a case of "how long should a man's legs be?" Lincoln >>>>> is alleged to have said "long enough to touch the ground." >>>>> >>>>>> Actually the issue is not how many state machines you have. It is the >>>>>> timing requirements of the various state machines. If your timing is lax, >>>>>> sequential operation of multiple machines is easy. But this often becomes >>>>>> a huge discussion with everyone talking past each other. >>>>>> >>>>> >>>>> They should use state machines to keep track then :) >>>>> >>>>> If your system can be decomposed as roughly events cross >>>>> state, you have a snowball's chance of "understanding" it. >>>> >>>> Sorry, I don't know what this means "roughly events cross state". >>>> >>>> >>> >>> You are in state A. Event 42 occurs. Lookup.... ah, here - >>> if we get event 42 whilst in state A, we move to state B >>> and send message m. >> >> So what makes that so hard to understand? > > To be more explicit, I think every FSM I've ever coded was along the lines of a > case statement on the state with IF conditions on all the interesting inputs. I > find this structure to be self documenting if the signal names are chosen well. > > Why is this structure hard to understand?I've seen a commercial case where that type of structure was mutated by people under pressure to: - have a single state machine for all different customers - make the minimum change - do it fast - where the original designers had left - a custom domain specific language, ugh The result was an unholy unmaintainable mess, with if-then-elses nested up to 10 (ten!) deep. Completely insane, of course. My preference is for a dispatch table based on event+state, since that forces you to consider all possibilities. The dispatch table can be either a 2D array of function pointers, or inherent in an OOP inheritance hierarchy where the hierarchy is a direct mirror of the state hierarchy.
Reply by ●January 5, 20182018-01-05
The question implies that a conventional RTOS and "superloop" (non-OS approach) are the only games in town. But the traditional shared-state concurrency and blocking based on RTOS is no longer the best known way of organizing embedded software. Neither are the various ad hoc tweaks to the venerable "superloop". To find out about the alternatives, I would recommend to google for the phrase "beyond the RTOS". Miro Samek state-machine.com
Reply by ●January 5, 20182018-01-05
StateMachineCOM <statemachineguru@gmail.com> writes:> Neither are the various ad hoc tweaks to the venerable "superloop". To > find out about the alternatives, I would recommend to google for the > phrase "beyond the RTOS".I looked at https://www.embeddedrelated.com/showarticle/951.php and the linked slideshare presentation. I'm not that much of an OOP guy so I may have missed some of the jargon. But it looks like you're advocating a traditional message-passing approach to concurrency, with some scheme for wrapping a separate event loop for each task. You might like the Erlang OTP system which does something like that, with preemptive scheduling and no shared data between tasks. It may be inadequate for low latency hard-real-time systems but works very well when there's a little bit more timing slack available (millisecond-level soft RT).
Reply by ●January 5, 20182018-01-05
The approach I advocate is a very lightweight version of the Active Object (a.k.a Actor) design pattern (again, anybody interested should google for the "Active Object" or "Actor pattern"). It also turns out that the Actor pattern is a natural fit for state machines, or better yet, hierarchical state machines. So yes, this approach is conceptually related to Erlang insofar Erlang implements the actor pattern. But of course the Erlang language and the accompanying runtime are not applicable to deeply embedded systems such as ARM Cortex-M0 with 2KB of RAM. However, this does not mean that the *concept* of active objects is necessarily heavyweight. To the contrary, event-driven systems are known to be lighter weight than traditional RTOS-based systems, because they don't require that much stack space (RAM). They are also naturally low-power. Anyway, I think that most embedded developers are unaware of the event-driven active object pattern and its applicability in deeply embedded applications with hard real-time requirements.
Reply by ●January 5, 20182018-01-05
On 05/01/18 19:51, Paul Rubin wrote:> StateMachineCOM <statemachineguru@gmail.com> writes: >> Neither are the various ad hoc tweaks to the venerable "superloop". To >> find out about the alternatives, I would recommend to google for the >> phrase "beyond the RTOS". > > I looked at https://www.embeddedrelated.com/showarticle/951.php and the > linked slideshare presentation. I'm not that much of an OOP guy so I > may have missed some of the jargon. But it looks like you're advocating > a traditional message-passing approach to concurrency, with some scheme > for wrapping a separate event loop for each task. You might like the > Erlang OTP system which does something like that, with preemptive > scheduling and no shared data between tasks. It may be inadequate for > low latency hard-real-time systems but works very well when there's a > little bit more timing slack available (millisecond-level soft RT).Or, with careful thought and decades of experience, you can implement the RTOS in hardware. See the multicore XMOS xCORE processors with xC (a modern CSP/Occam), for embedded hard realtime programs. "Hard" means the IDE/toolchain calculates the min/max instruction times. Processors with up to 32 cores and 4000MIPS, and interrupt latencies of 10ns. There is tightly integrated hardware plus software support for i/o event processing and inter-core comms. With that you don't need an RTOS :)
Reply by ●January 5, 20182018-01-05
StateMachineCOM <statemachineguru@gmail.com> writes:> However, this does not mean that the *concept* of active objects is > necessarily heavyweight. To the contrary, event-driven systems are > known to be lighter weight than traditional RTOS-based systems,Sure, they've been in Forth multitaskers for almost 50 years, as this article describes: http://www.complang.tuwien.ac.at/anton/euroforth/ef17/genproceedings/papers/haley-slides.pdf There's some oft-repeated wisdom that as the application gets more complicated, cooperative multasking runs into more and more problems (tasks hanging or blocking crash the whole system etc) and preemption becomes important. So it's good to support both.