Hi Michael and Jez,

Michael wrote:


Actually, that would be (in this case) Arun's job. Actually, in this case, I did not offer a design. I offered an idea. I leave it to the implementor to do his/her own engineering.

(Actually, the reason I keep starting sentences with the word "Actually" is as much because I really enjoyed that A-Team cartoon someone posted as for rhetorical effect.)

Here's my position. Every design choice we make is always a judgement call. But every solution is not necessarily more code. If you have a µ-controller doing nothing but monitoring a thermocouple and a pushbutton, then a firmware debouncing routine is the obvious choice for the pushbutton. But at some point the µ-controller will become sufficiently tasked and taxed that you will have to start asking yourself whether it's worth the compute cycles to debounce the pushbutton. At some point you need to think about using a Schmidt trigger device to debounce the pushbutton.

Unfortunately, I get the impression that a lot of embedded people are starting to get like software people, piling on more and more code and leaving it to the chip designers to make it all fast enough. Basically, unless you know how to do something in hardware, then as a designer it's no longer your choice because you have no choice. It is, IMHO, always best to know how to accomplish a task both ways if possible. Only then can you make an educated choice.

And now Arun, thanks to my initial idea and your added comments, at least has the basis of how he can detect edges in hardware, assuming he can do the requisite engineering to make it sufficiently reliable for his purpose.

Joe