Timing And Loop Fundamentals

I have been using PIC BASIC Pro for a long time, however all my applications have been very basic, a range of inputs and range of corresponding outputs,
and a small amount actual processing.

The timings are simply based on a short pause at the start of the main loop with lots of variables incrementing on each loop. The inputs and counter variables are checked during each loop and outputs set when required. So no other pauses required, although various command like serial and A/D are used.

However, when the amount of time counters or the amount of input / outputs start to grow and the lenght of time counting requirements increased (perhaps into days), the accurancy is a problem. Until now i have just measured the error over a couple of hours, then made an adjustment to the loop pause.

But anything that is added into the loop at a later stage or things like serial outputs makes everything go astray, this does not seem like the right method.

I have started to use TMR0 interupts / prescaler, so no pauses in the main loop, just variables incrementing on each interupt.

The next issue was that if i now want to use sleep to save power i am stuck, i believe that TMR0 shares the prescaler with the watchdog, used for sleep, so i would have to use another timer.

Getting to the point, what is the best way to handle all these timings, and if sleep is required, how can this be used when no current pauses are used?

I also understand that sleep (or nap) is not accurate, so if i just used this instead of the interupt method, my problems may be even worse.

I have assumed that the device would go to sleep, wake up via the interupt (which would be accurate), then increment all the counters & check the conditions and set outputs etc. all from inside the interupt rountine.??

Any comments or clarification would be appreciated.

Gordon

Hi,
When you put the PIC to sleep the main oscillator shuts down. If the timer you're using to generate the interrupt is clocked from the main oscillator (ie you're not clocking it from an external source) then the timer stops incrementing and will never overflow thus never generating the interrupt that's supposed to wake the PIC up again.

There are several possible ways to do what you want, I'm going to sugest one here. TMR1 has its own oscillator which can be driven by an external x-tal, for example a 32.768kHz clock x-tal. When clocked externally it won't stop counting when the rest of the PIC goes to sleep so the interrupt caused by the timer overflow will wake it up.

Depending on the PIC you're using there may be various power managed mode, for example Idle. In Idle mode the CPU core is shut down but any enabled peripherals such as the timer(s) are still clocked. Take a look at the Power Managed Modes section in the datasheet for the particular PIC you're using.

/Henrik.

I'm fairly new to 'sleep' (fairly new to PICs and programming come to that), but if you intend using sleep, then I'd suggest dedicating Timer1 to any counting that must happen while asleep.

I'm not sure I'm understanding this sentence...

Quote:

---

I have assumed that the device would go to sleep, wake up via the interupt (which would be accurate), then increment all the counters & check the conditions and set outputs etc. all from inside the interupt rountine.??

---

When you say increment all counters....from what? (I guess a bit more meat on the bones wrt what's happening in your circuit)

How I'm doing it...

pic goes to sleep (timer 1 still counts while asleep)
WDT wakes PIC up (pretty accurately)
the PIC while briefly awake (digesting toast & supping coffee), checks timer1 blah blah
pic then goes back to sleep
WDT wakes pic up, the kettle goes on...rinse repeat.

To save more battery power, I set the WDT period initially to wake the pic up every 128mS, but then after 2 hours of no buttons being pressed (no humans about), the WDT only wakes the PIC up every 2 seconds (I have to change timer1's prescalers to reflect the longer 'sampling period'). As an aside, I've got my overall 'sleep' circuit current draw down to 10uA ....I'm pretty happy with that ( about 6 years in standby for a single 9v battery)

I've still not learned a good way to approach all the loop timing thoughs (& yes, it's a PITA when you change parts of your loop...the timing then go out the window!)...I use online stopwatch & hserout a lot!

Hi Hank,
I suspect Gordon is maintaining a bunch of software counter/timers in his code, much like in a PLC or something like that. I'm sure he'll elaborate on that.

Quote:

---

How I'm doing it...
pic goes to sleep (timer 1 still counts while asleep)

---

So are you clocking TMR1 externally then or are you using one of the "idle-modes" where the oscillator isn't shut down?

I'm asking because I was sure that the main oscillator is shut down when entering sleep-mode and when TMR1 (or any timer) is set to timer mode it is being clocked by the now shut down oscillator so it can't keep ticking.

If indeed your TMR1 is ticking while the device goes to sleep can you tell us what device that is, I'd like to read up on the datasheet on that one.

/Henrik.

Sorry for not being clear, I was outlining how I appproach sleep in general (using the WDT to wake the PIC up vs using a timer interrupt)

Like I say I'm still finding my way & new to sleep....presently learning about capacitive touch....during sleep, when configrued right, Timer1 counts the output pulses from the capacitive touch module ...which still outputs during sleep (I would have offfered that up as an idea...use the capactive touch module to clock timer1 while sleeping, but it's not particularly steady & its frequency drifts quite a bit with enviromentals!)

Thankyou for the comments.

Sorry i was not clear about the timers, yes, these are just software variables which are incremented and cleared as required.

My questions are general, i don't have something specific in mind just thinking about the best way of doing things, i think i have got lazy and just stick to the same old methods all the time.

The devices i have been using don't have the power managed idle mode, but i can see others that do and this seems quite a good idea.

I thought that if i used the WDT to wake the chip, then do whatever, this would not be as accurate as using the TMR interupt.

Also, i am right in thinking that if i used the TMR1 with the external crystal, which would be accurate, then i could set the main oscillator to internal? As the program timings would all come from TMR1.

Gordon,

If you use XLP device, and running tmrX from x-tal, and everything else turned off, it consumes only about 1uA...
You have in code example RTCC that use only 2 uA...