"Jon Kirwan" <jonk@infinitefactors.org> wrote in message 
news:glmil4tn7i69tejh9t31ovef69t4njada5@4ax.com...
> On Mon, 29 Dec 2008 23:02:02 -0000, "Steve at fivetrees"
> <steve@NOSPAMTAfivetrees.com> wrote:
>
>>"Jonathan Kirwan" <jkirwan@easystreet.com> wrote in message
>>news:lqv7l41uf17qlk82d7thujcn71bsrtk9m0@4ax.com...
>>> On Thu, 25 Dec 2008 12:38:07 +0100, "Legato"
>>> <legato_summ23@mailinator.com> wrote:
>>>
>>>>However, if you need to make a state-machine to get the
>>>>timing to work then I'd opt for an RTOS.
>>>
>>> One might.  But using the idea that a state-machine is required to get
>>> timing done wouldn't be a reason to force the issue.
>>>
>>> On instruments that have been running around the world and have been,
>>> in some incarnation or another (various products in product lines)
>>> doing that since around 1993, I've used state machines hooked to a
>>> timer interrupt to handle serial eeprom updates, synchronous
>>> communications with a DSP, and keyboard and display updates.  No
>>> "RTOS" involved.  Oh, and it also handled precise time delays in the
>>> main code for determining update rates and proper averaging for the
>>> consumer applications expecting measurements at certain intervals.
>>
>><rest of excellent message reluctantly snipped for brevity>
>>
>>Bravo, I say, bravo <whistle>. Good show, old chap.
>>
>>Seriously - apart from my comment about state machines as a better
>>mousetrap - you nailed it, dude. Absolutely my point of view too. Thanks 
>>for
>>saving me all that typing :).
>
> Thanks, Steve.  But of course, over time here I've learned that you
> and I think far too much alike!!  I'm still wondering if we disagree
> on anything.  I can only imagine what it would be like working on a
> project, together.  (A real joy, I'm sure.)

Consider me suitably flattered ;).

> Yes, I happen to appreciate state machines, too.  I wrote here, "I can
> provide specific cases that would argue well that a state machine is
> clearer, maintainable, and far less prone to programming mistakes."
> And that is not just words, but fact.  There are times when I'll head
> towards a state machine well before I will examine any other option
> because of how consistently well they work and the ease in writing
> them to cope with myriad complex logical possibilities with robust,
> bullet-proof perfection.  Some places, they are nearly indispensable.

Once again, well said.

Steve
--
http://www.fivetrees.com 

On Mon, 29 Dec 2008 23:02:02 -0000, "Steve at fivetrees"
<steve@NOSPAMTAfivetrees.com> wrote:

>"Jonathan Kirwan" <jkirwan@easystreet.com> wrote in message 
>news:lqv7l41uf17qlk82d7thujcn71bsrtk9m0@4ax.com...
>> On Thu, 25 Dec 2008 12:38:07 +0100, "Legato"
>> <legato_summ23@mailinator.com> wrote:
>>
>>>However, if you need to make a state-machine to get the
>>>timing to work then I'd opt for an RTOS.
>>
>> One might.  But using the idea that a state-machine is required to get
>> timing done wouldn't be a reason to force the issue.
>>
>> On instruments that have been running around the world and have been,
>> in some incarnation or another (various products in product lines)
>> doing that since around 1993, I've used state machines hooked to a
>> timer interrupt to handle serial eeprom updates, synchronous
>> communications with a DSP, and keyboard and display updates.  No
>> "RTOS" involved.  Oh, and it also handled precise time delays in the
>> main code for determining update rates and proper averaging for the
>> consumer applications expecting measurements at certain intervals.
>
><rest of excellent message reluctantly snipped for brevity>
>
>Bravo, I say, bravo <whistle>. Good show, old chap.
>
>Seriously - apart from my comment about state machines as a better 
>mousetrap - you nailed it, dude. Absolutely my point of view too. Thanks for 
>saving me all that typing :).

Thanks, Steve.  But of course, over time here I've learned that you
and I think far too much alike!!  I'm still wondering if we disagree
on anything.  I can only imagine what it would be like working on a
project, together.  (A real joy, I'm sure.)

Yes, I happen to appreciate state machines, too.  I wrote here, "I can
provide specific cases that would argue well that a state machine is
clearer, maintainable, and far less prone to programming mistakes."
And that is not just words, but fact.  There are times when I'll head
towards a state machine well before I will examine any other option
because of how consistently well they work and the ease in writing
them to cope with myriad complex logical possibilities with robust,
bullet-proof perfection.  Some places, they are nearly indispensable.

Jon

"Vladimir Vassilevsky" <antispam_bogus@hotmail.com> wrote in message 
news:NZc6l.9907$as4.8559@nlpi069.nbdc.sbc.com...
> Steve at fivetrees wrote:
>> Me, I love state machines. I'd much rather have a hierarchy of state 
>> machines than an RTOS.
>
> I'd rather bear with the preemptive multitasking overhead then do a 
> cascade of the state machines.

Ok, noted. (Although "cascade" for me seems scarily chaotic compared to 
"hierarchy" ;).)

