Searching \ for 'R: Re: 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: Re: State machine and EEPROM 24LC...'.

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

flavicon
face
Andrew Mayo wrote:


>Of course. Simply use the Microchip application notes on driving the
>24LCxx devices and create a PIC which programs them - and have it accept
>commands via RS232 so then you have an ultra-low-cost EEPROM programmer.

   Thanks for your suggestion, I will take it in account in case I'll not
find any cheap I2C programmer already done; I'm in touch with  spam_OUTcfbTakeThisOuTspamfast.net
after a suggestion from Andy Kunz (thanks Andy) regarding such a low cost
device.

>I don't understand why you need so much memory for a state machine.
>Normally you need only a byte or two to store the state number (a state
>machine with over 256 finite states would have so much code I don't see
>how you'd implement it in a 16F84). Plus a byte or two to store
>state-associated flags. You start at state 0 and then as events occur
>you move to state x, state y etc. You certainly don't need an n-input X
>m-state array under normal circumstances.

   Andrew, perhaps I haven't got your thought, but it seems strange to me
how to implement a finite state machine without using a 2 dimensions array.
For instance, the state machine I'm implementing to accomplish Manchester
encoding in order to bit bang all the data to LCD module via an RF link has
to manage at least 4 different inputs and has 12 states, so the total
dimension for the array is 4 x 12 bytes, and this is the simplest machine.
If you have the simplest transition model in which from state 0 you move to
state x, y, etc. not considering different inputs and transitions, you don't
need a state machine, that is a straight procedure flow.

>In two bytes I have implemented state and status for quite a complex
>dual-triac zero-crossing temperature controller which also had a control
>keypad, dual LED displays and a Dallas DS1820 temperature sensor. If
>your project is much more complex, are you sure your code will fit into
>1K?.

   I've already coded the whole engine that will "move" the state machines
I need (yes, they are 3 running at the same time in a sort of multitasking)
and it took me 200 bytes. As I'll put the array of data for the state
machines in an external EEPROM, the remaining space I hope will be suffice
for coding the action routines needed to react at state transitions.

   Best regards

1997\12\01@163916 by Andy Kunz

flavicon
face
>to manage at least 4 different inputs and has 12 states, so the total
>dimension for the array is 4 x 12 bytes, and this is the simplest machine.

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.

>If you have the simplest transition model in which from state 0 you move to
>state x, y, etc. not considering different inputs and transitions, you don't
>need a state machine, that is a straight procedure flow.

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've already coded the whole engine that will "move" the state machines
>I need (yes, they are 3 running at the same time in a sort of multitasking)
>and it took me 200 bytes. As I'll put the array of data for the state
>machines in an external EEPROM, the remaining space I hope will be suffice
>for coding the action routines needed to react at state transitions.

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.

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.

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!"
==================================================================

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