[CCC DEV] Sleep (when time permits)

[Omer Kilic]

Hi Matt,

On (13/06/2011 16:24), Matt Jadud wrote:
> 1. Does it preserve RAM? (I assume that because the TVM wakes and
> resumes execution without crashing that the RAM state must be
> preserved.)

Yup. AVR datasheet, page 40 bottom paragraph states:

""
If an enabled interrupt occurs while the MCU is in a sleep mode, the MCU 
wakes up. The MCU is then halted for four cycles in addition to the 
start-up time, executes the interrupt routine, and resumes execution 
from the instruction following SLEEP. The contents of the Register File 
and SRAM are unaltered when the device wakes up from sleep. If a reset 
occurs during sleep mode, the MCU wakes up and executes from the Reset 
Vector.
""


> 2. What happens to peripherals / pin states at sleep-time? (For
> example, if a pin is driven HIGH, does it drop LOW at the point of
> sleep?)

Looking at Christian's commit*, we seem to be using the "power save" 
sleep mode (SMCR = 0x07;) and according to the table in page 40 of the 
datasheet that essentially stops all the running clocks (with the 
exception of Timer2) so I would guess that synchronous modules would 
have trouble operating since there is no active clock source.

As for the pins, the outputs should keep their values but it seems like 
the input buffers (except interruptable ones) are turned off.

 From the datasheet (page 44):

""
In sleep modes where both the I/O clock (clkI/O) and the ADC clock 
(clkADC) are stopped, the input buffers of the device will be disabled. 
This ensures that no power is consumed by the input logic when not 
needed. In some cases, the input logic is needed for detecting wake-up 
conditions, and it will then be enabled.
""


* https://projects.cs.kent.ac.uk/projects/kroc/trac/changeset/7218


> 3. What happens to peripherals at wake-time? (For example, if a pin
> was HIGH, will it come back HIGH?)

Since output registers keep their values you should have the same values 
as pre-sleep. One thing to note is that doing I/O operations instantly 
after wake-up might be problematic since the clock has to settle down, 
wait a few cycles before toggling pins.


> I'm particularly curious about numbers 2 and 3. I'd like to deploy a
> prototype temperature monitor into the field; the deadline for
> completion would be July 3. Ideally, we'd be able to implement the
> following behavior:
>
> 1. Wake on interrupt. (Use a Maxim DS3234 or similar to wake once
> every hour, say.)
> 2. Power up SD card, sensors.
> 3. Read / record data.
> 4. Sleep.

Sounds reasonable.


> What I'm wondering is whether or not we should have internal
> interrupts in the VM so we can
>
> wait.for.interrupt(AVR.SLEEP)
>
> and
>
> wait.for.interrupt(AVR.WAKE)
>
> or similar. I'm not sure if that's the right idea, but my concern is
> whether or not we need to give the developer the ability to write a
> PROC that executes before sleep and after wake. Or, somewhere in their
> code, to be able to use the sleep/wake state as a trigger for some
> behavior. Is that something we would want/need?

Hmm, that would be nice as an optional thing I guess. When the processor 
wakes up it will continue where it left off though so we might have to 
force the stack pointer to where the wakeup function is before issuing a 
sleep command. Alternatively we can use a flag to check if we have woken 
up from sleep every time there is a context switch.

...or there might be a far easier way of doing this in the VM that I 
don't know about :)


> In this particular case, I can do everything I need with INT0. I can
> wait for the INT0 interrupt to wake the processor (which will start my
> pipeline), and I can close things down myself after writing at the end
> of the pipeline. I can even force the issue, and put the processor to
> sleep at the end of the pipeline, so... that's probably not an issue,
> either.

Again, sounds reasonable. I am doing a very similar thing at the moment 
with an RFID module. After a certain amount of inactivity I turn off 
power hungry devices and put the processor down to sleep. When the RFID 
reader detects a card, it raises an interrupt and wakes up the processor 
(which then enables the LCD, etc).


> Anyway. I thought I'd share that. Now, back to working on slides...

I started working on it but didn't have time sadly. The beamer skeleton 
is in the repository.


Cheers,
Omer.