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

[mturon at xbow.com]

Hi Phil,

Yes, I meant the MCU will need to be in ACTIVE state for a UART operation to
be initiated.  Additionally, the CPU can not drop below IDLE while the byte
is being transferred (middle of split phase until done event signaled).

I agree with you that the actual management of external UART devices most
logically belongs in the specific device driver.  Such a driver would
require IDLE as a minimum MCU sleep state using the tep112 mechanism during
the entire split-phase interaction of each byte operation.  

How the UART RX case is handled requires more thought.  On the ATmega128,
you might be able to turn the UART into external interrupt pins, and wake up
the processor, but I doubt you could get the start of the message correctly.

The application components we talked about before that timeout and "spin
down" a device would solve these problems, but not at a very fine-grain.

So to summarize some of the issues: 

- UART TX case: not handled properly with tinyos-1.x power management.
	We should define how we want this to work in tinyos-2.x.

- UART RX case: power management must be disabled currently.
	Designing a way to make this possible generically would be nice.
	We should define how the app writer does this in tinyos-2.x

Martin 
__________________________________________________
Martin Turon  |  Crossbow Technology, Inc.

-----Original Message-----
From: tinyos-2.0wg-bounces at Mail.Millennium.Berkeley.EDU
[mailto:tinyos-2.0wg-bounces at Mail.Millennium.Berkeley.EDU] On Behalf Of
Philip Levis
Sent: Saturday, October 01, 2005 12:57 PM
To: tinyos2 group
Subject: Re: [Tinyos-2.0wg] Power Management

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
_______________________________________________
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