Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Putting the PIC to sleep

Status
Not open for further replies.

Overclocked

Member
Heres what I want to do; I have a interrupt routine that goes off ever second, samples the ADC and sends it over UART (via bluetooth, HC-05). Right now my Main while loop does nothing. I want to put the PIC to sleep while it does nothing, to try and get the current draw down (The whole system together consumes 25mA-The Bluetooth module takes up the majority of it). I must be missing something, because I tried putting in

Code:
asm
sleep
end asm

Into my while loop, and the PIC just sits there. I must have missed a register or something. I am using Timer 1 with a 32kHz crystal.

Code:
{
*****************************************************************************
*  Name  : Datalogger_A.BAS  *
*  Author  : Chris S  *
*  Notice  : Copyright (c) 2014 Open Source  *
*  : All Rights Reserved  *
*  Date  : 10/4/2014  *
*  Version : 1.0  *
*  Notes  :  *
*  :  *
*****************************************************************************
}
Device = 18F13K22
Clock = 16
Include "IntOSC.bas"
Include "USART.bas"
Include "utils.bas"
Include "convert.bas"
Include "ADC.bas"
Config FOSC = IRC

Dim
 Channel2 As Word,
 TMR1IE As PIE1.0, // TMR1 Interrupt Enable
 TMR1IF As PIR1.0, // TMR1 Interrupt Flag
// TMR1ON As T1CON.0, // TMR1 Count Enable
Timer1 As TMR1L.AsWord // A quick way of creating a Word Alias
Const
 TMR1StartVal = $80, // User defined TMR1 starting value
 TMR1ReloadVal = TMR1StartVal + 5
Interrupt TMR1_Interrupt()
 Save(0) // Back up system variables
  If TMR1IF = 1 Then
  TMR1IF = 0 // Clear the TMR1 Interrupt
  T1CON.0 = 0 //Turn timer 1 off
  TMR1H = $80 //Preload high byte with 128
  TMR1L = 0  // Preload Low byte with 0
  T1CON.0 = 1 // timer 1 on
  ADCON0.0 = 1  //enable ADC
  ADCON0.1 = 1 //GOGOGOGO
  While ADCON0.1 = 1
  ADResult = (ADRESL)
  Wend
  //read channel 2
  Channel2 = ((ADResult+ 1) * 499) / 1024  //MATHMATICAL!   
   
  USART.Write ("Channel 2: ",DecToStr(Channel2 / 100), ".", DecToStr(Channel2, 2), " ",13,10)
   
   
  EndIf
 Restore // Restore system variables
 
End Interrupt
 
Sub TMR1_Initialize()
 TRISC.0 = 1 // If External clock, then set clock as an input
 T1CON.0 = 0 // Timer 1 off
 TMR1H = $80 //Preload with 128
 TMR1L = 0  //
 T1CON.0 = 1 // timer 1 on
 T1CON.1 = 1 // 1 = External clock from pin RC0/T1OSO/T1CKI (on the rising edge)
  // 0 = Internal clock (FOSC/4)
   
 T1CON.2 = 0 // 1 = Do not synchronize external clock input   
 // 0 = Synchronize external clock input
 // When T1CON.1 = 0;
 T1CON.3 = 1
 T1CON.4 = 0
 T1CON.5 = 0
 T1CON.6 = 0
 T1CON.7 = 0
 TMR1IE = 1 // Enable TMR1 Interrupts

 Enable(TMR1_Interrupt) // Enable TMR1 Interrupt Handle
End Sub

// Start Of Main Program...

TMR1_Initialize // Setup and enable TMR1
USART.SetBaudrate(br9600)
Channel2 = 0
TRISA.2=1 //set channel 2 as a input
ADCON0= %00001000  //channel 2 as ADC input
ADCON2 =%10101010 //12 TAD, FOSC/32
ANSEL.2 = 1

//Main Loop
While True
     

Wend
 
To enter sleep mode you need to clear the IDLEN bit in OSCCON. Note also that the chip takes a little time to wake up and this may make your timer less accurate. For setting Timer1's value in the ISR I would simply set bit 7 of TMR1H as this is the way Microchip suggest.

edit, typo.

Mike.
 
Last edited:
I Think I got it to work. I noticed no difference in the current consumption of the whole circuit. What I did was clear the IDLEN bit right before I initiated the sleep command (all in the same ASM sequence). It seems that I cant get around the current consumption of the Bluetooth Module (HC-05 if anyone is curious). Always consumes around 22mA if its connected (taken on my Meter btw, on my scope I get peaks of 45mA of Current roughly every 1.5mS). 22mA isnt a lot, but I feel it can be better. For this project (its just going to log data and send it remotely, for now it will be temperature) it doesnt make sense for it to update every second.

Realistically, It will be once every 5 minutes. SO what I might do is enable the Bluetooth module right before my interrupt happens, or rather in my while loop I can check how much time has passed (ie if its 5 minutes, then do something). The Module takes a few seconds to pair, but thats not an issue. The only unknown thing is how to check if the BT module is booted up. I wonder if it buffers incoming data, and then sends it out once paired..Hmm.
 
Don't put the PIC to sleep :(
 
have you read these, may have some ideas for you.; Microchip PIC® Microcontroller Low Power Tips ‘n Tricks DS01146B
 
Hi,

What bluetooth module are you using, do you have a link or something?

When you have something else like this that has to run when the uC wakes up, then you need to power it with say a transistor so you can turn it on and off. When the uC wakes up, turn it on, wait for it to stabilize, then start using it. Just before the uC goes to sleep, shut it off (signal to the base of the transistor from an output port pin) and that keeps the power low.

