View previous topic :: View next topic |
Author |
Message |
yossihagag1978
Joined: 04 Apr 2013 Posts: 19
|
WDT |
Posted: Sat Oct 17, 2020 11:56 pm |
|
|
Hi
I am using restart_wdt option in #use_delay:
Code: | #use_delay(clock=2000000, restart_wdt) |
I noticed that when i use this option some delays are not accurate when using
delay_us(x);
For example x=100 or 200 or 500 is accurate but some others not.
But when i disable this option (restart_wdt) from #use_delay,
every x i put is accurate.
How can i know when the compiler execute restart_wdt ?
Using v5.008 compiler.
regards
Yossi |
|
|
bkamen
Joined: 07 Jan 2004 Posts: 1615 Location: Central Illinois, USA
|
|
Posted: Sun Oct 18, 2020 12:34 am |
|
|
Don't forget to use setup_wdt to actually configure the WDT for the interval you want.
(see setup_wdt() )
Then, in your main loop, you use restart_wdt() to restart it. You have to put that in.
The restart_wdt in use_delay only makes sure to restart the WDT in functions like delay_ms()... but if your code is off doing other things, and you exceed the WDT timeout, then you'll have a problem (and a reset).
Check ex_wdt.c for an example.
Lastly, think hard about how you code and whether to set up interrupt driven timers to tick time where your functions get called based on that ticker which allows main to run at full speed without long delays using delay_ms() (or other long delays). _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
yossihagag1978
Joined: 04 Apr 2013 Posts: 19
|
|
Posted: Sun Oct 18, 2020 12:59 am |
|
|
I did set setup_wdt() to 1 sec.
Still did not answer my question:
How can i know when the compiler executes restart_wdt ?
Each 1000 us or every other number ? |
|
|
bkamen
Joined: 07 Jan 2004 Posts: 1615 Location: Central Illinois, USA
|
|
Posted: Sun Oct 18, 2020 1:14 am |
|
|
yossihagag1978 wrote: | i did see setup_wdt() to 1 sec
stiil did not answer my question
how can i know when the complier execute restart_wdt ?
each 1000 us or every other number ? |
Ideally, you put restart_wdt() in your main loop.
now - in the use_delay() and including "restart_wdt", the compile will add restart_wdt() to both delay_us() and delay_ms() functions.
If you look at the list file, you'll see the instruction in there too. (it'll be in assembly)
Any time you call delay_ms() or delay_us(), restart_wdt() will be in there.
If you never call delay_ms() or delay_us() within the time period you've set for the WDT, it will cause a restart.
That's why you also want to add it to your main loop. _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
Re: WDT |
Posted: Sun Oct 18, 2020 4:46 am |
|
|
yossihagag1978 wrote: |
For example x=100 or 200 or 500 is accurate but some others not.
|
Post some delays that are not accurate, and post what you get.
Example:
Nominal 150us delay is actually 155us.
In other words, tell us the details.
Also tell us your PIC. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9229 Location: Greensville,Ontario
|
|
Posted: Sun Oct 18, 2020 5:47 am |
|
|
Really need to know the PIC type. WDT, especially on early PICs, wasn't very accurate. Some speced at +-50%, so a WDT, set to say 1 second, could 'trip' at .5 to 1.5 seconds and be within the 'spec'.
Newer PICs are better but you cannot use them as a RTC or any application that needs accurate timing.
The main purpose of a WDT is to restart the PIC if it ever fails to run right. This would be the last 'coding' you would do. Normally WDT is not enabled until the product it ready to be sold. Then it's enabled, tested. Typically as Main() grows during developement, the timeout value of the WDT would have to be increased. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19518
|
|
Posted: Sun Oct 18, 2020 11:30 am |
|
|
Restart WDT in the delays, is actually one of the worst things offered by
CCS. It fundamentally invalidates the WDT operation.
Key with a watchdog, is that the restart should be designed so it can
_only_ be reached if everything genuinely is running correctly.
Not having this means the restart can be 'accidentally' reached, which
then means the watchdog cannot do it's job.
I would never use this 'feature'. Instead i f you must have a delay longer
than the watchdog period, 'divide it up', and have a delay shorter than the
period that is repeatedly called, and on each loop check the conditions
that show everything is running correctly, and only if these are OK,
reset the WDT. |
|
|
|