It is germane to point out that randomly accessing EEPROM is quite slow
because you need to clock in the full address (I am assuming you are
intending to use an I2C device such as the 24LC16B. Even using a 400KHz
clock rate, this is still some 30 or so clock cycles, from memory (oops,
no pun intended). That would imply up to 100 microseconds per random
access, which might be an issue. Of course, you can be servicing
interrupts etc. while setting up the access.

> ----------
> From:         Humberto Bonasso[SMTP:hbonasso@FLASHNET.IT]
> Reply To:     pic microcontroller discussion list
> Sent:         Tuesday, December 02, 1997 12:37 PM
> To:   PICLIST@MITVMA.MIT.EDU
> Subject:      R: State machine and  EEPROM 24LC...
>
> Andy Kunz wrote
>
>
> >It isn't 4x12 bytes, it's 4 inputs * 12 states.  You can encode the
> new
> >state in only 4 bits, and the action in 4 more bits (unless you have
> more
> >than 16 transition actions to perform).  That's only 48 bytes, and
> would
> >fit quite well in ROM.
> ......
> >You don't "move to state x,y" you move from state x1 to state x2,
> >performing operation (x1,y) prior to the move.
> >
> >You only need to store the current state in memory.  The stimulus is
> simply
> >used to select which column.
>
>
>     I think we are referring to different models of state machine. If
> I well
> remember about my studies at university (it happens a long time ago -
> at
> least 22 years) there were two possible models named Mealy and Moore.
> One
> model (I don't remember if it's Mealy or Moore) proposes that the
> transition
> from the current state to the new state is determined by an input
> event
> together an action code, the state information is intended to be just
> as a
> "memory" of the machine; the other model, which feels me much more
> confortable,
> says that to move from one state to another one it is needed only the
> input
> event code because the action to be performed is self contained in the
> new
> state reached.
>
>     Well, assuming we are now talking about the second model (I think
> it's
> Moore), I've chosen to code each state in 8 bits (shrinking and
> compacting
> info takes too much logic to handle it), where the real "state"
> information
> is coded in 5 bits (max 32 states that is enough for most simple
> machines)
> and the remaining 3 more bits can be used for special transitions like
> transient states (this means when the state reached is not a "stable"
> state
> and after performing the action related with self-moves to the final
> "stable" state). So with this kind of approach I need:
> 1)  an array of RAM in which I store the current state value for all
> the
> machines running (3 machines = three bytes of RAM)
> 2) a two-dim array of EEPROM of n inputs x m states bytes
> 3) a RAM queue (short indeed, 10 or 20 RAM locations) in wich I store
> the
> input events coming in from interrupts, timers expired and whatever
> eligible
> as input to the machines
> 4) two RAM pointers at "first input to serve" and "last input to
> acquire" (a
> little care must be taken handling wrap-around condition of the queue)
> 5) a good interrupt driver that must perform the task of acquiring and
> coding all the inputs coming in from I/O pins (the edges high-low and
> low-high for rb0,4,5,6,7 must be coded as well) and computing the
> several
> timers intended to be inputs for the machines based on basic PIC timer
> in
> free-running condition (you have to use application prescalers leaving
> the
> PIC prescaler unchanged running continously in wrap-around mode).
>
>     After all these stuff, and once you have well debbugged it of
> course,
> you have a "framework" that can be reusable for many purposes allowing
> you,
> at each new project, to concentrate on the core problem to solve
> instead of
> inventing the wheel each time.
>
> >If you have 3 running at the same time, are they the same machine or
> a
> >different one for each?  In either case, you only need 2 bytes RAM to
> store
> >the current states for the machines, since they can easily be
> compressed
> >into nybbles.
>
>     The three machines are different: one for handling Manchester
> encoding
> through the RF link with bitbanged LCD and keypad, one for measuring
> pressure and water flow values of the pipe and one for handling power
> delivered to the pump via the TRIAC.
>
> >So you are running an interpreter in your code?!?  This is commonly
> done in
> >set-top cable converters in order to extend functionality.  Very good
> idea,
> >_IF_ you are doing something complex.  Otherwise, it's a lot of
> unnecessary
> >difficulty.
>
>     It is an interesting point of view assuming that a finite state
> machine
> could be intended as an interpreter, but no, it isn't an interpreter
> in my
> intention. However, you are certainly right in your last sentence,
> there is
> always a tradeoff between complexity and flexibility, but once climbed
> the
> mountain running down to the valley is so pleasant.
>
>     Happy to read you the next time.
>