Re: [openag5-talk] Modus operandis

["Lars Krueger" <lars_e_krueger@xxxxxx>]

> Assuming the user-defined state machine is implemented in the native
> assembly language, 4 KiB should be sufficient: since the
> micro-controller is 8-bit, each native instruction is 1 byte long.
> Therefore we can have a maximum of 4 Ki instructions.

There is no need to compile the state machine to assembler code. They can be expressed in simple tables. This is usually more memory efficient. Depending on the type of state machine (my first impulse would be a Mealy machine, http://en.wikipedia.org/wiki/Mealy_machine) we need 2 byte per transition. The actual algorithm is always the same, only the tables have to change.

> I recently learned of a language called Forth which allows execution
> of native machine instructions from arbitrary memory locations.  It
> also allows us to build higher-level primitives from a set of native
> machine instructions.

Having written my own Forth-compiler when I was younger and more adventurous, I recommend against the use of Forth. For something as simple as a state machine interpreter this is too much overhead around it.

The state machine interpreter will look like this:

unsigned char state;

void handleKey( unsigned char code)
{
  unsigned char action=actionTable[state][code];
  unsigned char nextState=stateTable[state][code];
  unsigned char actionParameter=parameterTable[state][code];
  
  actionFunctionTable[action]( actionParameter);
  state=nextState;
}

You call this function on every keypress. action and nextState can be put into 1 byte, the parameter into the other one.

The actions reside the program memory and only a fixed set of preprogrammed actions is required: LED on/off, set timer, send USB code, etc. My guess would be 8 actions at most, which leaves us 5 bits for 32 states. Assuming 64 codes (keys + other events such as timers), we need 2*64*32 = 4096 bytes of data flash. 

> So I will be investigating Forth as the language for implementing
> the user-defined state machines.  Of course, at the user level, we

Forth is an interesting language in its own right. You may check the gforth implementation as it aims to be standards compliant and very portable. There should be some forth systems around for HC08 MC's. 

http://pygmy.utoh.org/3ins4th.html looks promising for the development. 
http://www.forth.org/compilers.html has a list of compilers.

> will use something like Ragel[1] to compile a very high-level state
> machine into Forth code or maybe native assembly.  Finally, we can

Or to tables. Ragel supports this as well.

> wrap a simple GUI around Ragel to simplify the user experience.

Good idea.

> In the end, the user need only manipulate a GUI or write Ragel code.
>  There is no assembly/Forth programming.

Good idea. Widens the user base.


-- 
Dr. Lars Krueger
http://LarsKrueger.homestead.com/files


Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

---