Searching \ for 'R: State machine and EEPROM 24LC...' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: massmind.org/techref/mems.htm?key=eeprom
Search entire site for: 'R: State machine and EEPROM 24LC...'.

Truncated match.
PICList Thread
'R: State machine and EEPROM 24LC...'
1997\12\01@184320 by Humberto Bonasso

flavicon
face
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.

1997\12\03@065243 by Andy Kunz

flavicon
face
>    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

This is the model I use regularly.  However, compression of the data is
rather simple, especially in a PIC with the SWAPF instruction.

>2) a two-dim array of EEPROM of n inputs x m states bytes

I have done 16x16 and larger state machines in ROM (in a '57) and larger in
EEPROM for cable TV stuff.  For the 16x16, I used a "current state+n"
method to determine the new state.  That is, the "new state" was an amount
to add to the existing state and then arranged the rows of the state table
such that it was possible to perform all transitions within 3 bits, leaving
me with 5 to provide the control.

>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

Do some worst-case analysis on this before using up RAM.  You might find
that the path through the SM will permit a much smaller queue.

>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)

I suggest you make the queue perfectly circular.  It's much less code this
way.  It also helps if the queue size is a power of 2.

>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).

That's quite simple.  I posted the interrupt entry/exit code I use on my
assembly projects several months ago.

>    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.

That's the reason people like me are able to survive from one project to
the next.

>    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.

Walter Banks sent me some stuff on his Fuzz-C product that might be of
interest to you.

>always a tradeoff between complexity and flexibility, but once climbed the
>mountain running down to the valley is so pleasant.

Until you trip.  <G>

Andy

==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\12\03@153517 by Eric Smith

flavicon
face
Humberto Bonasso <spam_OUThbonassoTakeThisOuTspamFLASHNET.IT> wrote:
> 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)

Andy Kunz <.....montanaKILLspamspam@spam@FAST.NET> wrote:
> I suggest you make the queue perfectly circular.  It's much less code this
> way.  It also helps if the queue size is a power of 2.

There's some example circular buffer code including useful macros to advance
and wrap the pointers in my UART demo/test program:

       http://www.brouhaha.com/~eric/pic/uarttest.html

Cheers,
Eric

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