----- Original Message ----- From: Timothy Box To: Sent: Thursday, February 20, 2003 10:06 AM Subject: Re: [PIC]: Programming logic solving > > The state-machines type of programming really has me very interested. I have > been using that type of approach in my interrupt routines. I was worried > though that I was writing poor code as the flow was in trapped in my head > and could never document that flow easily with just comments at the end of > the line. The fact that it is a well recognised system and that there are > proper ways to generate a "neat table" for the permutations is some thing I > have to follow up. > > This is really what I have been looking for! > A "neat [state transition] table" can actually be viewed as set of high level instructions which have their "microcode" written in native machine code. If done properly the "microcode" consists of very small fragments of code which can be shared by several states or state transitions. This means that several complex pieces of code can often be reduced to a single simple code fragment and several state entries in the state transition table (which share the fragment). The logic density goes up for a given amount of program space at the cost of processing speed, kind of like using interpreted BASIC. However unlike using interpreted BASIC each "token" in a state machine (entry in the state transition table) is highly tailored to the job in hand doing things directly related to the task in native machine code, unlike interpreted BASIC which is executing pseudo machine code (that emulates a more powerful processor) which is in turn executed as native machine code fragments. State transition tables have a further property that BASIC tokenised programs don't have. Each state effectively excludes processing that has been done in a previous state. This is like building your own BASIC interpreter each time you write a program, with specialised tokens that thread their way through your code optimising the way the work is done. Hand coding a state machine using if statements, switch statements or even function tables is like programming a processor in machine code using binary. Yes we can all do it but how large a program would you realistically produce using this method. How long before you fall back to macro assembler or even a C compiler. To really get to grips with state machines and enjoy the real benefits they provide, you need to be able play with them as you would a high level language, tinkering, experimenting. The best way that I have found to do this is via state diagrams and the appropriate tools. You need to be able to draw your state diagram, play with the code produced and go back and edit the diagram until you get what you want. Ok, I guess talk is cheap so I'll have to point you at something a little more concrete. The following set of pages shows what a I mean about small code fragments is a state machine (you need to click on "STF_M_init_transfer" or "STF_S_busy" to actually get the code fragment to come up) http://www.xcprod.com/titan/ZMECH-DOC/generate/state-machine/MODE-B-STATE-DE SC/diag-01.html To actually see what this state machine belongs to (it's actually part of a much bigger set of interacting state machines) look here: http://www.xcprod.com/titan/ZMECH-DOC/generate/state-machine/block-indx.html Regards Sergio Masci -- http://www.piclist.com hint: To leave the PICList mailto:piclist-unsubscribe-request@mitvma.mit.edu