internal RTC (TIMER1), current consumption, etc

[SteveS]

I need a low power Real Time Clock to wake up the processor periodically (maybe every 15 secs or so). I've been playing with an external RTC module, but am looking now at the internal setup using Timer1 (18Fxx20) and a 32Khz crystal at T1OSO and T1OSI. It looks like it may take more current than an using an external RTC, but it may not be enough to matter. I've looked thru the archives and don't see too much on using the internal clock - what has been the experience with it - esp in terms of current consumption and battery backup? I would put the chip to sleep between wake-ups of course. I would also need a backup battery to allow basic timekeeping to continue without main power. I know many of the external devices deal with the power switchover automatically, which is nice.

TIA

[PCM programmer]

We are looking at this issue on our current project.
Tentatively, we've decided to use the Watchdog timer
to periodically wake up the the PIC from sleep.
In the newer PICs, the WDT only takes 2 or 3 ua.
For a 2100 NiMH mah battery, that's not much.

The WDT post-scaler can be set for the maximum
timeout period. Then, if we need a longer period
we can do the standard practice of keeping a
count of "wake-ups" and then do the required
processing after we've reached that count.

The fact that the WDT can vary with temperature
quite a bit doesn't hurt us, because the amount
of time between "checks" doesn't have to be
exact. We just want to do it every few seconds.

Using the WDT this way doesn't affect the normal
usage of the WDT (which we will likely also need).
That's because the data sheet (for 18F) says that
if a WDT timeout ccurs in Sleep mode then execution
resumes at that point, but if a WDT timeout occurs
in normal operation then a reset is performed.

This approach seems a lot cheaper than adding a RTC
chip to the project (including a crystal, and probably
a separate battery).

[Neutone]

Using an external 32K crystle is very low power. The 32Khz crystle runs low power all the time. Using the WDT has a single efficiency drawback versus using a crystle. The WDT has to start your crystle on wake up and requires time to start oscilating. It can spend a lot more time starting than running in this situation but is still low power. The lowest power option is using a second crystle to increment a timer. The marginal gains often don't win over cost and the WDT is usually the way to go.

[SteveS]

The WDT timer is a good idea. I don't need real accurate wake up times, but I do need a RTC for date/time stamps so I'm kinda stuck with an external RTC or using Timer1 as an RTC.

BTW, on the topic of wake-ups. At least some of the 18F series processors have a neat quasi-sleep mode where the processor sleeps but the peripherals keep clocking - not extreme low power, but good for some applications - like wake up on RS232 without losing any characters.

[Neutone]

I am aware that you can shift data into a chip via an SPI interface and cause an interupt. I am not aware of any PIC's that you can do this with for the serial USART because the USART is dependant on the clock for timing. What chips are you refering to?

[SteveS]

The 18F1320 for one:

- from the data sheet
-------------------
3.3 IDLE Modes
The IDLEN bit allows the microcontroller�s CPU to be
selectively shutdown while the peripherals continue to
operate. Clearing IDLEN allows the CPU to be clocked.
Setting IDLEN disables clocks to the CPU, effectively
stopping program execution (see Register 2-2). The
peripherals continue to be clocked regardless of the
setting of the IDLEN bit.
---------------------

I was surprised myself when I ran across it, as it is a fairly unique feature. Now it doesn't cut current down to the few uA like SLEEP, but in my application it cut idle current more than half - down to 0.7mA from 1.7mA. I needed to keep RS232 and an input capture running, but had nothing to do until a character came in or an edge was caught.

Pretty cool.

- SteveS

[Neutone]

I would say it's pretty cool all right. This is the first I have heard of the enhanced USART module. It has auto baud rate detection built in as well it's own communication oscilator seperate from the system clock. That probably explaines the remaining 0.7mA.