On 11/12/17 13:19, pozz wrote:> Good point. Multi-threading is a good thing... but it's not simple to move > from a "bare-metal" model to a "multi-threading" approach. You have to face > unseen problems, like sharing resources among different threads.It is if you have a good solid theoretical background with tools that implement the theory. Start by having a single core dedicated to each I/O device, with many cores, and with a programming paradigm that lets all the cores communicate with each other. Previous embodiment was the Transputer and Occam, current embodiment is the XMOS xCORE processors and xC. See DigiKey for pricing and pointers to the 30,000ft architectural overviews. Effectively the RTOS is cast in silicon. No interrupts; each core sleeps until there is something for it to do, e.g. input, output, or messages to other cores. Add no caches and the min/max execution times can defined by the IDE examining the optimised object code. All in all it is a surprisingly pleasant and mature system.
When exactly do you choose to use a RTOS (instead of a non-OS approach)?
Started by ●December 9, 2017
Reply by ●December 16, 20172017-12-16
Reply by ●December 19, 20172017-12-19
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
Reply by ●December 19, 20172017-12-19
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. > edIt can always be one state machine. The only issue is how complex the combined state machine is. 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. -- Rick C Viewed the eclipse at Wintercrest Farms, on the centerline of totality since 1998
Reply by ●January 2, 20182018-01-02
On Tuesday, December 19, 2017 at 11:51:48 AM UTC-5, 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.Yes. You read me exactly right.> > 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.Indeed! 8^) Yes, and I forgot this was comp.arch.embedded, not comp.realtime, my bad. Ed
Reply by ●January 3, 20182018-01-03
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. You get modest model-checking and message flow analysis on your side that way. And if you're lucky, or good, or both it's deterministic. Anything else is self-deception. -- Les Cargill
Reply by ●January 3, 20182018-01-03
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 get modest model-checking and message flow analysis > on your side that way. And if you're lucky, or good, or > both it's deterministic. > > Anything else is self-deception. >-- Rick C Viewed the eclipse at Wintercrest Farms, on the centerline of totality since 1998
Reply by ●January 3, 20182018-01-03
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.>> You get modest model-checking and message flow analysis >> on your side that way. And if you're lucky, or good, or >> both it's deterministic. >> >> Anything else is self-deception. >> > >-- Les Cargill
Reply by ●January 4, 20182018-01-04
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?>>> You get modest model-checking and message flow analysis >>> on your side that way. And if you're lucky, or good, or >>> both it's deterministic. >>> >>> Anything else is self-deception. >>> >> >> >-- Rick C Viewed the eclipse at Wintercrest Farms, on the centerline of totality since 1998
Reply by ●January 4, 20182018-01-04
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? -- Rick C Viewed the eclipse at Wintercrest Farms, on the centerline of totality since 1998
Reply by ●January 4, 20182018-01-04
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? -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.