>> Hell, for even a non-timing-critical sequential system within an alien 
>> non-RT OS, I'd still use a state machine. The reason is perhaps less to 
>> do with latency than elegance: I find a task described entirely 
>> sequentially (with sleep()s etc) tends to have a lot of duplication of 
>> error handling - a thread from earlier this year here, where a couple of 
>> the people whose opinions I would otherwise respect took time to defend 
>> the dreaded goto on this basis, illustrated my point rather well ;). (And 
>> no, try/catch doesn't cut it either. Slightly better than the goto, but 
>> still a nappy layer.)
>>
>> YMMV, and I'd be interested to hear it.
>
> In a state machine, the responsiveness is determined by the state with the 
> longest execution time. Suppose you have a math task which takes a long 
> time to calculate (~1 second). Okay, this task can be broken in a sequence 
> of the small states and the tons of the state variables, which is going to 
> be messy and difficult to maintain.  Nevertheless you can't split a 
> library function such as sin() or log() into a sequence of states. Neither 
> you can split a function like fread(), so if there is a file system 
> related delay, then everything is stalled.

All good points, well made.

I'd counter only with:

 - Yes, I've occasionally had to split a lengthy (time-wise, not 
action-wise) process into substates. Not too often, but yes, at such times 
pre-emption seems attractive ;).

 - You absolutely have a point re e.g. fread() - assuming you're using a 
classic function call provided by an OS, in which case all bets are off. If 
you're writing your own under a cooperative multitasker, you'd probably 
split it into states anyway ;).

Thanks for response - fascinating discussion.

Steve
--
http://www.fivetrees.com 

Steve at fivetrees wrote:


> Me, I love state machines. I'd much rather have a hierarchy of state 
> machines than an RTOS.

I'd rather bear with the preemptive multitasking overhead then do a 
cascade of the state machines.

> Hell, for even a non-timing-critical sequential 
> system within an alien non-RT OS, I'd still use a state machine. The reason 
> is perhaps less to do with latency than elegance: I find a task described 
> entirely sequentially (with sleep()s etc) tends to have a lot of duplication 
> of error handling - a thread from earlier this year here, where a couple of 
> the people whose opinions I would otherwise respect took time to defend the 
> dreaded goto on this basis, illustrated my point rather well ;). (And no, 
> try/catch doesn't cut it either. Slightly better than the goto, but still a 
> nappy layer.)
> 
> YMMV, and I'd be interested to hear it.

In a state machine, the responsiveness is determined by the state with 
the longest execution time. Suppose you have a math task which takes a 
long time to calculate (~1 second). Okay, this task can be broken in a 
sequence of the small states and the tons of the state variables, which 
is going to be messy and difficult to maintain.  Nevertheless you can't 
split a library function such as sin() or log() into a sequence of 
states. Neither you can split a function like fread(), so if there is a 
file system related delay, then everything is stalled.


Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

http://www.abvolt.com

"FreeRTOS.org" <noemail@given.com> wrote in message 
news:gj2df5$5jd$1@news.motzarella.org...
> "Jonathan Kirwan" <jkirwan@easystreet.com> wrote in message 
> news:lqv7l41uf17qlk82d7thujcn71bsrtk9m0@4ax.com...
>> On Thu, 25 Dec 2008 12:38:07 +0100, "Legato"
>> <legato_summ23@mailinator.com> wrote:
>>
>>>However, if you need to make a state-machine to get the
>>>timing to work then I'd opt for an RTOS.
>>
>> One might.  But using the idea that a state-machine is required to get
>> timing done wouldn't be a reason to force the issue.
>>
>> On instruments that have been running around the world and have been,
>> in some incarnation or another (various products in product lines)
>> doing that since around 1993, I've used state machines hooked to a
>> timer interrupt to handle serial eeprom updates, synchronous
>> communications with a DSP, and keyboard and display updates.  No
>> "RTOS" involved.
>
> I always advocate using the right tools for the job - sometimes that is 
> with an RTOS, sometimes without.  I like using some of these 'automated' 
> state machine paradigms, when that suites the job.  However, while I can 
> cut the grass with scissors, it would work, I would always choose to use a 
> lawn mower if the lawn was more than one foot square.
>
> I often give talks where one of the subjects is when an RTOS is useful and 
> when not, and having multiple state machines to control fast and slow 
> device (especially if nested) is one indicatation that an RTOS might be 
> the best solution.  In the same talk I take a piece of LCD code that I 
> downloaded from the net which is implemented as a state machine - then 
> first ask the class to tell me how it works (nobody has got it right yet), 
> followed by asking how it would need changing if the LCD controller 
> changed and worked at twice the speed (nobody has got it right yet). 
> Finally we convert the state machine to a piece of sequential code that 
> uses the services of the RTOS.

