[<<][compsci][>>][..]
Mon Mar 6 12:43:32 EST 2017

State machines

The thing is really that often you don't want to write down a state
machine's transition rules explicitly.  Why? Because that is a very
low-level description of the problem that often requires introduction
of intermediate states that you really don't care about in your
problem description.

What you want is to write down some other model, that talks about
actual events -- often event filtering -- and leaves out the details.

Some patterns I've ran into:

- Sequentially perform a number of operations, possibly finitely
  nested in loops, and wait for a set of events.  This is the most
  common one, and corresponds to what otherwise would be an execution
  thread in a typical multitasking OS.

- Perform resets / restarts when "exceptional cases" occur.



The debouncing problem in the previous thread is more easily expressed
as a sequential process:

events:
A - activating edge
R - releasing edge
T - timeout after a

process:
1. Wait for A
2. with timeout_process {
   3. wait for T,R
      R -> reset to 1
      T -> continue
}
4. output A
5. wait for R
6. output R
7. stop


Notes:

- The scope here indicates a resource that needs to be cleared on
  leaving the scope, in this case the timer process/state.

- The second timeout process is an _essential_ part of this.  There is
  something on the outside of the main process that can not be
  represented by something inside it (apart from emulating a
  scheduler).

- This can be implemented by CSP (channel-style) and Erlang-style
  multiprocessing.





[Reply][About]
[<<][compsci][>>][..]