Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #27461 > unrolled thread
| Started by | Mike Perkins <spam@spam.com> |
|---|---|
| First post | 2017-12-10 14:56 +0000 |
| Last post | 2018-01-07 09:59 +0000 |
| Articles | 20 on this page of 64 — 11 participants |
Back to article view | Back to comp.arch.embedded
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
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
Page 1 of 4 [1] 2 3 4 Next page →
| From | Mike Perkins <spam@spam.com> |
|---|---|
| Date | 2017-12-10 14:56 +0000 |
| Subject | Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? |
| Message-ID | <p0jhvg$bb7$1@news2.open-news-network.org> |
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. -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.uk
[toc] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2017-12-16 11:58 -0600 |
| Message-ID | <p13mob$dfn$2@dont-email.me> |
| In reply to | #27461 |
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. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Ed Prochak <edprochak@gmail.com> |
|---|---|
| Date | 2017-12-19 08:19 -0800 |
| Message-ID | <ad8c675d-61e1-4e64-b511-af822e8ec1b8@googlegroups.com> |
| In reply to | #27467 |
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
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-12-19 11:51 -0500 |
| Message-ID | <p1bg2u$5ke$2@dont-email.me> |
| In reply to | #27471 |
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. 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
[toc] | [prev] | [next] | [standalone]
| From | Ed Prochak <edprochak@gmail.com> |
|---|---|
| Date | 2018-01-02 14:58 -0800 |
| Message-ID | <c2fecb5f-4da8-4f1a-87df-44ce7fa18c8d@googlegroups.com> |
| In reply to | #27472 |
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
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2018-01-03 06:07 -0600 |
| Message-ID | <p2igr5$j9j$1@dont-email.me> |
| In reply to | #27472 |
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
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2018-01-03 12:59 -0500 |
| Message-ID | <p2j5mn$bev$2@dont-email.me> |
| In reply to | #27486 |
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
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2018-01-03 17:59 -0600 |
| Message-ID | <p2jqj6$9jq$1@dont-email.me> |
| In reply to | #27487 |
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
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2018-01-04 03:33 -0500 |
| Message-ID | <p2kotf$cu9$1@dont-email.me> |
| In reply to | #27488 |
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
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2018-01-04 14:31 -0500 |
| Message-ID | <p2lve0$tuv$1@dont-email.me> |
| In reply to | #27489 |
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
[toc] | [prev] | [next] | [standalone]
| From | Rob Gaddi <rgaddi@highlandtechnology.invalid> |
|---|---|
| Date | 2018-01-04 11:56 -0800 |
| Message-ID | <p2m0tm$brs$1@dont-email.me> |
| In reply to | #27490 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2018-01-04 21:46 -0600 |
| Message-ID | <p2ms8b$ro9$2@dont-email.me> |
| In reply to | #27491 |
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
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2018-01-04 16:46 -0800 |
| Message-ID | <87vaghnndl.fsf@nightsong.com> |
| In reply to | #27490 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2018-01-04 21:47 -0600 |
| Message-ID | <p2msag$ro9$3@dont-email.me> |
| In reply to | #27493 |
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
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2018-01-06 18:55 -0500 |
| Message-ID | <p2rnl1$b30$1@dont-email.me> |
| In reply to | #27493 |
Paul Rubin wrote on 1/4/2018 7:46 PM: > 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. I guess we design very different devices. I can't think of a time when I didn't start analysis of my problem with a FSM diagram. -- Rick C Viewed the eclipse at Wintercrest Farms, on the centerline of totality since 1998
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2018-01-07 00:54 +0000 |
| Message-ID | <Dde4C.235794$Jg1.222201@fx33.am4> |
| In reply to | #27493 |
On 05/01/18 00:46, 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. As I'm sure you know, that's merely one example of the use of FSMs, and one where the regexp is the more comprehensible expression of the intent. In such cases, use regexps to express the operation. But for many embedded systems, FSMs are (or IMNSHO ought to be!) a key component in structuring and expressing the design. Canonical examples are ATMs, car cruise control, comms/networking protocols etc.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2018-01-07 13:41 -0800 |
| Message-ID | <87608dmjmk.fsf@nightsong.com> |
| In reply to | #27525 |
Tom Gardner <spamjunk@blueyonder.co.uk> writes: > But for many embedded systems, FSMs are (or IMNSHO ought to be!) a key > component in structuring and expressing the design. Canonical examples > are ATMs, car cruise control, comms/networking protocols etc. I don't see a requirement for FSM's in any of those. ATM's (I assume you mean cash dispensers) just seem like they'd run normal business code. Cruise control sounds like a normal PID-like controller. I've written tons of comms code without FSM's. On the other hand, maybe your comm protocol involves checksums or error correcting codes. Doing those with FSMs would be straightforward in theory but ridiculous in practice.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2018-01-07 23:32 +0000 |
| Message-ID | <c6y4C.433162$4O3.95466@fx15.am4> |
| In reply to | #27549 |
On 07/01/18 21:41, Paul Rubin wrote: > Tom Gardner <spamjunk@blueyonder.co.uk> writes: >> But for many embedded systems, FSMs are (or IMNSHO ought to be!) a key >> component in structuring and expressing the design. Canonical examples >> are ATMs, car cruise control, comms/networking protocols etc. > > I don't see a requirement for FSM's in any of those. ATM's (I assume > you mean cash dispensers) just seem like they'd run normal business > code. You appear to have a very limited definition of what constitutes an FSM. "Business code" often /is/ an FSM, even if it doesn't use some specific implementation techniques. See, for example, http://www.conceptdraw.com/examples/fsm-state-machine-model-of-an-atm-system > Cruise control sounds like a normal PID-like controller. Modes, dear boy, modes. Speed maintenance using a PID occurs in only one mode. You enter/exit that mode when different events occur, e.g. pressing buttons or brake pedals etc. See, for example, https://www.researchgate.net/figure/283902282_Figure-2-Cruise-control-system-finite-state-machine-diagram > I've written tons of comms code without FSM's. It depends on what you mean by "comms code". But any comms _protocols_ will have many states (e.g. connected, disconnected, idle, active, throttled, retransmission etc) and transitions between states will occur when defined things occur. That's an FSM however you code it. > On the other hand, maybe your > comm protocol involves checksums or error correcting codes. Doing those > with FSMs would be straightforward in theory but ridiculous in practice. Strawman argument; nobody has suggested that.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2018-01-10 10:33 -0500 |
| Message-ID | <p35bo2$kjs$1@dont-email.me> |
| In reply to | #27550 |
Tom Gardner wrote on 1/7/2018 6:32 PM: > On 07/01/18 21:41, Paul Rubin wrote: >> Tom Gardner <spamjunk@blueyonder.co.uk> writes: >>> But for many embedded systems, FSMs are (or IMNSHO ought to be!) a key >>> component in structuring and expressing the design. Canonical examples >>> are ATMs, car cruise control, comms/networking protocols etc. >> >> I don't see a requirement for FSM's in any of those. ATM's (I assume >> you mean cash dispensers) just seem like they'd run normal business >> code. > > You appear to have a very limited definition of what constitutes > an FSM. "Business code" often /is/ an FSM, even if it doesn't use > some specific implementation techniques. *EVERYTHING* on a computer is a FSM as a computer is a FSM. What's your point? -- Rick C Viewed the eclipse at Wintercrest Farms, on the centerline of totality since 1998
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2018-01-10 16:29 +0000 |
| Message-ID | <5cr5C.415132$Gr2.60497@fx36.am4> |
| In reply to | #27566 |
On 10/01/18 15:33, rickman wrote: > Tom Gardner wrote on 1/7/2018 6:32 PM: >> On 07/01/18 21:41, Paul Rubin wrote: >>> Tom Gardner <spamjunk@blueyonder.co.uk> writes: >>>> But for many embedded systems, FSMs are (or IMNSHO ought to be!) a key >>>> component in structuring and expressing the design. Canonical examples >>>> are ATMs, car cruise control, comms/networking protocols etc. >>> >>> I don't see a requirement for FSM's in any of those. ATM's (I assume >>> you mean cash dispensers) just seem like they'd run normal business >>> code. >> >> You appear to have a very limited definition of what constitutes >> an FSM. "Business code" often /is/ an FSM, even if it doesn't use >> some specific implementation techniques. > > *EVERYTHING* on a computer is a FSM as a computer is a FSM. What's your point? Read the context in which I made the statement, especially the comments by Mr Rubin.
[toc] | [prev] | [next] | [standalone]
Page 1 of 4 [1] 2 3 4 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web