Honestly the smc programmers manual http://smc.sourceforge.net/SmcManual.htm http://smc.sourceforge.net/SmcManual.htm is probably good enough. Its quite light;

Honestly the smc programmers manual http://smc.sourceforge.net/SmcManual.htm http://smc.sourceforge.net/SmcManual.htm is probably good enough. Its quite light; even with a blog post one would still have to extrapolate from the author's application to how one would apply the tool to one's own problem domain. But +1 for SMC; used it quite a few times already, in many cases in new product versions replacing legacy code where the original insisted to implement a partially-identified state machine "by hand" (and invariably ended up tripping over all sorts of unforeseen and edge cases). I've also found that merely the exercise of thinking in terms of FSM definition, often helps to simplify the problem (for example by identifying that there may actually be multiple independent/"orthogonal" FSMs present, instead of one monolithic one).