[Tinyos Core WG] non-TEP code

[Gilman Tolle]

In my user button component, I provided the Notify interface with a
type of <bool>, so I get a TRUE when it's pressed and a FALSE when
it's released. I also provided a Get interface to read the current
state of the button. Combining these 2 SID interfaces effectively
covers the functionality of the basic Button interface proposed above,
with the exception of the timestamping. But as you say, you can always
query LocalTime as long as you don't mind a tiny offset from the
'true' press time, and that's what I do too.

Once you start adding configuration options like 'how long should the
button be pressed before it's considered a click', and 'how many
clicks were made in a row', it sounds to me like you're writing a HAL
to a particular sensor-processing scheme. For that situation, I'd just
write the most expressive interface (as Joe has done), and only later
consider writing a simplifying SID layer.

SIDs were meant for generic interconnections between dataflow-driven
components. If you're intending your interface to be used by human
programmers, and you think those programmers would prefer a nice
concrete Button over a hazy cloud of renamed Gets and Notifies, more
power to you, and I don't want to get in your way.

But -- I'm not convinced that we need to be writing a TEP about this.
We could consider the user button to be a particular 'sensor', with
its own driver, and decide that it doesn't need special standardized
status in the same way that a radio or a storage device does.

If you want to add a component that presents the telosb user button,
then stick it in 'platforms/telosb/chips/userbutton', and then we
don't need to debate over the interface.

If you want to factor out a nice generic piece of debouncing logic
that converts a hardware-independent GeneralIO+GpioInterrupt pair into
a higher-level Button or Get+Notify interface, then perhaps it could
go in 'chips/button', where other driver authors could use it if they
choose.

But as for trying to decide whether all buttons on all platforms
should provide the same standardized interface... I'd suggest leaving
this one up to the platform maintainers.

Gil

On 11/27/06, Philip Levis <pal at cs.stanford.edu> wrote:
> Rather than going down a rathole, let's take a step back.
>
> Basically a button is a digital IO line with debouncing. Are there
> other inputs where you want to
>
> 1) Know when it goes high
> 2) Know when it goes low
> 3) Provide debouncing
>
> which are not buttons? I'd imagine touch sensors, rain gauges, or
> other sensor which depends on a physical contact. Not all care about
> both 1+2. This seems like a more general library component that can
> sit on top of a GpioInterrupt component.  The fact that you care
> about both directions makes this distinct from the SID Notify
> interface, unless you had two Notify interfaces, with the value being
> a timestamp.
>
> Gil, what are your thoughts?
>
> Phil
> _______________________________________________
> Tinyos-2.0wg mailing list
> Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg
>