Waking up from an input pin state change.

fernando_g

fernando_g

Senior Member
The title says it what I would like to achieve: essentially a Picaxe which is sleeping most of the time, wakes up by an event, does its required chores, and then goes back to sleep and the cycle repeats.
This as an effort to really minimize the overall power consumption.
The events can occur at any time, thus the doze and sleep commands with its fixed delays, may sometimes miss one.
 
Assuming it's an X2, you could try something like this:

Code: 
#picaxe 20X2
#no_data
#no_table
#terminal 9600
Init:
    hintsetup $22       'Only use Interrupt 1 with rising edge.

Main:
    sertxd(cr,lf,"@Main")
    disablebod          'Disable Brown-Out Detection to save power.
    setintflags $2, $2  'Use hardware interrupt 1 only (20x2, pin18).
    'setfreq k250       'Lowering the clock didn't seem to reduce power in sleep mode.
    sleep 0
    gosub DoStuff
    goto Main

Interrupt:
    enablebod
    setfreq m8
    return
    
DoStuff:
    sertxd(cr,lf,"Do stuff here.")
    pause 1000
    hInt1Flag = 0       'Clear the interrupt flag.
    setintflags $2, $2
    return
 
Hi,

It depends on how low you want the power consumption to be, and whether you need a fast "interrupt" response, or if you are only concerned with not "missing" any events (e.g. pulse-counting).

For the latter, you can poll the M2's "Interrupt On Change Flags" (or the "Timer 1 Gate" logic) the next time that the PICaxe wakes from sleep, which will indicate if an event (or 2) has occurred. These flags are available on more pins than PICaxe's dedicated interrupt inputs, but need to be accessed via a PEEKSFR command (and cleared after reading them). However, the internal Port.pin numbering (used for the SFR commands) can be a little confusing on the 14M2 and 20M2.

The Brownout Detector is included for a purpose - to reduce the risks of the PICaxe crashing if there is a glitch on the supply rail, so normally I wouldn't disable it. Also, the PICaxe's power consumption doesn't change as steeply as the clock frequency, so I'm not convinced that reducing the clock is worthwhile. Theoretically, it even could be worthwhile to increase the clock, if the event-processing is computing-intensive. Then, the processing time (and thus Energy consumed) will reduce by more than the current consumption increases, and then the PICaxe can sleep at very low power.

Cheers, Alan.
 
Give us some idea of the rate / frequency of the event perhaps ?
Power consumption wise I have managed to get power consumption down to sub uAmp twilight zone on 08M2 with a few SFR Pokes.
I can 'poke' this trick up if needed.
BOD on an 08M2 at least seems to make not a lot of difference practically or saving power wise (It Did on 08M)
The 08M used to tolerate direct OP pin driven small DC motors off the same rail to make 'the simplest robots in the world' (Chip + battery + 2x N20 motors
08M2 I have found are too sensitive for that with only a few 10's or 100's of -Ve transients on the supply or OP pins resetting things.
 
Last edited:
Kiwipatch said:
Give us some idea of the rate / frequency of the event perhaps ?
Power consumption wise I have managed to get power consumption down to sub uAmp twilight zone on 08M2 with a few SFR Pokes.
I can 'poke' this trick up if needed.
BOD on an 08M2 at least seems to make not a lot of difference practically or saving power wise (It Did on 08M)
The 08M used to tolerate direct OP pin driven small DC motors off the same rail to make 'the simplest robots in the world' (Chip + battery + 2x N20 motors
08M2 I have found are too sensitive for that with only a few 10's or 100's of -Ve transients on the supply or OP pins resetting things.
Click to expand...
Sorry for not responding sooner.
Walking up about once every 10 minutes.
 
You must log in or register to reply here.
Back
Top