Ungureanu Silviu wrote:
"where in his code should place the WDT reset command?"

True, its not uncommon for us to go beyond the posted question that orginates the topic, and post observations for our peers to debate or reflect upon.

Ungureanu Silviu wrote:
"I understand from your thoughts that you try to avoid using WDT as much as you can."

That is not my purpose, but it is a result. I write my systems in a scheduler/tasker form because its a more logical format and it flows much more efficiently. This structure tends to minimize foreground I/O drivers and so I don't require closed loop polling that would require WDT tapping. Yes this minimizes WDT tapping, but its not the reason for structuring the code that way.

Ungureanu Silviu wrote:
"It's a common practice to deliver one system to a customer with the WDT enabled routine?"

I'd say yes - definately. I manufacture an electronic product to industry and I require that product to be as trouble free as possible. A WDT helps the product to recover from any chaos without the customer even noticing the interruption. The days of supplying your customer a reset button is ending.

Besides a WDT, there are other coding strategies that can make your system more reliable - particularly useful of I/O internal or external without good feedback flags. I have a scheduled task in my scheduler to re-initialize the I/O ports ever so often when they are not in use. This can clean up unavoidable problems like a LATCHED relay getting mechanically toggled by an impact. The idea is, if the micro loses some settings for what ever reason or if the problem can't be perceived by the micro, the problems will still be fixed before the customer can try it a second time.

Ungureanu Silviu wrote:
"How it will be to see software reset in PC without operator"

As an engineer, I like having a reset button on anythin I buy. But that is not agood product strategy for most consumers. Its wiser not to concern them abot power glitches that they can not fix or see. If th micro can handle the situation, recover and continue without a noticable restart message, ALL THE BETTER!

If you program your device to dutifully inform the operator of every glitch you detect, the operator will assume the problem is your overly sensitive product. I want to sell more and make more money - I do not want to annoy the operator by showing off what a clever engineer I can be. :)

Consider to products, One that restarts noticably everytime the power glitches and another that quietly restarts without telling the operator anything happened.

If BOTH get glitched equally everytime but one appears to constantly restart while the other seems to work perfectly... who do you think is going to win the next order?

You have to be BOTH an engineer and a businessman to get rich in this industry.

:)

duh