Searching \ for 'Two topics - State Machines' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Two topics - State Machines'.

Truncated match.
PICList Thread
'Two topics - State Machines'
1999\10\22@115622 by Lawrence Lile

flavicon
face
Dmitri,

There is a real nice example of a state machine on the CC5X home page.  For
some reason, they file it under 'Multitasking" although state machines have
much wider application.  THis is a real thorough and straightforward
example.  After reading it, the light went on in my head.  ("DUH!" it said,
in neon colors "I've been using state machines without knowing it. Seemed a
natural way to program things. ")

The examples are in C, but are straightforward enough to be applicable to
just about any programming.

http://www.bknd.com/cc5x/multitasking.shtml




{Original Message removed}

1999\10\22@123355 by John Mitchell

flavicon
face
On Fri, 22 Oct 1999, Lawrence Lile wrote:

> Dmitri,
>
> There is a real nice example of a state machine on the CC5X home page.
> [...]
> http://www.bknd.com/cc5x/multitasking.shtml


Also check out this paper: "Finite State Machines in Forth".  The author,
Mr. J. Noble, goes through a few different variations, explaining the
time/ space/ readability tradeoffs for each:

       http://dec.bournemouth.ac.uk/forth/jfar/vol7/paper1/toc.html

- j

1999\10\22@165248 by Mark Willis

flavicon
face
Lawrence Lile wrote:
>
> Dmitri,
>
> There is a real nice example of a state machine on the CC5X home page.  For
> some reason, they file it under 'Multitasking" although state machines have
> much wider application.  THis is a real thorough and straightforward
> example.  After reading it, the light went on in my head.  ("DUH!" it said,
> in neon colors "I've been using state machines without knowing it. Seemed a
> natural way to program things. ")
>
> The examples are in C, but are straightforward enough to be applicable to
> just about any programming.
>
> http://www.bknd.com/cc5x/multitasking.shtml

Sort of an inside joke among some programmers - There really IS no such
a thing as "multitasking" on single-CPU computers, just different ways
to PRETEND we're doing multiple tasks simultaneously, by doing a little
of each task at a time, then switching to the next task - really
quickly. <G>  And repeatedly.

I want to write a good overall view, in my too-perfectionist way, that
shows some nice things about the use of State machines, when to use
them, some hybrid stuff based on them, etc.  It's going to take some
good work to do all that, I think I'll "divide and conquer" it, and
write it in chapters, so to speak <G>

 Mark

1999\10\22@222551 by Russell McMahon

picon face
>Sort of an inside joke among some programmers - There really IS no such
>a thing as "multitasking" on single-CPU computers, just different ways
>to PRETEND we're doing multiple tasks simultaneously, by doing a little
>of each task at a time, then switching to the next task - really
>quickly. <G>  And repeatedly.


At that level of picky-ness (PIC-i-ness?) I'd have to assert that there was
no such thing as a microprocessor based state machine either :-). This is
especially true if the total set of inputs to the "machine" exceeds the data
word size of the processor so that you have to macke numerous decisions to
decode and implement the state actions.

A REAL state machine is a simultaneously switchjing (clocked or ripple
through) piece of hardware. A microprocessor implementation is just another
way at looking at code with a complex set of conditional branches. As
someone noted, you can end up writing something that others would describe
as a stae machine without ever having heard that they exist. A state machine
can be as much a way of thinking or a programming paradigm.

All that said, the state machine concept is a marvellous one for simplifying
complex programming tasks - especially realt-me multitasking ones :-)

While I'm drivelling, I disagree about the lack of ability to do REAL
multitasking on a single cpu machine.
BECAUSE -
if a task operates in :"real time" and produce "outputs" of whatever form in
response to certain stimulii and prior conditions, what does it matter what
the computer is doing in the time it has left over after doing the
componnets of the task?
If there were multiple (say 10) computers doing multiple (say 10) such tasks
simultaneously and each is idle for 95% of the time or one computer is doing
all 10 tasks and being idle for 30% of the time, would the tasks be any less
"simultaneous" or "multiple" in the latter case. As long as the outputs are
indistinguishable in each case the answr is, of course, no. If the 10
computers are truly multitasking then the single computer is also truly
multitasking.
But then, I know, you know that.


RM

1999\10\25@142158 by Andy Kunz

flavicon
face
>A REAL state machine is a simultaneously switchjing (clocked or ripple
>through) piece of hardware. A microprocessor implementation is just another

Ah, you mean a state machine is a microprocessor, then.

So somebody is talking about implementing a state machine in a state
machine, right?

Andy

