Hmm. If there are 4 inputs and 12 states, then encoding the state number
as 4 bits implies that the entire machine state at any given time is
encoded as 2 bytes (4 nibbles, one for each channel). (i.e each of the
four input channels is independently in state 's'). Of course, what you
are intending to do, I presume, is to look up the state transition table
from eeprom. Again, though, if there are 12 states, then each next state
surely is also a number from 1-12 (or 0-11 if you prefer). This implies
that such a lookup table would be 12 nibbles or six bytes, and isn't the
transition table the same for each input?. Sure, each input channel is
at any time in an independent state from any other input channel, but
the transition table is shared by all input channels as they are all
processed the same.

I may have misunderstood what you need to do but on the surface this
seems to be plausible. Of course, if you need to store data at each
point in the state transition matrix, you need more memory. But normally
this isn't necessary - in your case it sounds like a classic 'if
negative transition, and in state 5, go to state 6' etc.

> ----------
> From:         Humberto Bonasso[SMTP:hbonasso@FLASHNET.IT]
> Reply To:     pic microcontroller discussion list
> Sent:         Tuesday, December 02, 1997 9:22 AM
> To:   PICLIST@MITVMA.MIT.EDU
> Subject:      R:      Re: State machine and  EEPROM 24LC...
>
> 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
> cfb@fast.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
>