News:

Let's find out together what makes a PIC Tick!

Main Menu

Energy saving project 18f25k22

Started by Giuseppe, Jun 14, 2021, 06:30 PM

Previous topic - Next topic

Giuseppe

Hello everyone
I'm using an 18f25k22 for a project powered by 4 AA size batteries. I saw that by powering only the microcontroller the absorption is 4mA. What ideas come to your mind to reduce this absorption?
To consider that the microcontroller through an external quartz runs the time base for the time, so I don't know if the sleep function can be fine since it disables the oscillators if I'm not mistaken

Mapo

Ciao Giuseppe,
you can disable the peripherals that the pic does not use, it is little thing, but useful

trastikata

Giuseppe,

Can you use the LF version and lower the CPU frequency?

TimB


The most important thing is to determine is how accurate any timings need to be.

On a recent project I had a timing system based around sleeping for ~1ms incrementing a counter until it reached 20hz where I then ran code. As soon as my routines were done I returned to sleep for 1ms.

I also had a timer running that keep timings right during my none sleep eg running my code.

The end result was getting my code running and sleeping in between. While being accurate to ~1-2 seconds over a 1 hour period. Good enough for my needs.

If you need better accuracy consider a 32khz crystal linked to a timer, You can still do the main code but your timer will be 100x more accurate.

Tim

RayEllam

#4
It Totally depends on what the pic is doing. For instance my current water flow meter project requirements are 4AA batteries last at least one year, the PIC has an internal RTC. my code does the following.

1. On a pulse from an ultra low power hall sensor then wake the pic from deep sleep via an interrupt pin, switch internal osc to 1mhz, count pulses, if no pulses after one second then do some math on the pulse count and save to ROM , then deep sleep.

2. Wake from deep sleep a couple of times a day @ 1mhz And check battery.

3. If button pressed, wake from deep sleep @4mhz and turn on OLED display for a minimum of 30 seconds after no more button pressed.

Deep sleep on the pic I'm using is around 100nA with it's internal RTC running, the pic spends most of its time in deep sleep. I'm not sure if your pic supports this?

Giuseppe

Mainly I have to keep updated the time for an activation at a certain time set and saved in eeprom. Then from any sleep you have to wake up if I press one of the 2 setting buttons and also I have to check the reading of an AD channel.
To consider that I have a 4-digit seven-segment display that I go to turn off after 2 minutes of inactivity, already saving some power.
Trastikata by lowering the frequency how much can you save?
TimB can you better explain the hypothesis of the crystal at 32Khz?
RayEllam which Mcu did you use with internal rtc?
Thank you all for answering me

TimB

You can externally clock a timer using an Xtal.

There are a lot of articles on it. eg https://www.bristolwatch.com/PIC16F628A/a4.htm

RayEllam

#7
PIC16lf19156. It's an XLP device with 28 pins, internal RTC and ROM.

You could aso consider driving the 7 segment common pin with pwm via a mosfet and dim the display after a few seconds of inactivity then off after a while  that will save a bunch of power.

When putting a pic into deep sleep it is important to consider any IO connected to pins. The pin state is held in deep sleep. I found it's best to switch the state of all IO pins to be digital outs and set the state for minimum current draw. Also set unused pins to be digital outs, floating pins set to inputs cause havoc on current draw.

Giuseppe

Reading the datasheet of 1825k22 I noticed that decreasing the frequency to 500Khz the consumption is reduced to less than 1mA. Now I have started setting up the registers:

OSCCON = %00100110    'set 4-6 bit 500Khz
OSCCON2 = %00000000
OSCTUNE = %10000000

To test the internal 500Khz oscillator.
The only error that the compiler gives me is on the Xtal that it does not foresee the value of 500 Khz.
How to solve the problem?

RayEllam

As far as I'm aware, the declare crystal only affects the timing of software commands like delayms. So setting declare crystal to say 1mhz will make the timing 2x slower.

trastikata

#10
Quote from: Giuseppe on Jun 15, 2021, 07:16 AMTrastikata by lowering the frequency how much can you save?

Take a look at the "DC AND AC CHARACTERISTICS GRAPHS AND CHARTS" starting at page 454 in the datasheet:
https://www.microchip.com/stellent/groups/picmicro_sg/documents/devicedoc/cn547043.pdf

The power saving depends on the oscillator mode, for example for the 18F version the IDD goes from 8.5mA for 64MHz down to 0.5mA for 4Mhz and about 0.1mA for 1MHz. If you don't need the processing power and can get around with a 32.768kHz crystal, the IDD drops to 15-20 uA.

Quote from: Giuseppe on Jun 15, 2021, 07:16 AMRayEllam which Mcu did you use with internal rtc?

Whenever I have to find a MCU to fit my project requirements, I am using Microchip's MAPS (MICROCHIP ADVANCED PART SELECTOR):
https://www.microchip.com/maps/Microcontroller.aspx

There you can adjust the selection tool according your requirements, including MCU's with Hardware RTCC/RTC.

Giuseppe

The problem is how to declare with xtal 500Khz?

trastikata

I'd declare 4MHz oscillator and adjust all delays and timing-related commands for 8 times slower oscillator i.e. if you need 8 MS delay, you are using 1 MS instead etc. Any timer interrupt is calculated as with 500kHz oscillator, because it is the cycles that you preload in the timer and so on.

Maybe Les can give a much better solution, but that's what I did in the past.

Giuseppe

So there is no declaration of xtal at 500Khz or 1Mhz? From the manual we start from 3 Mhz

slyrye

A bit off-topic what happened to the old Proton PicBasic forum? what happened to Lester? is either dead?

John Drew

Lester decided not to support the forum anymore.
Thanks to Gevv and OG we again have a forum.
John

Giuseppe

I tried set xtal = 4 Mhz and then I set the OSCCON register for a frequency of 500Khz. It seems to go the consumption has reduced from 4mA to 1mA. As stated in the previous messages we must consider the delays are multiplied by 8