Mark Willis wrote:

> 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!);

  Thanks Mark, I had suggested that, but I think privately.

  My other suggestion was to multiplex as an 8 by 2 array (all of PORTB
and two lines of PORTA utilized for up to 16 "stations") as per my reply
last week to the "Multiplexing" thread, using as a matter of some
convenience, two wires per node with the LED across these in one
direction and the switch plus a diode in the other.  The diode in series
with the switch prevents anything from "shorting out".

  I understand that Greg has decided to multiplex but he hasn't
specified how.

  Fairness?  Well now.  The priority encoder isn't fair as it favours
the highest priority.  Forget that (if you *are* concerned about
fairness).

  How about reading the port in parallel?  Fine but for two
considerations.  First, Greg wanted *ten* inputs.  That means more than
one port anyway, and you can't read two ports at once and on a PIC, you
need to process one fully before you can even look at the other due to
having only one accumulator; that's at least two instructions apart to
dump it to a shadow register.

  And then you have to decide what to do if you *do* have a "tie".  Use
a randomize algorithm?

  Can I propose the fairest solution to be one in which an
isosynchronous nest of two loops performs multiplex scanning on PORTB?
That is, the inner loop continuously rotates a bit mask and compares it
to PORTB, breaking if it finds a switch set.  The outer loop alternates
between the two port A lines and the code is tuned such that the move
from the last bit of one "row" to the first bit of the other is the same
as from one bit of one row to the next.

  This is of course slower, but since we have agreed that *nothing* can
ever be fast enough, that really doesn't matter.  It's not totally fair
since for a given pair of switches pressed simultaneously, it is more
likely that one will be scanned first (as it is more likely that when
both were pressed, the scan was passing one of the other switches than
moving from one to the other.

  *This* however may be easily randomized by having the wait loop for
the "Start" (or if there is none, the "Reset") button drive a counter
the LSB of which determines the direction of the scan.  If you cannot
predict which way the scan will run, and the scan in effect spends
exactly equal time moving one button to the next, it is - as fair as you
will get since you have distributed the latency precisely.

  Now, one PIC for 16 stations.  Is that cheap enough?  From an
engineering viewpoint, using 74HC00 chips as R-S latches, even if they
are dirt cheap, instead of the proper quad packages, *plus* some other
glue logic, results in a pretty hairy PCB and that should ring some loud
bells on fabrication costs.

  I would have thought that an octal latch and an octal NAND per 8
inputs (any output causes the latch enable to go false) would be the
smallest and simplest if you don't like the PIC.
--
  Cheers,
        Paul B.