Wait state timeouts

[mickp]

@Wolfox did a nice description of wait states in the docs folder.

           [for digital pins ---]
            If action is negative, it is a wait state:
                -1 waits for signal to be 1;
                -2 waits for signal to be 0;
                -3 waits for signal to change (edge)

We probably need a way to timeout, too. When I first started thinking about wait states, my original thought was to use a negative action value where the sign indicates that this is a wait operation, and the magnitude is the timeout. This conflicts with@Wolfox's choice above, though, and I like his high/low/edge choice more - it's more useful, and it's bounded, whereas a timeout is arbitrarily long, so could hit representation limits.

So how do we deal with timeouts? Here are some options for consideration. None of them is perfect.

Software

Client software could keep track of the timeout, and send a signal that aborts any running wait states and jumps straight to the next action.

• If something has timed out, the added latency of a software operations is probably not important.
• We'd need some way of telling the software that we're entering a wait state, though, or it would have to infer it from the time it last received data: if it's expecting data back every 50ms, it could just send the trigger-source a kick after 50ms and a timeout period have elapsed.

Dedicated override pin

We could have one digital pin that overrides any pending wait states.

• What sets it?
• How do we tell whatever it is that we're entering a wait state?

Supplementary information in the action table.

We could provide supplementary information in the action table.

• We could use the next line or a simultaneous action in the action table that specifies a timeout. This might make action table generation and manipulation error prone, though.
• We could add another column to the action table, but most of the time we won't need that column.