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

[mturon at xbow.com]

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.

Martin 
__________________________________________________
Martin Turon  |  Crossbow Technology, Inc.

-----Original Message-----
From: Philip Levis [mailto:pal at cs.stanford.edu] 
Sent: Saturday, October 01, 2005 11:27 AM
To: Joe Polastre
Cc: mturon at xbow.com; tinyos at barnowl.org
Subject: Re: [Tinyos-2.0wg] Power Management

On Sep 30, 2005, at 7:59 PM, Joe Polastre wrote:

>
> When did you run into this questions and why?  I couldn't find any
> reference to it in the notes.
>

The notes look a bit brief on the matter. There's a brief mention of  
it in the Notes2 text for 9/7. Martin proposed this mechanism as a  
way to disable devices that essentially have no wakeup time and whose  
power draw is miniscule compared to the active MCU but significant  
compared to a sleeping MCU. This way, rather than having to manually  
control the power state, TinyOS would just do it for you. The example  
Martin gave was the mica flash chip.

In the 9/7 meeting, Rob pointed out that you can't disable pins  
unilaterally because you might be in the middle of an operation and  
the MCU has no way of knowing this. This would cause you to power off  
the flash in the middle of an operation. Martin agreed that this was  
a bad idea and so we tabled the automatic pin stuff as unnecessary  
unless there is an example of where/when/how it could be used to  
conserve power.

> If you can work out how to start and stop components, the pin
> management follows automatically (and this policy of turning your pins
> off when you're done actually DOES work in TinyOS 1.x!)

That was the general conclusion from the PM discussion. I think the  
general consensus is that we want to keep the MCU power state  
mechanisms as simple as possible, but also cover the important corner  
cases which some platforms might introduce. That's why there's the  
override command.

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