[Tinyos-host-mote-wg] Re: [Tinyos-2.0wg] Power Management

[Philip Levis]

On Oct 1, 2005, at 11:54 AM, mturon at xbow.com wrote:
>
> The devices in question are:
>     1) Thermister (powered via GPIO, sampled via ADC)
>     2) External Flash (powered via GPIO, accessed via UART)
>
> Such devices have the following properties:
>     1) Powered by a GPIO pin
>     2) Resistive load
>     3) Desirable for device to be on and available when CPU on
>     4) Desirable to turn off device when sleeping (~100uA >> 10uA)
>     5) Insignificant current in ACTIVE mode (~100 uA << 8mA)
>
> Yes, you need to keep track of whether an operation is in progress  
> (ADC or
> UART write).  This is generally true for any UART or ADC operation;  
> I don't
> think these cases are well handled currently.
>
> Upon thinking about it, I would expect that the CPU would be  
> involved and
> required to be operating for the majority of an ext. flash read/write
> operation.  Either way, a design exists that can solve this.  Every  
> pin
> powered device could have its own dirty bit in its device driver.
>

What do you mean by "involved and required to be operating?" Do you  
mean in the active state?

As you pointed out in the telecon, it's definitely the case that the  
1.x mica family software (e.g., 128) has bugs. I'm not certain that  
these bugs are due to architectural limitations, though; that is,  
they might just involve fixing some lines of code rather than  
changing how 1.x does things (e.g., consider UART interrupts, turn  
the UART on/off). It's also not clear to me how the current 2.x PM  
architecture is insufficient to deal with these bugs and therefore  
why they require additional mechanisms.

Let's look at this from another perspective: the properties of these  
devices are such that you want their GPIO pins active if and only if  
they are performing an operation. These devices can be turned on and  
off very quickly, which is why you suggested they be part of the  
basic scheduling loop.

Why not turn them on/off on every operation? This can be done  
directly in the driver software, and wouldn't require adding  
additional logic to the core scheduling loop. If the devices are  
active, you don't want the core loop to turn them off; if they're  
inactive, they should be off anyways. Taking care of these pins  
*before* you reach the atomic-no-going-back sleep code seems  
preferable to me, at least.

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