Fascinating. That state machine must have really sucked.

I've had the opposite experience, but possibly that's because the state 
machines were designed by me, and I'm quite good/experienced/old ;). My main 
aim in such cases is to make things so clear they can't possibly be either 
wrong or misunderstood. It's actually not all that hard.

However, re code downloaded from the net, I have to agree there - the 
majority of 3rd-party state-machine implementations I've seen really do 
suck. That doesn't mean the basic concept is flawed, though. It just means 
people think sequentially, and have trouble thinking synchronously. Unless 
of course you're a hardware designer, in which case such things come 
naturally ;).

> I have not actually done the counting, but would guess there was a lines 
> of code ratio of about 5 to 1, and the RTOS solution is so simple you 
> could not mistake how it worked because all the timing information is 
> abstracted away. The RTOS solution is also very maintainable - especially 
> if you had to maintain it when somebody else had written it.  Plus the 
> RTOS solution is many more times efficient as it does not repeatedly call 
> a state machine when there is nothing to do or just to click through a 
> timing state

<snip>

There is some truth in this, but not 5:1. Given Moore's Law, I'm happy to 
sacrifice some efficiency for robustness and clarity. But probably not 5:1. 
More like 1.5:1.

I call this argument the sock argument - is the sock inside-in or 
inside-out? You can have time-based or task-based paradigms - some are good, 
some are bad. But thinking entirely sequentially, with no eye to 
cooperation, tends to result in sucky code either way.

Steve
--
http://www.fivetrees.com 

"Jonathan Kirwan" <jkirwan@easystreet.com> wrote in message 
news:lqv7l41uf17qlk82d7thujcn71bsrtk9m0@4ax.com...
> On Thu, 25 Dec 2008 12:38:07 +0100, "Legato"
> <legato_summ23@mailinator.com> wrote:
>
>>However, if you need to make a state-machine to get the
>>timing to work then I'd opt for an RTOS.
>
> One might.  But using the idea that a state-machine is required to get
> timing done wouldn't be a reason to force the issue.
>
> On instruments that have been running around the world and have been,
> in some incarnation or another (various products in product lines)
> doing that since around 1993, I've used state machines hooked to a
> timer interrupt to handle serial eeprom updates, synchronous
> communications with a DSP, and keyboard and display updates.  No
> "RTOS" involved.  Oh, and it also handled precise time delays in the
> main code for determining update rates and proper averaging for the
> consumer applications expecting measurements at certain intervals.

<rest of excellent message reluctantly snipped for brevity>

Bravo, I say, bravo <whistle>. Good show, old chap.

Seriously - apart from my comment about state machines as a better 
mousetrap - you nailed it, dude. Absolutely my point of view too. Thanks for 
saving me all that typing :).

Steve
--
http://www.fivetrees.com 

"Legato" <legato_summ23@mailinator.com> wrote in message 
news:givrbd$53k$1@news.albasani.net...
>
> I guess it depends. If you can do all those things within individual time 
> slots without fear of missing a beat then, yes, it may be easier to do 
> without an RTOS. However, if you need to make a state-machine to get the 
> timing to work then I'd opt for an RTOS.

Oooh, what an interesting statement.

Me, I love state machines. I'd much rather have a hierarchy of state 
machines than an RTOS. Hell, for even a non-timing-critical sequential 
system within an alien non-RT OS, I'd still use a state machine. The reason 
is perhaps less to do with latency than elegance: I find a task described 
entirely sequentially (with sleep()s etc) tends to have a lot of duplication 
of error handling - a thread from earlier this year here, where a couple of 
the people whose opinions I would otherwise respect took time to defend the 
dreaded goto on this basis, illustrated my point rather well ;). (And no, 
try/catch doesn't cut it either. Slightly better than the goto, but still a 
nappy layer.)

YMMV, and I'd be interested to hear it.

Steve
--
http://www.fivetrees.com 

