CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

internal RTC (TIMER1), current consumption, etc

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
SteveS



Joined: 27 Oct 2003
Posts: 126

View user's profile Send private message

internal RTC (TIMER1), current consumption, etc
PostPosted: Tue Jan 20, 2004 3:47 pm     Reply with quote

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



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Tue Jan 20, 2004 6:00 pm     Reply with quote

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



Joined: 08 Sep 2003
Posts: 839
Location: Houston

View user's profile Send private message

PostPosted: Tue Jan 20, 2004 8:17 pm     Reply with quote

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



Joined: 27 Oct 2003
Posts: 126

View user's profile Send private message

PostPosted: Wed Jan 21, 2004 7:25 am     Reply with quote

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



Joined: 08 Sep 2003
Posts: 839
Location: Houston

View user's profile Send private message

PostPosted: Wed Jan 21, 2004 9:15 am     Reply with quote

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



Joined: 27 Oct 2003
Posts: 126

View user's profile Send private message

PostPosted: Wed Jan 21, 2004 3:52 pm     Reply with quote

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



Joined: 08 Sep 2003
Posts: 839
Location: Houston

View user's profile Send private message

PostPosted: Wed Jan 21, 2004 5:18 pm     Reply with quote

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.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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