| View previous topic :: View next topic |
| Author |
Message |
bartman
Joined: 14 Nov 2012
Posts: 5
|
| #use_delay bug? |
 Posted: Tue Jun 28, 2016 6:11 pm |
 |
|
The following sample code to illustrate the problem seems to increase the loop cycle by exactly the delay_ms value (ie changing to 50ms causes a 50ms increase in total loop time. I think this is a bug, because the delay_ms shouldn't be resetting the WDT unless #use_delay has the restart_wdt option included.
Is there a way, not documented in the manual or that I've missed, to prevent the delay routines from resetting the wdt?
Compiler version 5.061 (and at least back a few versions)
| Code: |
#include <12LF1840.h>
#device adc=10
#FUSES WDT //Watch Dog Timer
#FUSES PUT //Power Up Timer
#FUSES BROWNOUT //brownout reset
#FUSES NOFCMEN //Fail-safe clock monitor disabled
#FUSES NOLVP //No low voltage
#FUSES NOMCLR //Master Clear pin used for I/O
#FUSES NODEBUG
#include <stdio.h>
#include <stdlib.h>
#use delay(internal=16MHZ)
void main() {
setup_wdt(WDT_256ms);
While(1) {
output_low(PIN_A5);
delay_ms(10);
output_high(PIN_A5);
sleep();
}
}
|
Thanks in advance to anybody that can confirm. |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Jun 28, 2016 7:16 pm |
|
|
Look at the .LST file. If the compiler is doing what you say, you'll find
CLRWDT instructions in the ASM code for #use delay().
I'd suggest getting rid of these two lines since they are not used in your
program and they clutter up the .LST file:
| Code: | #include <stdio.h>
#include <stdlib.h> |
|
|
|
bartman
Joined: 14 Nov 2012
Posts: 5
|
|
| Posted: Tue Jun 28, 2016 8:42 pm |
|
|
When in doubt, read f'n manual...turns out on this particular chip, the sleep command clears the WDT before going to sleep, and again coming out.
Thanks anyway  |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19543
|
|
| Posted: Wed Jun 29, 2016 12:52 am |
|
|
| All PIC's do this (can't think of any that doesn't).... |
|
|
bartman
Joined: 14 Nov 2012
Posts: 5
|
|
| Posted: Wed Jun 29, 2016 1:17 am |
|
|
Your right they do  . Its not something I'd ever really considered or cared about until I wanted a semi accurate timer that works in sleep in a low power application, as per an old mchip appnote.
Thanks guys for setting me straight  |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1355
|
|
| Posted: Wed Jun 29, 2016 8:17 am |
|
|
| bartman wrote: | Your right they do . Its not something I'd ever really considered or cared about until I wanted a semi accurate timer that works in sleep in a low power application, as per an old mchip appnote.
Thanks guys for setting me straight |
There are quite a few chips out there that can do that with an external timer clock/crystal on timer1 (or timer0). You have to check the data sheet to make sure the time used has an asynchronous mode and that you can wake from sleep using that input.
I don't work with many of the 8bit chips, but as an example on almost any of the PIC24FJ chips you can put an accurate 32kHz crystal on the SOSC pins and tell timer 1 to run off of that. The PIC24FJ series will wake from sleep off of this interrupt. I've used various flavors of PIC24FJyyGAxxx chips in this configuration
Additionally if you don't care about accuracy much at all some small number of chips have an internal LPRC crystal that can be assigned to timers to wake from sleep. However, the majority (all?) of these have really abysmal tolerances (upwards of + or - 15%). The PIC24F32KA302/304 has this option as an example. However, I usually fall back on the above suggestion of external 32kHz crystal as I want more accurate timing.
Also, this thread from the Code Library might be of interest if you come up with a good hardware implementation:
https://www.ccsinfo.com/forum/viewtopic.php?t=26177 |
|
|
asmboy
Joined: 20 Nov 2007
Posts: 2128
Location: albany ny
|
|
| Posted: Wed Jun 29, 2016 2:05 pm |
|
|
without knowing your counting needs - i've found
the DS1305 is an awfully nice way to get larger timing increments
and useful alarms with very low pic overhead.
especially good for waking from sleep with a single pin interrupt flag after n-seconds or more of activation.
The best part is - a simple driver lets you deal in whole -second multiples of alarm with an external interrupt ( wake ) from the chip...
if you need resolution to "wake" that is sub-second - that's tougher.
Last edited by asmboy on Wed Jun 29, 2016 3:32 pm; edited 1 time in total |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19543
|
|
| Posted: Wed Jun 29, 2016 2:23 pm |
|
|
In fact just about all the PIC's (except a few PIC12's etc.), can wake using a timer1 crystal. You setup the timer to stay running, and then just load a 'preload' value into the timer counter, disable global interrupts, clear and then enable the timer interrupt, and sleep. When the timer wraps, the interrupt triggers and wakes the chip. You then disable the timer interrupt and do what you want. Since the global interrupt is disabled, no handler is called.
So with a 32768Hz crystal, a 'preload' of 49152, gives a wake in half a second from when loaded. Many times more accurate than any of the watchdogs. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