Assuming it takes 1 second to transmit the data and the time interval is 100 seconds (just under two minutes) the duty cycle is 1/100 so if the module draws 20ma that means the average current goes down to 20ma/100=200ua of current.
With only 200ua average current you could run for approximately 2000/0.0002=2778 hours or about 6 months off of three AA cells in series. Increasing the time interval to 200 seconds would increase the run time to almost a full year.

I do the almost the same thing with my refrigerator monitor. Two AA batteries last about 2 years.
 
I am using the popular HC-05 Bluetooth Module, and Ive paired it with my phone. Ive been looking into other RF transceivers (like the NRF series thats also popular). I was thinking of turning it on/off via a pin, but the module seems to take a few seconds to link and stabilize.

Here are (one of many) datasheets for the module. There is something called Sniff mode that I have to look into
ftp://imall.iteadstudio.com/IM120417010_BT_Shield_v2.2/DS_BluetoothHC05.pdf
 
Could you please elaborate on this misterT?

Presumably because it's pointless?, your requirement doesn't have anything to gain from putting the PIC to sleep.

Assuming you wanted to make it so it DID gain something, the answer is to not send the data every second - instead buffer the data and sent data bursts much more infrequently - this would allow you to shut the BT module down entirely, reducing consumption to only micro-amps.
 
I am using the popular HC-05 Bluetooth Module, and Ive paired it with my phone. Ive been looking into other RF transceivers (like the NRF series thats also popular). I was thinking of turning it on/off via a pin, but the module seems to take a few seconds to link and stabilize.

Here are (one of many) datasheets for the module. There is something called Sniff mode that I have to look into
**broken link removed**

Hi,

Thanks for the link i'll have to check that out. I am wondering how far that will transmit.

What i was suggesting is that you turn it off for a good amount of time so that the average current drain goes down very low. If the module takes 3 seconds to stabilize that's a problem but not unworkable. Just keep it off longer and the average still goes down.

I used the 1 second and 100 seconds off just to illustrate how much savings you can actually get. If you have to keep it on for as long as 5 seconds then just keep it off for 500 seconds and you'll get the same results which is still very low average current draw. Yes you wont be able to transmit as often but it sounded like you dont have to anyway.
 
Hi,

Thanks for the link i'll have to check that out. I am wondering how far that will transmit.

From what I tested, about 60+ feet. I had tested a module outside and gotten the same range (I put one in my window and walked to the back of my backyard). I feel the range is more than adequate, and I could basically be anywhere within my house (800 sqft) and still get reception. I would defiantly recommend these modules for simple comms.

Theres also an obnoxious LED that lights up once every few seconds to show if the module is connected. Disabling this on the BT module will help as well.

I get what your saying about transmitting once every so often. Theres a "sniff" mode that I should look into.
 
I think he meant "do not kill" (like a dog).
Yes.. I was bored and just tried to be funny. Sorry if it was confusing for the thread.
I am actually working with a battery powered device at the moment. The goal is to have 5 year battery lifetime. The processor itself is not a problem. The problem is the electronics around it. (two tmp006 sensors, phototransistors, accelerometer, radio etc.). We need to carefully control how to use the sensors. We are down to 20 uA when sleeping, but the goal is around 5uA.. still need to find out where to save.
 
Yes.. I was bored and just tried to be funny. Sorry if it was confusing for the thread.
I am actually working with a battery powered device at the moment. The goal is to have 5 year battery lifetime. The processor itself is not a problem. The problem is the electronics around it. (two tmp006 sensors, phototransistors, accelerometer, radio etc.). We need to carefully control how to use the sensors. We are down to 20 uA when sleeping, but the goal is around 5uA.. still need to find out where to save.

Mine switched all external loads completely OFF (with an FET), leaving nothing but the PIC running in sleep mode with a 32KHz crystal clock running generating 1 second interrupts.

I can't remember what the final consumption was, though it wasn't as low as the datasheet claims is possible - but 'should' meet the required long battery life.
 
Mine switched all external loads completely OFF (with an FET), leaving nothing but the PIC running in sleep mode with a 32KHz crystal clock running generating 1 second interrupts.

I can't remember what the final consumption was, though it wasn't as low as the datasheet claims is possible - but 'should' meet the required long battery life.

In extreme cases where consumption does not come low enough and the period IS a must, putting two batteries in parallel, is it a valid option?
 
In extreme cases where consumption does not come low enough and the period IS a must, putting two batteries in parallel, is it a valid option?

The period was pretty variable, depending on how often the 'alarm' was triggered - if not triggered at all it self-triggered once a month (although the actual period was adjustable via txt message) in order to keep the SIM live. Obviously during these triggered intervals the consumption is pretty high, and the batteries were fairly high power and expensive :D
 
I think the harder part here is the receiver, it too has to only turn on at the same intervals as the transmitter, but What happens if they are a few microseconds apart? I dont think the receiver would get the transmission in time. Any ideas?

I think if I turned the receiver on slightly before the transmitter transmits it should solve the problem.
 
I think the harder part here is the receiver, it too has to only turn on at the same intervals as the transmitter, but What happens if they are a few microseconds apart? I dont think the receiver would get the transmission in time. Any ideas?

I think if I turned the receiver on slightly before the transmitter transmits it should solve the problem.

I wasn't aware you were trying to save power on the receive side as well?, I presumed it was connected to a PC or similar.

Essentially you really need to keep the receiver running permanently - but if you're not connecting to an existing BT, then why use BT at all? - it's just making things more complicated, and increasing consumption.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top