Hi,
ISR must be short and fast as possible.
You must avoid calling long and time consuming subroutines in ISRs.
You can use flags in your program, each event has it's own flag that
will be set in ISR and reset in main routine after processing the event.
1 Short and fast (same)
2 If interupt system isn't vector interupt .
you would take care priority from interupt
3 Checked all config that save and restore
for speed save as you need
Each saved config is enought and not overwrite
important data
4 Set trap interupt for check in valid interupt
5 Don't forget stack size (same)
I was planning to set up the watchdog timer for 0.5 sec or 1 sec and i was planning to reset it in timer ISR (which is 100usec). Is there any problem with this? please tell the reason.
I was planning to set up the watchdog timer for 0.5 sec or 1 sec and i was planning to reset it in timer ISR (which is 100usec). Is there any problem with this? please tell the reason.
Yes- your system could either have software bugs, corrupted RAM space, or the main could be stuck in an infinite loop waiting for an external component to respond, and that timer would likely still run though the state is now busted. Since your main code probably runs in a loop, put one or more wdt resets in the loop, preferrably right after doing something useful.
Calling other functions is not necessarily bad in all cases. Depending on language and compiler, it may inline it anyways, but the code may read clearer. The real problem comes about when calling functions which can also be called by the main body. This would mean reentrant calls which not all compilers support, and it consumes a lot of resources (might need to implement it twice) to even give it that capability in the resulting assembly. As such, lib functions may ALSO be bad. So aside from the possible speed issues from doing a floating point op in an ISR, you also have reentrancy issues (so never do this!).
Actually there are cases when resetting a watchdog in your timer ISR can be used. To extend the available Watchdog timer time to a bigger time (eg few minutes). But then you have to create a software watchdog and be very carefull!
Most of the time when you need this, there is something wrong with the software architecture!
Hmm you are right. Even the program fails the timer will continue to run and reset the watchdog so ucontroller won't be resetted which causes an infinite loop.
I increment a counter at the main loop and check its value inside the timer isr. If counter does not increment correcly then I block refresh strobes to the external watch dog. This way, you still have control on the wdt even if cpu goes crazy.