[Tinyos Core WG] non-TEP code

Jonathan Hui jhui at archrock.com
Tue Nov 28 09:26:14 PST 2006


Joe Polastre wrote:
> Actually, it includes what you're talking about with:
> 
> enable() and disable() -- self explanatory
> pressed() -- this is the "falling" edge event
> released() -- this is the "rising" edge event
> get() -- this is to get the level position (i'm not sure how a level
> trigger is relevant versus the first two)
> 
> if you only care about a single edge, then you only handle pressed(),
> for example.

My point exactly. The Button and GpioInterrupt interfaces are 
functionally very similar. They also have similar philosophies in 
pushing for static binding, thanks to living in this TinyOS world.

In a level trigger mode, a pressed/released interrupt would keep firing 
as long as the button is in that state, similar to how MCUs implement 
level triggered interrupts.

> Agreed.  The primary difference with a button is that you don't
> specify the edge to trigger on explicitly like you do an interrupt.
> We could decide that this is the position that we want to take, but I
> actually like having both edge events occur automagically under the
> covers rather than explicitly having to ask for the rising edge
> interrupt after the falling edge interrupt occurs (and likewise, the
> debouncing happening for you automatically too).

I see, so you do want abstract some functionality. We did think about 
doing the same for GpioInterrupt but the atmel doesn't support a 
both-mode for edge-triggered interrupts. Specifically, both-mode would 
need to be emulated in software and because it switches the mode itself, 
what happens if a hardware interrupt is missed (e.g. would we miss the 
falling-edge if we already missed the rising-edge)?

Maybe we can say that buttons never have this problem because a human 
can only press a button so fast, and we just assume that buttons have 
some minimum period between edge triggers.

The debouncing looks like its only in the advanced interface, not in the 
basic interface. Which looks fine since the advanced interface is 
implemented on top and adds functionality. It looks like only the press 
is debounced. What about buttons that are pressed in their "common" mode 
and you'd rather be signaled on a long release?

--
Jonathan Hui
jhui at archrock.com


More information about the Tinyos-2.0wg mailing list