[Tinyos-host-mote-wg] Re: [Tinyos-2.0wg] Interrupt interface

David Gay dgay42 at gmail.com
Thu Oct 20 14:36:39 PDT 2005


On 10/20/05, Phil Buonadonna <pbuonadonna at archedrock.com> wrote:
>
> The 'enable' function of the interrupt interface
> (tos/interfaces/Interrup.nc) takes as an argument a flag to determine wether
> it should fire on a rising or falling edge.  This implies that the interrupt
> is based on a digital signal transition (i.e. a GPIO pin) rather than a
> generic peripheral interrupt in which there is no notion of 'edge
> transition' but rather just an event.
>
> The docs of the interface say that it is microcontroller independent, but it
> really isn't in this case. It is specific to 1) Digital (GPIO) signals and
> 2) interrupt controllers that can fire on only one type of transition:
> rising OR falling BUT NOT both. (As I understand it, this is because the
> ATmega128 is limited to this case)
>
> Proposals:
> 1) Move interrupt to a new interface called GPIOInterrupt and create a new
> Interrupt.nc in which there is only an enable feature.
> -or- 2) Keep the present interface, but document 'enable()' where the
> argument is optional (seems kludgy)
>
> As for the double edge trigger issue, one option is to simply not accomodate
> this function in TOS 2.0.  That is, in TOS 2.0 you can define a GPIO trigger
> on a rising edge XOR falling edge. Which is fine, if that's the consensus.

There's more options than rising, falling, or both. The two obvious
missing ones are high and low-level - for instance, the atmega128 does
rising, falling and low, and on some pins only, both falling and
rising... (fun, no?)

>From this, and the fact that there's no clear subset of pin-interrupt
conditions, I'd like to suggest the following:

- there's a generic Interrupt interface with just
enable/disable/fired, with no arguments.
- option 1) each microcontroller gets its own XXXPinInterrupt
interface - some platforms may even get several if they are like the
atmega128; these interfaces allow you to configure the pin's behaviour
at enable time
- option 2) each microcontroller offers generic components with
microcontroller-specific arguments specifying the interrupt rules, but
these components offer the no-argument Interrupt interface

Note that option 1 and 2 are not incompatible... (2 can/should? be built in 1)

Btw, we could try and define a platform-independent GPIOInterrupt
interface with a bunch of enable options, but this strikes me as a bad
idea:
- if we use the union of all possible choices, we get two problems:
what is the set of chocies + runtime failure for
impossible-on-this-platform
- if we use the intersection, we probably end up with the empty set

David

_______________________________________________
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


More information about the Tinyos-host-mote-wg mailing list