another bizarre architecture
in [Embedded]
|
From: joseph2k on 11 Feb 2007 11:25 Vladimir Vassilevsky wrote: > > > John Larkin wrote: > >> I don't like interrupts. The state of a system can become >> unpredictable if important events can happen at any time. A >> periodically run, uninterruptable state machine has no synchronization >> problems. Interrupts to, say, put serial input into a buffer, and >> *one* periodic interrupt that runs all your little state blocks, are >> usually safe. Something like interrupting when a switch closes can get >> nasty. > > As everything else, this approach has its limits. > > 1. Once the number of states in the state machine gets over a hundred, > the code is very difficult to manage. The dependencies are growing all > the way. Changing anything can be a pain in the butt. It is almost > impossible to verify all kinds of transitions between the states. For > that reason it is very easy to overlook something. > > 2. There are kinds of tasks which call for multithreading. Caching, > hashing, calculations, vector graphics and such. Those tasks can be > organized as the state machines however it is going to be messy. > > Vladimir Vassilevsky > > DSP and Mixed Signal Design Consultant > > http://www.abvolt.com Before the time i have a 100 states in a state machine is look to "refactor" it into multiple interacting state machines of less than 12 states each. -- JosephKK Gegen dummheit kampfen die Gotter Selbst, vergebens. --Schiller |