"Mark Borgerson" <mborgerson@comcast.net> wrote in message 
news:MPG.23c20f18a8721fd4989690@news.motzarella.org...
> In article <Z9KdnX5h3_IkGMjUnZ2dnUVZ8rudnZ2d@pipex.net>,
> steve@NOSPAMTAfivetrees.com says...
>>
>> If the 500ms needs to be exact, consider achieving this by hardware 
>> linkage.
>> It's not generally a good idea to do h/w IO in interrupts, but so long as 
>> it
>> has no side-effects (a read-modify-write needs to be atomic), it can be
>> done.
>
> I'm not sure I understand your last sentence.  Are you saying that it is
> not a good idea to use interupts to service hardware such as UARTS, SPI
> devices or other hardware I/O devices?

I was clearly too brief ;).

Somewhat less briefly: there needs to be a clear distinction between the 
hardware resources owned by the top level, and those owned by interrupts. 
Reasonably often a single port has pins that are serviced by interrupts, and 
others that are not. In such cases one has to be sure that an interrupt 
doesn't come along and change the state of the port (or its DDR) while the 
top level is doing something with it, hence my reference to 
read-modify-writes being atomic. Again, reasonably often one needs to 
maintain a copy of the state of the entire port in software - the same 
cautions apply.

As a general rule, unless the hardware support is time-critical (as is the 
case with serial comms or SPI), it's better to set a flag in software under 
interrupt control and allow the top level to maintain the hardware. YMMV.

Steve
--
http://www.fivetrees.com 

In article <Z9KdnX5h3_IkGMjUnZ2dnUVZ8rudnZ2d@pipex.net>, 
steve@NOSPAMTAfivetrees.com says...
> "eeboy" <jason@jasonorsborn.com> wrote in message 
> news:O-udnRbNLLEmEszUnZ2dnUVZ_qPinZ2d@giganews.com...
> > Thank you all for your input. That's exactly what I needed. I've got a lot
> > to look over and take in. Protothreads looks like it may be a good option.
> >
> > I stated my generalized thoughts on a suitable scheme but was having
> > difficulties with the problem where I needed to engage a pin, do something
> > else for 500ms (exactly) then return.
> 
> If the 500ms needs to be exact, consider achieving this by hardware linkage. 
> It's not generally a good idea to do h/w IO in interrupts, but so long as it 
> has no side-effects (a read-modify-write needs to be atomic), it can be 
> done.
> 

I'm not sure I understand your last sentence.  Are you saying that it is
not a good idea to use interupts to service hardware such as UARTS, SPI
devices or other hardware I/O devices?


> Anything done by a main loop, whether cooperative or pre-emptive, is only as 
> exact as the lengthiest route from iteration to iteration.
> 
> Steve


Mark Borgerson

In message <f2gdl4pqt89rv8prndfst0hin9717k1n53@4ax.com>, Jonathan Kirwan 
<jkirwan@easystreet.com> writes
>On Sat, 27 Dec 2008 18:50:22 -0500, CBFalconer <cbfalconer@yahoo.com>
>wrote:
>
>>Chris H wrote:
>>> CBFalconer <cbfalconer@yahoo.com> writes
>>>> Chris H wrote:
>>>>> eeboy <jason@jasonorsborn.com> writes
>>>>>
>>>>>> 2) I would envision using malloc and memcpy to implement the queue.
>>>>>> Are these appropriate (efficient enough) in the embedded world?
>>>>>
>>>>> No....  MISRA-C bans malloc
>>>>
>>>> Which is a silly attitude.
>>>
>>> Not at all
>>>
>>>> Often malloc functions are the only way to provide efficient use
>>>> of limited memory.  <there was more, but the p'graph got snipped>
>>>
>>> Then deviate... in writing giving reason for this specific case in
>>> your project
>>
>>If they deviate from the C standard you are not using C.  That only
>>leaves a very few possibilities, such as failure to recover large
>>enough spaces, and the use of lazy assignment (usually switch
>>offable).  That was why I mentioned assigning uniformly sized
>>blocks.
>
>I think he meant "deviate [from MISRA-C]" in that MISRA-C (and I'm
>guessing here) permits deviations so long as the reasons for the
>deviation are well-documented.  I think he was responding to your
>statement that malloc() may be uniquely appropriate, at times, and
>defending MISRA-C's "ban malloc" by saying that you can have
>exceptions to their ban, if documented.
>
>Of course, I'm just guessing.  He'll need to respond, I suppose.  Just
>offering my interpretation for what it is worth.

Hi Jon,

Your interpretation is correct.


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/