Re: How to choose a firmware partner

From: Dave Hansen (iddw_at_hotmail.com)
Date: 06/03/04 

Date: Thu, 03 Jun 2004 13:15:27 GMT

On 3 Jun 2004 00:45:31 -0700, robin.pain@tesco.net
(robin.pain@tesco.net) wrote:

[...]
>No, I do read data sheets but I have a small attention span and a bad
>memory so I expect to make mistakes.
>
>Therefore the simpler the system, the more likely it will work (for
>me).
>
>The more sensible the job the more likely it will fascinate my brain.
>
>The sillier the job the more likely my brain will wander, and make
>mistakes.

>
>Therefore I expect to make more mistakes implementing e.g. <wdt>
>types. It may be that I am unique but I doubt it. I think some others
>do likewise and I think the sheer dullness and difficulty
>(impossibility) of optimising the placement of the wdt_resets
>(ignoring future maintainability horror) will likely lead to wholesale
>sloppiness sooner to later and agressive management or timescale
>pressure will guarrantee it.

Misreading (or not reading, or forgetting) the data*** was a silly
mistake.

But the sillier one was trying to "optimize" your WDT updates. There
is really no reason to do so.

For my superloop code, the WDT is updated in exactly two places:
immediately after reset, and at the top of the superloop. Combined
with special "come from" tests to ensure the program flow is as was
expected, our systems have no trouble surviving some really nasty ESD
testing required by our customers. (Without a WDT, I _guarantee_ your
system will fail these tests.)

Multitasking systems also update the WDT in exactly two places:
immediately after reset, and in a low-priority periodic task that
checks to make sure the system is operating correctly.

Under normal operation the WDT is being updated several orders of
magnitude more often than is necessary. Who cares? It's abnormal
operation I care about, and what the WDT is supposed to remedy.

Regards,

                               -=Dave 

-- 
Change is inevitable, progress is not.
Quantcast