Re: How to develop a random number generation device




John Larkin wrote:

And my point is that it shouldn't "accidentally" get into a broken
state, any more than the program counter of a CPU should accidentally
find itself in never-never land.

If a digital system is unreliable, the cause should be found and
fixed. The problem with kluges like this is the same problem with
watchdog timers: they hide the real problem, so keep it from getting
fixed.

I always turn off the watchdog timer on test units, and protos
delivered to customers. I only enable it after we're sure we don't
need it.

I have seen engineers get into trouble that would have been
avoided had they only followed the above advice.

Another problem-hider is filling unused ROM with jumps to the
reset vector. I only do that on the production units; for
the prototype (and sometimes for the pilot run) I like to fill
unused ROM with stop instructions.

A technique that I sometimes use when designing toys is to
have the button / switch that tells the toy to start moving
and making noise cause a hardware reset, and the timeout at
the end of play that tells the toy to stop moving and conserve
power to invoke the deepest available sleep mode -- usually
with the clock stopped entirely -- to be woken up by the next
hardware reset. In industrial control applications you
sometimes see the same sort of thing but with a counter causing
the resets to occur every N seconds. This techniques isn't
always applicable (check to see how fast the oscillator can
come up, for example; some are annoyingly slow) but in some
limited cases it works well.

--
Guy Macon
<http://www.guymacon.com/>



.

Quantcast