Not just another TMR q


Closed Thread
Results 1 to 7 of 7
  1. #1
    Join Date
    May 2005
    Location
    Minnesota
    Posts
    31

    Default Not just another TMR q

    9v battery application using a 16LF628 and an external 4MHz resonator.

    Time delay is switch selectable, 5 minutes to 5 hours. Presently, the circuit will go to sleep for the selected amount of time. I have noticed that the time in sleep mode can vary greatly between IC's. So much that I have been looking into the TMR function. I understand the prescale, setting up the registers, servicing the interrupts . . . My question is this, will the circuit consume the same amount of power when only the timer is running as it would if, say the uC is in a loop waiting for an input? In sleep mode the uC consumes very little power, which is why I selected it to begin with. Also, depending on the answer to the first question, can the timer be interrupted with a Change on PortB int?

    I was thinking about counting the number of interrupts required in 5 minutes, and 5 hours, for example, and test that condition to see if the selected time delay had been reached. Not the right way to go about it, but the board has been made, I'm already tacking on an external resonator to the SSOP pkg, and there is no room for an external clock IC.

    As always, I appreciate the thoughtful responses from the forum.

    Brad

  2. #2
    Join Date
    Jul 2003
    Posts
    2,358


    Did you find this post helpful? Yes | No

    Default

    This could be tricky... you may need to find available space for a lead-acid battery or two...

    Firstly, the internal Timers are shut off during SLEEP mode and can't wake the processor because all the peripheral logic is shut down. But the processor can be woken by either RB0 or change on some of the PortB pins.

    See Special Features of the CPU section in the Datasheet.

  3. #3
    Join Date
    Jul 2003
    Posts
    2,358


    Did you find this post helpful? Yes | No

    Default

    Thinking about it... there IS a way...

    The WDT (if set) will Time-Out when the PIC is put to SLEEP and awake the PIC. By assigning the prescaler to the WDT, you can control how long the PIC will sleep before it's woken. Simply increment a counter each time the PIC wakes to a value closest to your pre-set time. If the count hasn't been reached, the PIC goes straight back to sleep. OK, so you're not going to be sleeping 100% of the Time Period, but sleeping 99.9% of the time is better than consuming power by being awake 100%.

    So, in a nutshell, just count the number of WDT wake-up's...

    When there's a thought... there's a way...

  4. #4
    Join Date
    May 2004
    Location
    New England
    Posts
    164


    Did you find this post helpful? Yes | No

    Default

    HI Melanie - just curious, isn't that more-or-less what the PBP "SLEEP" command does?
    Also, seems like he'd still have the inaccuracy of the WDT clock to deal with (variance between devices, etc).

    Arch
    "Data sheets? I ain't got no data sheets. I don't need no data sheets. I don't have to read any stinking data sheets!"

  5. #5
    Join Date
    Jul 2003
    Posts
    2,358


    Did you find this post helpful? Yes | No

    Default

    Yes, in a way. PICBasics SLEEP uses the WDT but doesn't cause a WDT event. I was actually thinking about causing a WDT to happen... but yes you're right, both methods rely on the WDT oscillator which isn't too hot on accuracy.

    Without adding external Hardware, we're in trouble here trying to maintain accurate timing whilst in a Low-Power quiesce mode. Lots of things 'should have' been designed in... if I was doing this, I'd probably run my application at sub 100kHz and have chosen one of the better Micropower PICs, and/or have an external RTC that could wake me every second. But Brad's stuck with an existing design and has to make the best.

    Best thing to do, if Power is really an issue, is to switch all I/O's to ensure there's minimal current drain, and run the PIC at the slowest clock rate you can get away with. If that means a 32kHz xtal and having to manually work-out Pauses and Timings for PBP, then so be it.

  6. #6
    Join Date
    May 2005
    Location
    Minnesota
    Posts
    31


    Did you find this post helpful? Yes | No

    Default Thanks for the quick response

    Melanie-Thanks again for the fast responses.

    I'll try your suggestion counting WDT events.

    Max time in sleep mode is closer to 2 hours, not 5, and the timer/clock will be reset at least once a day so accumulative time errors will not exist past the end of say 16 hours of continous operation.

    I was hoping you would suggest some of your code from the Olympic Timer project. I saw something that might work at this link http://www.picbasic.co.uk/forum/showthread.php?t=603

    What do you think?

    B

  7. #7
    Join Date
    Jul 2003
    Posts
    2,358


    Did you find this post helpful? Yes | No

    Default

    Yes, my Timer Code will happilly work for you but not when the PIC sleeps, and I thought you wanted to conserve power by sleeping?

Similar Threads

  1. Elapsed Timer Demo
    By Darrel Taylor in forum Code Examples
    Replies: 111
    Last Post: - 29th October 2012, 17:39
  2. internal TMR for frequency output
    By Samoele in forum mel PIC BASIC Pro
    Replies: 0
    Last Post: - 15th January 2009, 09:38
  3. Why does TIMER slow down when using longer pause
    By GrandPa in forum mel PIC BASIC Pro
    Replies: 5
    Last Post: - 6th July 2007, 00:35
  4. How to use TMR command?
    By Samoele in forum mel PIC BASIC Pro
    Replies: 5
    Last Post: - 28th January 2007, 21:37
  5. Can a TMR interrupt stops HSERIN?
    By SergioRM in forum mel PIC BASIC Pro
    Replies: 0
    Last Post: - 24th January 2006, 01:07

Members who have read this thread : 1

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts