Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #27518
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? |
| Date | 2018-01-06 16:35 -0600 |
| Organization | A noiseless patient Spider |
| Message-ID | <p2rip9$fe5$1@dont-email.me> (permalink) |
| References | (8 earlier) <p2kotf$cu9$1@dont-email.me> <p2lve0$tuv$1@dont-email.me> <%jH3C.197195$nS6.171613@fx23.am4> <p2pfkf$7or$1@dont-email.me> <Wn04C.187479$043.114396@fx27.am4> |
Tom Gardner wrote: > On 06/01/18 03:29, Les Cargill wrote: >> Tom Gardner wrote: >>> 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. >>> >> >> Eh, doing it totally, totally wrong. With all due respect - you really >> need a configuration system managed well within the code itself, and >> customer specializations are but different settings. > > I didn't have due respect; I had due disrespect. > > It was all contained in a configuration system, that > bloated wrong-headed pile of ordure IBM Rational > Clearcase. > We've all been there. I worked one place where the software chief published a config spec daily ( or even more often ). This being said, CM people have a natural affinity for ClearCase. > I once, and only once, looked at the version trees. > For a couple of years it was respectable and sane: > a trunk with a few branches. Then it exploded over > the screen and looked like a plant with a serious > enzyme disorder: there were even backwards branching > loops. I have no idea how they achieved that nor why > (other that get it out the door tomorrow). > > >> On one product, the "model number' was nothing more than a name >> that pointed to a hard table of defaults for the configuration, >> and further config changes were possible. If the support >> people requested it, we'd grow a model number when they got too painful. >> >> That being said - OO and configuration go together like chalk and cheese >> :) >> >>> Completely insane, of course. >>> >> >> Well, yeah. You can make anything disgusting >> if you work hard enough :) > > And they did work hard enough; enhancements were > positively sclerotic. > > > >>> My preference is for a dispatch table based on event+state, >>> since that forces you to consider all possibilities. >> >> Yup yup. And you can generate a test vector for it with combinators. >> Then testing essentially becomes compressing the output - tedious, but >> ... rewarding. >> >> If the tested FSM is properly tested, then all remaining >> defects are 1) either tweak/tone of unrealistic expectations or >> 2) hardware bugs. >> >>> 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. >> >> >> There's something to be said for the 2d approach. It's >> more canonical ( and more normal ) for one. > > Agreed, but it can be convenient to express the design > in other terms. For example: > - the top level catches events that have not been dealt > with elsewhere; I prefer this to be a "should not > happen" which is logged > - next level down is divided into a small number of > superstates, maybe "initialising", "working normally", > "gross fault recovery" > - bottom level is the normal states, e.g. "door open", > "door closed", "fire alarm", etc > Events are "delivered" to the bottom level and, if not > handled, percolate up to the next level. Levels naturally > correspond to an OOP class hierarchy. > To an extent, that's true. It seemed to make the systems engineers happier than the software guys. > That's nothing new, see Harel's StateCharts. Having said > that, I'm not overly fond of some aspects of StateCharts. Right. But they're adaptable. -- Les Cargill
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Mike Perkins <spam@spam.com> - 2017-12-10 14:56 +0000
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Les Cargill <lcargill99@comcast.com> - 2017-12-16 11:58 -0600
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Ed Prochak <edprochak@gmail.com> - 2017-12-19 08:19 -0800
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? rickman <gnuarm@gmail.com> - 2017-12-19 11:51 -0500
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Ed Prochak <edprochak@gmail.com> - 2018-01-02 14:58 -0800
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Les Cargill <lcargill99@comcast.com> - 2018-01-03 06:07 -0600
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? rickman <gnuarm.deletethisbit@gmail.com> - 2018-01-03 12:59 -0500
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Les Cargill <lcargill99@comcast.com> - 2018-01-03 17:59 -0600
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? rickman <gnuarm.deletethisbit@gmail.com> - 2018-01-04 03:33 -0500
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? rickman <gnuarm.deletethisbit@gmail.com> - 2018-01-04 14:31 -0500
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2018-01-04 11:56 -0800
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Les Cargill <lcargill99@comcast.com> - 2018-01-04 21:46 -0600
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Paul Rubin <no.email@nospam.invalid> - 2018-01-04 16:46 -0800
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Les Cargill <lcargill99@comcast.com> - 2018-01-04 21:47 -0600
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? rickman <gnuarm.deletethisbit@gmail.com> - 2018-01-06 18:55 -0500
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-01-07 00:54 +0000
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Paul Rubin <no.email@nospam.invalid> - 2018-01-07 13:41 -0800
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-01-07 23:32 +0000
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? rickman <gnuarm.deletethisbit@gmail.com> - 2018-01-10 10:33 -0500
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-01-10 16:29 +0000
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? upsidedown@downunder.com - 2018-01-08 08:11 +0200
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Paul Rubin <no.email@nospam.invalid> - 2018-01-07 23:05 -0800
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? upsidedown@downunder.com - 2018-01-08 10:06 +0200
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? David Brown <david.brown@hesbynett.no> - 2018-01-08 10:27 +0100
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Paul Rubin <no.email@nospam.invalid> - 2018-01-08 09:56 -0800
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-01-08 18:39 +0000
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Paul Rubin <no.email@nospam.invalid> - 2018-01-08 12:20 -0800
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-01-08 22:11 +0000
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? David Brown <david.brown@hesbynett.no> - 2018-01-08 22:26 +0100
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-01-08 22:23 +0000
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Paul Rubin <no.email@nospam.invalid> - 2018-01-08 14:44 -0800
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-01-08 23:06 +0000
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-01-08 10:02 +0000
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Les Cargill <lcargill99@comcast.com> - 2018-01-08 17:34 -0600
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? rickman <gnuarm.deletethisbit@gmail.com> - 2018-01-06 22:29 -0500
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Paul Rubin <no.email@nospam.invalid> - 2018-01-07 00:46 -0800
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Les Cargill <lcargill99@comcast.com> - 2018-01-04 21:44 -0600
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-01-05 09:12 +0000
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2018-01-05 21:40 -0500
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Les Cargill <lcargill99@comcast.com> - 2018-01-05 21:29 -0600
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-01-06 09:10 +0000
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Les Cargill <lcargill99@comcast.com> - 2018-01-06 16:35 -0600
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-01-07 01:04 +0000
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-01-06 09:17 +0000
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Les Cargill <lcargill99@comcast.com> - 2018-01-06 16:37 -0600
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-01-07 01:11 +0000
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Paul Rubin <no.email@nospam.invalid> - 2018-01-06 17:31 -0800
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-01-07 01:52 +0000
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Paul Rubin <no.email@nospam.invalid> - 2018-01-07 00:39 -0800
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-01-07 09:55 +0000
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Paul Rubin <no.email@nospam.invalid> - 2018-01-07 10:43 -0800
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-01-07 19:35 +0000
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? rickman <gnuarm.deletethisbit@gmail.com> - 2018-01-06 19:06 -0500
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Paul Rubin <no.email@nospam.invalid> - 2018-01-06 16:58 -0800
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? rickman <gnuarm.deletethisbit@gmail.com> - 2018-01-06 22:37 -0500
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Paul Rubin <no.email@nospam.invalid> - 2018-01-07 00:58 -0800
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? rickman <gnuarm.deletethisbit@gmail.com> - 2018-01-07 09:32 -0500
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Paul Rubin <no.email@nospam.invalid> - 2018-01-07 10:53 -0800
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? rickman <gnuarm.deletethisbit@gmail.com> - 2018-01-10 11:40 -0500
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-01-07 01:14 +0000
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? rickman <gnuarm.deletethisbit@gmail.com> - 2018-01-06 18:57 -0500
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-01-07 01:17 +0000
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? rickman <gnuarm.deletethisbit@gmail.com> - 2018-01-06 22:40 -0500
Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-01-07 09:59 +0000
csiph-web