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