We used a state machine to create this program. It was implemented using the switch construction where we made sure that every possible event was handled in every possible situation.

This might have looked a little like overkill, in that you can create a perfectly workable morse code decoder without resorting to something as complex as a state machine, We managed to make our reaction timer simply by creating the code as we went along. However, we found that nasty things appeared when we tested it, an that we had to add extra code to make it work properly if the user did something stupid.

In the case of the morse system we don't have that problem, since we have covered every possible user action in every possible state our program can occupy. We have gone even further, in that we tested the state machine with known data before we gave it any real stuff. This meant that if we had any problems with our key decoding part of the program we knew that is where they must be.

We could even have implemented the morse key reader as a state machine which was triggered by events like key down, key up, timer expire and the like, but that part of the program seemed to lend itself better to straight line coding.

Don't think of the state machine as the only way to approach a problem. Think of it as a way in which you can get a handle on the problem itself, and then consider how the program will be structured based on that. At the end of the day your customer is looking for a program which solves the problem, the precise design decisions are up to you. Go with the one which suits you best.

The PICmicro