Mark Willis wrote:

> 2 possibilities here:

> Either the PIC pin's only set as output then the next instruction sets
> it LOW, in which case the switch (to ground) isn't going to hurt it (A
> mechanical switch 'forcing' an output pin to the same state it's > already
> IN, is hardly going to hurt it!);

> Or, you plan to set all PIC pins as outputs, including those set HIGH,
> in which case you're going to have nothing but problems when the other
> contestants hit their switches.

> I'd suggest the first option <G>  And make all contestants take their
> hands off their buttons once they've pressed 'em, as otherwise their
> LEDs will stay on.

Mark,

Exactly. In the single, cheap, PIC with minimum parts count, approach I
propose, only the first contestant input to be detected as a low would
change to an output and go low.

Yes, any of the other switches pressed after that would light their LED
but only the "first" would stay lit with no switches pressed.  If two or
more lights were on, the moderator would say, "Take your fingers off the
buttons so we can see who was first."

This design is a combination of switch debounce and first occurrence
detection.  My suggestion to Greg was to try this first.  Then see what
he needs to do about differences in switch characteristics and the need
to continue sampling all inputs after the first low input is detected.

Without also writing the code, how many microseconds would it take
between samples of the same pin at the desired clock rate?

What is the bounce waveform of the switches going to look like when the
button is first pressed? Min/max on-off time, slope?  What is the effect
of contestant switch cable length, type of cable and current through the
switch and voltage applied.

This is also a 10 input logic analyzer or 10 channel o'scope with 2
state output for each channel.

I'm saying, see what happens with the minimum hardware and minimum code
then go from there.

How about building a test fixture to mechanically  press two or more
switches simultaneously?

Don