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

[Phil Buonadonna]

> What do you mean by "generic peripheral interrupt?" So far, the  
> Interrupt interface has not been used for internal devices (e.g.,  
> SPI, UART); instead, their interrupts are controlled through 
> a device  
> specific interface.

Effecitvely, this answers my question.  That is, Interrupt.nc is implicitly
a GPIO ping interrup interface. Great.

> I am wary of doing this unless we understand the design space better.
> 
Not too much to understand, I think. Except that there are/will be devices
which can be set to interrupt on both edges, not just one.  If we stick to
the present interface, we consciously block this capability. I think that's
just fine, but we should be aware of it.

pb


> -----Original Message-----
> From: Philip Levis [mailto:pal at cs.stanford.edu] 
> Sent: Thursday, October 20, 2005 12:55 PM
> To: Phil Buonadonna
> Cc: Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
> Subject: Re: [Tinyos-2.0wg] Interrupt interface
> 
> On Oct 20, 2005, at 12:04 PM, Phil Buonadonna 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.
> 
> What do you mean by "generic peripheral interrupt?" So far, the  
> Interrupt interface has not been used for internal devices (e.g.,  
> SPI, UART); instead, their interrupts are controlled through 
> a device  
> specific interface.
> >
> > 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)
> >
> 
> I actually think it came out of the MSP430 code. But you're right,  
> the possibility of both can't be covered. Hm. What sorts of chips  
> support that? The PX?
> 
> > Proposals:
> > 1) Move interrupt to a new interface called GPIOInterrupt and  
> > create a new
> > Interrupt.nc in which there is only an enable feature.
> 
> This ignores the "I can do one or both" possibility...
> 
> > -or- 2) Keep the present interface, but document 'enable()' 
> where the
> > argument is optional (seems kludgy)
> >
> 
> Agreed.
> 
> > 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
> 
> I am wary of doing this unless we understand the design space better.
> 
> 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