![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
jecottrell
Joined: 16 Jan 2005 Posts: 559 Location: Tucson, AZ
|
General Approach to Reducing Duty Cycle... |
Posted: Fri Nov 10, 2006 1:10 pm |
|
|
18F2525 @ 40MHz
3.236
Hello All,
I've ready many of the 'oscillator switching' threads and have tried to digest the datasheet....
I'm getting ready to attempt Oscillator switching and sleep or idle modes to reduce duty time. I have several questions I can't seem to find definitive answers on in the datasheet (I'm sure they're there, but I don't understand what's being said.)
General plan of attack for reducing duty cycle and power is...
Shut down all peripherals.
Switch from external 10MHz osc w/ PLL to internal RC @ 31khz.
Go to the lowest power mode possible that can be awoken by an internal interrupt (WDT, timer, counter....).
Wait for a fixed period of time (55 seconds for now).
Awake.
Switch to external oscillator @ 10MHz and PLL
Turn peripherals back on.
Questions:
What timer should I use to wake my processor? WDT or one of the system timers?
Which is the best Timer or scheme to do what I'd like?
Any information, wisdom, links to threads that may help would be greatly appreciated.
Thanks,
John |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
![](templates/subSilver/images/spacer.gif) |
jecottrell
Joined: 16 Jan 2005 Posts: 559 Location: Tucson, AZ
|
|
Posted: Fri Nov 10, 2006 3:25 pm |
|
|
PCM,
Thanks for the link. I had seen that in days past (...ok, a long time ago.) It cleared things up a little but I think I may have confused the issue by saying 'internal RC' oscillator. Looking at the datasheet, I really mean my low power osc source will be INTIO2 and most of the appnote is concerning an external RC, no?
Am I interpreting the datasheet correctly in saying that the only internal event (WDT, Timer, or Counter) that can wake the part from sleep is the WDT?
...wait, I think I just caught something I missed before. Datasheet says Timer1 can be used. But that doesn't jibe with 'When a wake event occurs in Sleep mode (by interrupt, Reset or WDT time-out),....' later in the datasheet.
Reading further, (about the WDT), I see some more that I missed. The WDT uses the internal oscillator. So I don't necessarily have to explicitly swap to the internal oscillator prior to sleep. All I really need to do is enable the WDT with the settings I'd like prior to sleeping?
I'll have to search for info on the state of the processor when it is awoken from a WDT event.
Thanks again,
John
EDIT:
Can you preload the WDT to get a roughly accurate wake up? |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Fri Nov 10, 2006 4:10 pm |
|
|
Quote: | So I don't necessarily have to explicitly swap to the internal oscillator prior to sleep. |
The data sheet says this is true:
Code: |
Entering the Sleep mode from any other mode does not
require a clock switch. This is because no clocks are
needed once the controller has entered Sleep. If the
WDT is selected, the INTRC source will continue to
operate. |
Quote: |
Am I interpreting the datasheet correctly in saying that the only internal
event (WDT, Timer, or Counter) that can wake the part from sleep is the
WDT? |
That's not exactly true. The A/D interrupt (while running from the A/D
RC oscillator) can wake-up the chip from sleep. There might be other
methods with this chip. I didn't read the entire interrupt section. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah Guest
|
|
Posted: Fri Nov 10, 2006 4:12 pm |
|
|
The WDT, has it's _own_ oscillator.
No, you cannot 'preload' it, and it's timings are poor.
The point about "interrupt, Reset or WDT time-out", are these are the events that can wake the chip _when it's oscillator is not running_. You can wake the chip from any other interrupt source, _provided you leave the oscillator running, even at slow speed_.
So for an accurate timing, using a timer is better, but the chip will draw more power with the oscillator running, than without.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Fri Nov 10, 2006 4:29 pm |
|
|
Quote: | The WDT, has it's _own_ oscillator. |
That's what I thought at first, but this chip is different.
This chip doesn't have a dedicated WDT-only RC oscillator.
The 18F2525 data sheet says:
Quote: |
For PIC18F2525/2620/4525/4620 devices, the WDT is
driven by the INTRC source. |
Quote: |
The other clock source is the internal RC oscillator
(INTRC), which provides a nominal 31 kHz output.
INTRC is enabled if it is selected as the device clock
source; it is also enabled automatically when any of the
following are enabled:
• Power-up Timer
• Fail-Safe Clock Monitor
• Watchdog Timer
• Two-Speed Start-up
|
Quote: |
Regardless of the setting of INTSRC, INTRC always
remains the clock source for features such as the
Watchdog Timer |
|
|
![](templates/subSilver/images/spacer.gif) |
jecottrell
Joined: 16 Jan 2005 Posts: 559 Location: Tucson, AZ
|
|
Posted: Sat Nov 11, 2006 1:50 am |
|
|
PCM & RJ,
Thanks. It's slowly getting clearer.
Am I correct in saying that the INTRC is 31kHz and any changes to clock speed when using the INTRC are through a divider/multiplier. So, changes in the INTRC clock setting don't change the period of the WDT. The only alteration I can make to the period of the WDT is to work with the post-scaler? (...and more for educational purposes, if an external clock source is used, does the WDT still use the INTRC?... i.e. SLEEP: WDT-->INTRC and RUN: WDT-->Current Clock?)
EDIT:
It also sounds like the hassles of dealing with waking from a WDT may be more than I'm willing to deal with at this point. I guess I'd have to save all the current variables, etc., to EEPROM prior to SLEEP and restore them upon waking? Or is there another approved solution?
John |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah Guest
|
|
Posted: Sat Nov 11, 2006 4:19 am |
|
|
Lesson, always check the structure of the particular chip before posting.
The oscillator structure here is fairly complex. At heart, there is a RC oscillator, which then _feeds_ a variety of other objects. This 'core' oscillator, will need to run when the WDT is enabled, but the dividers from it, to feed the actual processor 'core' are disabled. Hence the WDT itself draws a little power, but less than if the processor is running.
Now this has implications for everything. The first is that the WDT on these chips, should be pretty accurate. A big improvement.
Now, the WDT, is still not accessible to change the current count, but this is not needed. Remember that it costs almost nothing to wake up, inrement/decrement a counter, and if it has not reached a target, go to sleep again. You talk about using a 40MHz clock. Is this the on-chip crystal oscillator, with PLL, or an external clock source?. The reason for this 'mattering', is that if it is the on chip oscillator, then it takes a long time to 'wake up', and therefore a reasonable amount of power. I'd suggest:
In the fuses, configure the watchdog postscale, to 256, and disable the watchdog (this leaves it under software control). The interval will be nominally 256/250 seconds.
Switch to internal oscillator, if the clock is a crystal.
Set a counter to 53
Enable the watchdog
Then simply sleep, decrement the counter, and if is not zero, loop back to sleep.
Set the oscillator back to 40MHz
This will give a total delay of 256/250*53, plus about 120 instructions at 30KHz, giving about 54.5 seconds.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
jecottrell
Joined: 16 Jan 2005 Posts: 559 Location: Tucson, AZ
|
|
Posted: Sat Nov 11, 2006 5:07 am |
|
|
Thanks.
That makes perfect sense now. The timing isn't critical at this point. I'm turning the processor on to open a 'receive' window for some radio comms. I'll start with a pretty wide opening (5 seconds and try narrowing as much as possible later).
The last area I'm unsure of is the state of the processor when waking after WDT timeout. Threads here seem to indicate no extra effort is required. Registers are intact, variables are still valid, etc. But some info in the datasheet seems to indicate some registers are in an indeterminate state?
Quote: | Lesson, always check the structure of the particular chip before posting. |
Unfortunately, I'm in the lower left corner of the 'learning' diagram, the one labeled ignorant/incompetent (that's where you don't know what you don't know....) I was assuming I had a basic understanding of what was going on. I guess I should realize every part is different and learn to study up every time I pick a different part.
Thanks again,
John |
|
![](templates/subSilver/images/spacer.gif) |
jaymiller Guest
|
reducing dutycycle |
Posted: Sat Nov 11, 2006 6:12 am |
|
|
If the reason to reduce the duty cycle is to extend battery life, perhaps you could see about using more powerful batteries.Today's batteries have far more amphours for the size than 20 years ago when I buil remote comm.equip that drew 5mA during 'sleepmode'.Used Gates 5.2Ah batteries then,huge compared to today's offerings.
Just trying to put another perspective on this project.Sometimes bigger is better!
Jay
PCM V2.681
hey,it still works for me ! |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah Guest
|
|
Posted: Sat Nov 11, 2006 7:22 am |
|
|
The comment about checking the data sheet, was for me.
Everything that matters should be retained after sleep. There are some little 'caveats'. One is that the next instruction is 'prefetched' when the processor goes to sleep. This can give the wrong results from things like tests, or if an interrupt is called (it won't actually get called till the next instruction on waking). This is why adding a 'delay_cycles(1)' (a NOP), after the sleep instruction, can be worthwhile.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
Mark
Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA
|
|
Posted: Sat Nov 11, 2006 8:25 am |
|
|
Ttelmah wrote: | Everything that matters should be retained after sleep. |
However, won't he need to locate code at the beginning of the program memory to check the restart cause in order to avoid initialized variables from getting initialized again on startup? The #zero ram would also cause a problem if not "bypassed". |
|
![](templates/subSilver/images/spacer.gif) |
jecottrell
Joined: 16 Jan 2005 Posts: 559 Location: Tucson, AZ
|
|
Posted: Sat Nov 11, 2006 8:29 am |
|
|
Jay,
Thanks for the thoughts. I'm starting with 6 F (3/2 D cell) NiCads @ 7Ah. My first test was spectacular failure. 2 Hours 4x4 drive in, 2 more out and a low battery message 3 hours after installation! (Big shame on me for some really lousy/non-existant testing prior to op-test/deployment. I had a small solar panel attached that I thought would save my bacon... but it didn't. Learn the hard way once and never forget!) I think a combination of a poor charge/conditioning on the batteries or damaged batteries from the folks that soldered up the pack was the problem... I'm still trying to figure that one out. I think eventually I'll be able to go down to 6 D NiCads maybe even C's.
RJ,
That sounds great, I'll throw in a NOP for good measure.
Thanks again to all,
John |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah Guest
|
|
Posted: Sat Nov 11, 2006 9:56 am |
|
|
Mark wrote: | Ttelmah wrote: | Everything that matters should be retained after sleep. |
However, won't he need to locate code at the beginning of the program memory to check the restart cause in order to avoid initialized variables from getting initialized again on startup? The #zero ram would also cause a problem if not "bypassed". |
No.
You are thinking of the smaller PICs.
On the 12 chips, a wake up from sleep, starts you at the beginning of memory. On the 18 chips, you continue with the next instruction (with the caveat about it having been pre-fetched).
This is section 3.52, in the data sheet for this chip, where it explains that a watchdog timeout, when _running_, causes a restart, but when in sleep mode, it causes an exit from this mode.
The initialisation is not called again.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|