==================================================================
Eternity is only a heartbeat away - are you ready?  Ask me how!
------------------------------------------------------------------
spam_OUTandyTakeThisOuTspamrc-hydros.com      http://www.rc-hydros.com     - Race Boats
.....andyKILLspamspam@spam@montanadesign.com  http://www.montanadesign.com - Electronics
==================================================================

1999\10\25@151117 by Don Hyde

flavicon
face
       [Don Hyde]  No, it's the other way around.  Microprocessors, like
CPU's in general are state machines, but not all state machines are
microprocessors.  Actually, most PIC's comprise quite a few interlocking
state machines, what with all those on-chip peripherals and such.

       If you're really into state machines, there's a Dutch outfit that
sells a cool tool for programming PIC's via drag-and-drop state diagrams.
       http://www.actum.com
       Too bad they have to make a living selling their software and can't
afford to give it away free...
>
> Ah, you mean a state machine is a microprocessor, then.
>
> So somebody is talking about implementing a state machine in a state
> machine, right?
>

1999\10\25@160740 by William Chops Westfield

face picon face
   >A REAL state machine is a simultaneously switchjing (clocked or ripple
   >through) piece of hardware.

   Ah, you mean a state machine is a microprocessor, then.

Well, a microprocessor is certainly a state machine (of rather large
complexity, of course.)

In hardware, "state machine" is usually used to describe a piece of logic
where the inputs and current state control transitions to a new state, and
the outputs are dependent only on the state (as opposed to logic whose
output is a combinatorial function of the inputs.)  It's typicaly
implemented as a couple of roms.  The first rom maps inputs and old state
into new state, and the second rom maps the new state into outputs.

In software, "state machine" is usually used to describe code where
program flow is controlled primarilly by a single small integer variable
(the "state".)  Other control decisions affect the state value, rather
than directly modifying the program flow.  Software types are likely to
cheat and cause their code to break by doing things only when a state is
entered or exitted.

BillW

1999\10\25@162535 by Dan Larson

flavicon
face
>Software types are likely to
>cheat and cause their code to break by doing things only when a state is
>entered or exitted.

AS as "software type", I usually create three states in such cases: One for the
"entry" state, one for "polling, looping, etc", and one for the "exit" state.

I don't know if *this* is cheating or not, but sometimes the next state to
be transitioned to from the current state depends on the previous state.
Sort of like subroutine calls within a state machine.  I only use such a
technique in order to avoid duplication of state.  Avoiding duplication
also avoids bugs cause by changes made to one of the any identically
functioning state but not the rest.

I once wrote a state machine for a "game show" program which had
over 150 states!  Mind blowingly complex, but it would have been almost
impossible with traditional logic structures (if then else).

State machines rule!

Dan

>
>BillW
>

1999\10\25@173827 by William Chops Westfield

face picon face
   > Software types are likely to cheat and cause their code to break by doing
   > things only when a state is entered or exitted.

   AS as "software type", I usually create three states in such cases: One
   for the "entry" state, one for "polling, looping, etc", and one for the
   "exit" state.

Yep.  That'd be the "pure" state machine...


   I don't know if *this* is cheating or not, but sometimes the next state
   to be transitioned to from the current state depends on the previous
   state.

That's cheating too.  Actually, it sounds like a particular case of
entry cheating (steady state means that the previous state is the
current state, right?  So special state entry code is the same as being
dependent on the previous state...)

BillW

1999\10\25@210545 by hris Fanning

flavicon
face
>     > Software types are likely to cheat and cause their code to break by doin
g
>     > things only when a state is entered or exitted.
>
>     AS as "software type", I usually create three states in such cases: One
>     for the "entry" state, one for "polling, looping, etc", and one for the
>     "exit" state.
>
> Yep.  That'd be the "pure" state machine...
>
>
>     I don't know if *this* is cheating or not, but sometimes the next state
>     to be transitioned to from the current state depends on the previous
>     state.
>
> That's cheating too.  Actually, it sounds like a particular case of
> entry cheating (steady state means that the previous state is the
> current state, right?  So special state entry code is the same as being
> dependent on the previous state...)

It's not cheating at all.  It's merely a "substate" of another state.
If you'd prefer to represent this as a "top level" state it can be
done by breaking this "super state" into "top level" states for each
set of prior and next states.

In hardware this is almost a necessity unless you're using a HDL.  All
software is a state machine, running on a state machine which is
comprised of a whole bunch of other state machines.  It's sort of silly
to try and say that one style of coding is a state machine and another
isn't when every statement affects state regardless.

Even in hardware there's a bunch of different models for constructing
and defining state machines.  They're just styles of state machines, not
the whole class of them.

It just depends on how explicit or implicit the model is.

Chris

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...