[Tinyos Core WG] Tep 115

[Kevin Klues]

>
> Right -- the issue is that FAIL tells you that you shouldn't have
> called start(), but it doesn't tell you when you can start an
> operation. How would you possibly write code to handle FAIL? You
> don't know whether an event is coming or not.


Agreed. I was thinking about this as well after having sent the email and my
proposal would not be sufficient to handle this case.

This goes back to Joe's comment on Jan 11, 2005 that a getState()
> command would be useful. If start() when on returns SUCCESS, then the
> callee needs to post a task or otherwise generate a startDone(), but
> the caller doesn't have to keep a bit of state.


I know that David Moss has been working on a generic state machine component
that device drivers could use to implement their state machines.  It is
implemented as a generic components that is capable of managing transitions
between a set of device specific states.  Device drivers implemented using
these components would be able to expose their state directly to any
components wishing to have access to them through a standard set of
interfaces.  This would also be useful for implementing some of the
management features that Neil Hancock keeps bringing up in his emails.

A third option might be to return a value besides SUCCESS and FAIL in
> response to a start() when on... this would make the upper state
> machine a lot simpler. E.g.:
>
> SUCCESS: you will receive an event
> EBUSY : you will receive an event for the other operation
> FAIL: you will not receive an event
> EALREADY: system is already in that state


Given that we currently don't have any devices that expose their state
directly through a standard set of interfaces I am inclined to lean towards
this approach.  It seems nice and clean, and allows clients to directly
infer the internal state of the device without actually querying it.  Plus,
their is no need to singal a startDone() event on redundant calls to
start().  This was my biggest problem with the original proposal in the
first place.

+----------------------+-----------+------------+----------+----------+
> | Call                 | Device On | Device Off | Starting | Stopping |
> +======================+===========+============+==========+==========+
> | SplitControl.start() |  EALREADY |  SUCCESS   | SUCCESS  |  EBUSY   |
> |                      |           |  FAIL      |          |          |
> +----------------------+-----------+------------+----------+----------+
> | SplitControl.stop()  |  SUCCESS  |  EALREADY  | EBUSY    | SUCCESS  |
> |                      |  FAIL     |            |          |          |
> +----------------------+-----------+------------+----------+----------+
> | operation            |  depends  |  FAIL      | FAIL     | FAIL     |
> |                      |           |  EOFF      | EOFF     | EOFF     |
> |                      |           |  EOFF      | SUCCESS  |          |
> +----------------------+-----------+------------+----------+----------+
>
> Phil
>

-- 
~Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/attachments/20070212/4be0294d/attachment.htm