Searching \ for 'QUIZ MASTER ( Who is the first?)' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=quiz+master+who
Search entire site for: 'QUIZ MASTER ( Who is the first?)'.

Truncated match.
PICList Thread
'QUIZ MASTER ( Who is the first?)'
1999\07\15@013747 by tens

picon face
part 0 16 bytes
</x-html>

1999\07\15@020553 by Greg Brault

picon face
tens,

I am currently working on the same type of project, on a slightly larger
scale.  I have 10 input switches (for 10 people).  I also wanted to have
10 output lights.  As you know, a PIC's i/o pins do not suit this.  I
had to do a little multiplexing... plus, I have a buzzer sound as well.
If you are interested in exchanging ideas, I would look forward to it...

Greg

{Quote hidden}

1999\07\15@021435 by w. v. ooijen / f. hanneman

picon face
Just that? In Jal it would be (typing directly, might contain some
problems):

-- quiz
-- a0..a4 are input, active low, pulled high with 10k
-- b0..b3 are outputs, active low

var bit button1 at pin_a0
var bit led1 at pin_b0
...etc
var bit quizmaster at pin_a4

port_a_direction = all_input
port_b_direction = all_output

procedure wait_for_answer is
  forever loop
     if button1 == low then
        led1 = low
        return
     end i
     ...etc
  end loop
end procedure

forever loop
  port_b = 0xFF -- clear leds
  wait_for_answer -- wait for someone to answer
  while quizmaster == high loop end loop -- wait for clear
end loop

regards,
Wouter




----------
From: tens <spam_OUTtensTakeThisOuTspamIDOLA.NET.ID>
To: .....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU
Subject: QUIZ MASTER ( Who is the first?)
Date: Thursday, July 15, 1999 08:33

Hi Piclisters,

I'm newbie in PICs field and still learning for PIC codes..
I like to make a "Quiz Master" circuit for a game by using PIC 16F84, to
replace  the similar circuit function that I made by using  Flip-Flop and
Gates ICs.
The main function of the circuit, that will determine who is  the first to
press a button in response to a question ( there are 4 buttons for 4
contestants ) and  the  coresponding output (LED indicator) to the button
will light ON, while the other contestants that pressing the buttons after
the first, will do not have any response to the ouput LED indicator, until
the system is resetted for new Start.
Does anyone have source codes for PIC 16F84 for that application?
Any help is highly appreciated.

Regards,

Paul H..

1999\07\15@024244 by Tony Nixon

flavicon
picon face
> tens wrote:
>
> Hi Piclisters,
>
> I'm newbie in PICs field and still learning for PIC codes..

I haven't tested this but it should work ok. It's written simply, so you
should be able to follow the code.

Contestant buttons connected from ground to PortB pins 0 - 3 with
pullups enabled.
Connect LEDs via 1K resistors to portB pins 4 - 7

       list p=16c84,c=140    ; processor type

status equ 3h
intcon equ 0bh
trisa equ 85h
trisb equ 86h
option_reg equ 81h
t0if equ 2h
temp equ 0ch

         ; 4MHz clock
         ; prescaler set to divide by 32
         ; gives about 8mS delay for mnloop
         ; you can change this to suit your requirements
         ;
         ; -------------
         ; PROGRAM START
         ; -------------
         ;

       org 0h

       clrf porta
       clrf portb
       bsf status,rp0      ; RP 1
       clrf trisa          ; all outputs - not used
       movlw b'00001111'   ; 7 - 5 = LED outputs, 3 - 0 = key inputs
       movwf trisb
       movlw b'00000100'   ; pullups on, prescale 1:32
       movwf option_reg
       bcf status,rp0      ; RP0

       ; maybe put a powerup delay routine here

mnloop  nop             ; wait approx 8mS
       btfss intcon,t0if
       goto mnloop

       bcf intcon,t0if ; reset timer flag
       movf portb,w    ; read portb
       movwf temp      ; store result

       rrf temp        ; if carry clear, key #1 was pressed
       btfc status,carry
       goto Check2

       bsf portb,4     ; contestant 1
       goto Loop

Check2  rrf temp        ; if carry clear, key #2 was pressed
       btfsc status,carry
       goto Check3

       bsf portb,5     ; contestant 2
       goto Loop

Check3  rrf temp        ; if carry clear, key #3 was pressed
       btfsc status,carry
       goto Check4

       bsf portb,6     ; contestant 3
       goto Loop

Check4  rrf temp        ; if carry clear, key #4 was pressed
       btfsc status,carry
       goto mnloop     ; no keys pressed

       bsf portb,7     ; contestant 4

Loop    goto Loop       ; wait here until power down


       end

PS Don't forget to disable the WDT

--
Best regards

Tony

'The Engine' - Design your own programmer.

http://www.picnpoke.com
Email picnpokespamKILLspamcdi.com.au

1999\07\15@030151 by Tony Nixon

flavicon
picon face
Just as an exercise, I wrote the quiz game for The Engine ;-)

It works OK too.

BlockStart(Quiz)

 SetTrisB(11110000)

 Label(Loop)
   Wait(8000)
   PortA>>GPB1
   SetFlag1(shrGPB1)
   ifFlag1=True(Goto(Cont1))
   SetFlag1(shrGPB1)
   ifFlag1=True(Goto(Cont2))
   SetFlag1(shrGPB1)
   ifFlag1=True(Goto(Cont3))
   SetFlag1(shrGPB1)
   ifFlag1=True(Goto(Cont4))
   Goto(Loop)

 Label(Cont1)  ; contestant 1
   SetPB0(Hi)
   Exit
 Label(Cont2)  ; contestant 2
   SetPB1Hi)
   Exit
 Label(Cont3)  ; contestant 3
   SetPB1Hi)
   Exit
 Label(Cont4)  ; contestant 4
   SetPB1Hi)
   Exit

BlockEnd

--
Best regards

Tony

'The Engine' - Design your own programmer.

http://www.picnpoke.com
Email .....picnpokeKILLspamspam.....cdi.com.au

1999\07\15@044848 by tens

picon face
Hi Tony,

Thanks  so much for posting the codes.
I will try it, and advice  the result later.

Regards,

Paul H.
======================
{Quote hidden}

1999\07\15@184558 by paulb

flavicon
face
Greg Brault wrote:

> I have 10 input switches (for 10 people).  I also wanted to have 10
> output lights.  As you know, a PIC's i/o pins do not suit this.  I had
> to do a little multiplexing... plus, I have a buzzer sound as well.

 Well the multiplexing is simple and elegant - I mentioned one approach
in my answer to the Video Switcher ("Re: Multiplexing Questions") a week
ago.

 An alternative approach, perhaps not entirely suitable for this
particular application, is to share one switch and one lamp output on
each I/O pin.  You have switches pulling I/O lines to ground and those
lines pulling down corresponding lamps returned to the Vcc rail (likely
via buffers).

 This means that the lamps are *always* lit when the corresponding
switch is closed, but are latched by the MCU detecting the logic low and
setting that port line as a low output (else input of course).
--
 Cheers,
       Paul B.

1999\07\15@203919 by Wagner Lipnharski

picon face
"Paul B. Webster VK2BZC" wrote:
{Quote hidden}

How fast can you read the switches and decide if any is pressed?
That loop speed would be the resolution between the 1st and 2nd person
pressing the switches.
You can have persons pressing switches with a time difference of only
half microsecond. Can you afford to say they pressed at the same time?
when they didn't?  It can happens if in the previous loop port reading
there was no switch pressed, and at the next reading two switches are
pressed.

Even using an interrupt triggered by any switch pressed, you can have
problems. The first person pressed the switch, triggers the interrupt.
During the interrupt service timing, a second person press a switch. The
interrupt routine will read the port and find two switches pressed...
who pressed first?

The really best solution is use an electronic scheme that once one
switch is pressed, it just disable all other switches. Then the
microcontroller will read the port and will *always* find just one
switch pressed.

One way to do that is just use small SCR's at each switch. All SCR's
gate have a resistor to ground. All SCR's cathode are grounded. The SCR
anode goes to the port pin pulled up by a resistor.  There is another
pulled up (common) wire that goes to all button switches. The other side
of the button switch goes to its SCR's gate.  Each SCR anode has a small
diode (diode cathode to SCR anode) going to the common wire.

It means that once the first button is pressed, the common wire pulled
up voltage triggers its SCR, the SCR conducts its port pin to ground and
also grounds the common wire via its diode. No other SCR would be able
to be gated since the common wire has no more voltage.  The SCR of the
first pressed switch still conducting, its port pin is zero, all other
port pins are up level.

You can install a LED at the pull-up of the port pin, so just the first
switched would have the LED lighted.  To reset the situation, just set
low all the port pins, it would remove the latch condition of the SCR
and it will go high impedance again.

I don't have the minimum idea how fast the SCR can remove the voltage
from the common wire, and that would be the first to second person
timing resolution.

--------------------------------------------------------
Wagner Lipnharski - UST Research Inc. - Orlando, Florida
Forum and microcontroller web site:  http://www.ustr.net
Microcontrollers Survey:  http://www.ustr.net/tellme.htm

1999\07\15@212923 by Greg Brault

picon face
Wagner,

First of all, I'm not about to have 10 SCRs lined up in a row for
that... too much :)
what happens in my code is that the 10 switches are encoded via a
priority encoder.  this outputs a 4 bit code of any switch that is
pressed. (16 possible...).  The code loops until that code does not
equal 0000 (no switches pressed).  once this happens, it exits the loop
that checks for that case, and goes into the part that lights up the
corresponding light.  this is accomplished thru a simple 1 of 10
decoder...  Meanwhile, other people can push switches, but their light
won't light up cuz it's not even checking if that code is not 0000.
Once reset, it again goes into the mode of checking that 0000 code.  The
whole circuit thus contains three chips... the PIC, and the
encoder/decoder.
Greg

Wagner Lipnharski wrote:
{Quote hidden}

1999\07\15@214410 by Wagner Lipnharski

picon face
What is the priority encoder chip part number?

Greg Brault wrote:
>
> Wagner,
>
> First of all, I'm not about to have 10 SCRs lined up in a row for
> that... too much :)
> what happens in my code is that the 10 switches are encoded via a
> priority encoder.  this outputs a 4 bit code of any switch that is
> pressed. (16 possible...).
[snip]

1999\07\15@220743 by Mike Keitz

picon face
On Thu, 15 Jul 1999 20:38:47 -0400 Wagner Lipnharski
<wagnerlspamspam_OUTEARTHLINK.NET> writes:


>You can have persons pressing switches with a time difference of only
>half microsecond. Can you afford to say they pressed at the same time?
>when they didn't?

The simplest thing would be to have a provision in the rules for the
times when the quizmaster reports more than one button was pressed at the
same time.  Most non-scientists are entirely comfortable with the
concept, and even expect that, two contestants will press their buttons
at "exactly the same time."  We know that such a rule is only necessary
because of limitations in the quizmaster hardware, but it would be very
rarely used.

Or, the quizmaster could quietly resolve multiple presses and always
report a clear winner.  It could be done just with a priority encode
scheme, but this gives a slight advantage to the contestant with the
highest priority button.  Only slightly more complicated would be to
choose one of the multiple pressers at random.  Seed the random number
generator with something like the time until the button was released for
the last answer.

Don't slow down the polling if a button is pressed for anything.  Using a
loop like:

wait_pressed
       movfw   PORTB
       skpnz           ;Skip if a button was pressed
       goto    wait_pressed

there is a window of up to 4 instruction cycles (1.6 us at 10 MHz xtal)
during which two buttons could be pressed and it wouldn't be possible to
resolve which one was first.


>Even using an interrupt triggered by any switch pressed, you can have
>problems. The first person pressed the switch, triggers the interrupt.
>During the interrupt service timing, a second person press a switch.
>The
>interrupt routine will read the port and find two switches pressed...

This is a good idea but I think it only shortens the window to 3
instructions.  The very first instruction in the ISR should read the
port.  Since the interrupt can only occur at one specific place in the
main program (when the quizmaster is armed and waiting for someone to
press a button), it is not necessary to go through the usual context
save.

>The really best solution is use an electronic scheme that once one
>switch is pressed, it just disable all other switches. Then the
>microcontroller will read the port and will *always* find just one
>switch pressed.

Using logic gates, the "window" between one switch being detected pressed
and the others locked out could be easily less than 100 ns.  Using very
fast logic, it might be less than 1 ns.  But no matter what hardware is
used, there will *always* be some finite time during which multiple
presses would be recognized.  I can think of logic where a multiple press
would be detected as no press (Each button has a set-reset latch), and
the output of each latch resets all the other latches).  Then the next
bounce of the switches would decide it.

>One way to do that is just use small SCR's at each switch. All SCR's
>gate have a resistor to ground. All SCR's cathode are grounded.

Nah, this is going to be too slow.  You have to run the common wire out
to all the buttons, and it will take a relatively long time to discharge
its capacitance once the first SCR fires.  Also the SCRs are likely to
not be matched in turn-on time, thus one contestant has an advantage.
Use ECL gates, or the fastest CMOS FPGA you can find.  But still there is
a chance that multiple presses will be recognized.



___________________________________________________________________
Get the Internet just the way you want it.
Free software, free e-mail, and free Internet access for a month!
Try Juno Web: dl.http://www.juno.com/dynoget/tagj.

1999\07\15@222951 by Dennis Plunkett

flavicon
face
At 21:44 15/07/99 -0400, you wrote:
>What is the priority encoder chip part number?
>
>Greg Brault wrote:
>>
>> Wagner,
>>
>> First of all, I'm not about to have 10 SCRs lined up in a row for
>> that... too much :)
>> what happens in my code is that the 10 switches are encoded via a
>> priority encoder.  this outputs a 4 bit code of any switch that is
>> pressed. (16 possible...).
>[snip]
>
>

Yes I would like to know too, as this would at first glance seem to bit a
bit biased to the person that is on the highest priority, unless of course
you have some form of first press block, but then if both are at the same
time (Effective) then the highest would win!

Dennis

1999\07\15@224529 by Wagner Lipnharski

picon face
complementing...

For sure you can have a heavy (500W, hehe) lamp connected to each SCR
anode, as the "pull up" to the port pin, and all lamps connected to a
common power +VLAMP controlled by a FET transistor tied to a 11th port
pin. Once that port pin drop the common +VLAMP to the lamps it will
reset any "First Pressed Switch Lamp On".

If the voltage drop across the small diode (0.6V) can sometimes allow
others SCR to trigger, just install another diode in series with the
cathode of each SCR, then it will requires 1.2V to trigger a SCR.

No kidding about the 500Watts lamp, it could be just above the person,
and it would "light on" just the person who pressed first.

--------------------------------------------------------
Wagner Lipnharski - UST Research Inc. - Orlando, Florida
Forum and microcontroller web site:  http://www.ustr.net
Microcontrollers Survey:  http://www.ustr.net/tellme.htm

1999\07\15@231850 by Brent Brown

picon face
Hi,

I made a simple Quiz master thing a few years ago now and
remember thinking about some the ideas being discussed.

For my Quizmaster I used an Atmel AT89C2051 with 6 push button
switches and 6 high brightness 10mm LEDs.  The LEDs ran
straight off the I/O ports with 470R resistors, ~7mA, and they
proved bright enough for indoor use.  The circuit runs off a little 9V
battery, which gets replaced every time the unit is used (about
once or twice a year).

I just constantly polled the inputs in sequence, (after all, the micro
has nothing else to do!), and the first switch found pressed caused
the appropriate LED to come on for about 3 seconds, then LED
turned off and polling recommenced.

In the case of simultaneous responses my scientist mind was
quieted when I considered that mechanical variations in the switch
contacts, like softer/harder springs, shorter/longer travel etc,
probably had a significant impact on the arrival time of the trigger
pulse, not just the actual response time of the contestant. (ie. If
two contestants RESPOND at exactly the same time, would both
electrical impulses actualy ARRIVE at exactly the same time?)

Polling at an appropriately fast rate adds a random function that I
think makes a fair enough decision in this case.  To illustrate this,
if I connect all 6 inputs to one switch and press it I always get a
different answer.  There is a constantly changing priority beacuse
at any random moment in time there is no way of knowing which
input is next to be polled and will be acted upon first.

Phew, I feel better after adding my 2 cents...Brent.

Brent Brown
Electronic Design Solutions
16 English Street
Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile: 025 334 069
eMail:  @spam@brent.brownKILLspamspamclear.net.nz

1999\07\15@234013 by Richard Martin

picon face
If you consider how the standard differential input pair for a op-amp
works (sometimes called an emitter coupled pair) you will see
that the first input to go high (for NPN parts) shuts off it's partner.
The winners' collector is pulled low, the losers' stays high. So just
use ten (rather than two) such emmiter coupled n-tuples.
This circuit has some name I've long forgotten. It has all the good
(and bad) features of the (-pair) and most of the analysis pertains,
for example use a current source rather than merely a (common)
emitter resister to get high gain== sharp threshold. Vbe matching
is easier using the DIP (single substrate) transister packages.
High beta input devices are good, and, yes the circuit CAN
oscillate just like it's opamp little brother.

You can set a threshold by artificially biasing the common emmiter
point a bit high, for instance by an 11-th input transistor.

An interesting question is whether you can fashion such a thing
from the UN-buffered CMOS inverter package with the 'emmiter'
resister on the ground lead. Any guesses?? Who will try it.?

I think the 11-th (threshold) device can form part of the classic
Schmidt trigger (hysteresis) circuit to latch the result for a while.
Though I don't quite see how right now.

R.Martin.

I just remembered: the R-S flipflop variant on the was called an 'N-flop'
works on the same principle.

Mike Keitz wrote:

> On Thu, 15 Jul 1999 20:38:47 -0400 Wagner Lipnharski
> <KILLspamwagnerlKILLspamspamEARTHLINK.NET> writes:
>
> >You can have persons pressing switches with a time difference of only
> >half microsecond. Can you afford to say they pressed at the same time?
> >when they didn't?

1999\07\16@005132 by Greg Brault

picon face
priority chip # is 74148

Wagner Lipnharski wrote:
>
> What is the priority encoder chip part number?
>
> Greg Brault wrote:
> >
> > Wagner,
> >
> > First of all, I'm not about to have 10 SCRs lined up in a row for
> > that... too much :)
> > what happens in my code is that the 10 switches are encoded via a
> > priority encoder.  this outputs a 4 bit code of any switch that is
> > pressed. (16 possible...).
> [snip]

1999\07\16@005137 by Greg Brault

picon face
Ok,

True, i am using a priority encoder, and this prevents two people from
buzzing in at the same time.  However, since the loop to detect buzz-ins
is like 4 instructions long, the chances of two people buzzing in (with
a 10 mhz xtal) is very slim.  Either way, some method has to be used,
and i've looked at others, and this seems the most efficient... mostly
because it prevents 2 simultaneous buzzes with few chips

Greg

Dennis Plunkett wrote:
{Quote hidden}

1999\07\16@012859 by Wagner Lipnharski

picon face
Greg Brault wrote:
>
> priority chip # is 74148
>

Tell me which button would be the higher order, I will be there.
If everybody presses the button at the same time, I will always win.
According to my point of view, this is not the best chip for the job.
Simple J-K flip-flops would work better, then feed them to the 148.
Wagner

1999\07\16@013745 by Greg Brault

picon face
Wagner,
I disagree.
Like someone had posted earlier today (sorry, i don't remember!), the
composition of the switches, spring constants, etc, add more variables
to the scenerio.  So (as quoted earlier today), the person who may know
the answer first, and pushes the button in the SAME INSTANT (within
microseconds) as another player, and even having top priority, still may
not get it.  Plus, I was in quizbowl for my entire high school career.
Their systems cost A LOT of money, and i wanted to build one for cheap.
very rarely did i see two lights on at the same time... indicating two
people were within that margin of time to do that (this can't even
happen with the encoder design ... just showing how often that scenerio
would happen)
Greg

Wagner Lipnharski wrote:
{Quote hidden}

1999\07\16@041057 by Donald Riedinger

picon face
R. Martin wrote:

> I didn't totaly follow the argument at the time it was of the nature
> of a law of physics or mathemetics (or death and taxes). It was
> calculated that the memory systems would lock up about once every
> ten years. Nobody confirmed this experimentaly.

What's wrong with 10 SCR's? 48 cents each for TO92 sensitive gate 0.8
amp SCR's from Mouser.  20 resistors so the first switch pressed causes
it's SCR to conduct and light it's light but pulls up the common side of
all the bulbs (resistor from bulb common to ground) so subsequent switch
closures will not turn on the gates of any of the other SCR's.  $5.00
plus switches and bulbs.  Since there is no clocking of logic involved,
it will work correctly every time plus drive healthy light bulbs.

Or how about 10 D flip flops with 2 input And gates on the D input.  One
input of each and gate goes to a switch. The not Q outputs are all or'ed
and the output of the 10 input Or gate (actually an And gate) goes to
all the other inputs of the And gates on the D inputs.  The Flip flops
are clocked together at a high rate.

If any switch is pressed, a high is clocked in and that flip flop Q
output goes high lighting its light.  At the same time that flip flop's
not Q goes low.  Now that one of inputs to the 10 input And gate
(inverted input, inverted output Or gate) the 10 input And gate output
will go low bringing one input of all the 2 input And gates low thus
disabling all inputs.

The first switch bounce that get clocked in is the winner.  If the #1
contestant's switch bounces low when the clock occurs and #2's switch
happens to be high on the next clock and #1 is low again, the machine
makes a wrong call.  A tie would also be possible juat from propagation
delay. Switch bounce is in milliseconds, logic can be clocked in Mhz.
Shouldn't be a problem more than once in ten years.

Same with the SCR's. SCR's wouldn't conduct and lockout other
contestants instantaneously.  A tie would be the only failure mode with
the SCR's.  If it's that close, maybe it is a tie.  As long as this game
isn't a matter of life or death.  And heck, there's millionaires that
don't pay taxes.

It's at least difficult to synchronously sample inputs with a PIC.

Don

1999\07\16@093716 by Wagner Lipnharski

picon face
Greg,
In real I am spreading the idea. Suppose there are no persons, but
machines, circuits voting, then speed is totaly dependent.  I still
believing a $10 circuit is cheap.  A single key and one lamp would cost
much more than all the electronic gates necessary to make it by the
right way.  If a key spring is stronger then other and it would delay
the contestant answer (even that the rule is "who makes first the switch
click", so key spring doesn't count), initially you don't have a way to
know that, and it makes part of the game, the same way if a contestant
is faster to know the answer but lazy to press the button.  Still
winning who makes first the click at the switch. But you already know
that a priority encoder circuit has a tendency, so it is changing the
situation about who made the first click.

Now, suppose you have 10 PIC units collecting data and you want to know
which one ends up first the calculation or data gattering, would you
still using the 148? for sure not.  Then, by the same price you can have
a "correct" way to do that.

Lets see;  each 74HCT00 can be used to build the necessary flip latches
for two contestants, so you would need 5 units, each one cost around
$0.20, you will spend $1.00 to have the right timming circuit, with less
than 10ns of possible error.  Increasing $1.00 in your Quiz Master to
make it "correct" is too expensive?  I don't think so.  Then use a 10 to
4 encoder and a shift register to send the 4 bits to the pic in just few
wires....

I am not trying to tell you what you should do, just telling you that
there are better ways to do it by the same cost.

:)
Wagner



Greg Brault wrote:
{Quote hidden}

1999\07\16@174127 by Greg Brault

picon face
I wanted the design to use the less space possible, less construction
needed, etc.. So using 1 pic compared with 10 scrs, or 1 pic compared
with a D flip flop with a 10 input OR gate... well, i chose the pic :)
Greg

Donald Riedinger wrote:
{Quote hidden}

1999\07\16@175543 by Greg Brault

picon face
Wagner,

I see your point.  It would be slightly more than a dollar, but hey,
cheap at that.

Greg

Wagner Lipnharski wrote:
{Quote hidden}

1999\07\16@184047 by Donald Riedinger

picon face
R. Martin wrote:

> I didn't totaly follow the argument at the time it was of the nature
> of a law of physics or mathemetics (or death and taxes). It was
> calculated that the memory systems would lock up about once every
> ten years. Nobody confirmed this experimentaly.

Greg Brault wrote:

> I wanted the design to use the less space possible, less construction
> needed, etc.. So using 1 pic compared with 10 scrs, or 1 pic compared
> with a D flip flop with a 10 input OR gate... well, i chose the pic :)


Greg,

One 22V10 PAL might just do everything for you.  My point was, a PIC
can't look at all the inputs at once.

Why do you need the decoder and encoder?  Just use port B and half of
port A of a PIC16C54 or something.  Connect LED's through current
limiting resistors from power to PIC I/O pins.  Connect momentary N/O
switches to ground the I/O pins and LED cathodes when pressed.

Your program sets all 10 pins as inputs then continuously scans them
looking for a low input.  You'd probably need 100k pull-ups on the I/O
pins.

When a switch is pressed, it lights the corresponding LED through the
switch.  The PIC sees that input is low and then jumps to a routine to
make that input an output and then make it low until reset.

Don

1999\07\16@185724 by Greg Brault

picon face
again, i fooled around with dualling each i/o pin as input and output.
i also ran into probs thinking about what would happen if the same
player hit their switch again, while the pin was set as output.  at
least with my couple designs i tried to come up with, i couldn't get one
that wouldn't short something out

Greg

Donald Riedinger wrote:
{Quote hidden}

1999\07\16@195831 by Richard Martin

picon face
Greg Brault wrote:

> I wanted the design to use the less space possible, less construction
> needed, etc.. So using 1 pic compared with 10 scrs, or 1 pic compared
> with a D flip flop with a 10 input OR gate... well, i chose the pic :)
> Greg

One of the issues here has been whether the Quiz Master is "fair"
(i.e. has no builtin baises that a knowledgable contestant could
exploit) or not. Priority encoders and sequentially bit scanned PIC
ports aren't "fair" (And most fiddling with the machinery 'in front' of
them won't make them 'fair', just more uncertain). N-Flops and
the whole class of syncronizers ARE 'fair' in this sense. I was just
making the additional point that these ALL would fail in a VERY
SMALL number of close CASES (and that this number could never
be ZERO). [For reasons I don't think I could 'prove' in general]

A PIC port is 'fair' in the above sense if we read it IN PARALLEL
as fast as possible ( or actually at any speed) and, when it's (e.g.)
NON-zero we then sort out the (hopefully one) winnner. A 'tie' is
of course possible, and we can calculate it's probability, in much
the way we could with any realizable (unbiased) synchronizer
arrangement. BUT it would be a "fair" tie.

<Possibly Wagner meant this 'parallel latching' in his J-K Flop scheme
in which case I retract my comment on that>

Price or size or power (or color) is another issue.

R. Martin

1999\07\16@202821 by Sean H. Breheny

face picon face
I haven't thought this one all the way through, and it certainly wouldn't
be cheap,but if you want a theoretical system with no "designed-in"
unfairness,why wouldn't this work:

Have a central clock generator which feeds a clock to each person's button
box,using lengths of cable with exactly the same velocity factor and
length. Each box has a circuit in it which counts the clock ticks received
from the clock,until the button is pressed. Then after a period of time,
when the system could be sure that at least one button was pressed (you
could use one of the already mentioned "unfair" systems to determine
this),the current clock tick values are read out of each box,and whichever
has the smallest number of ticks was the person who pressed the button first.

If you find that you are sometimes getting "simultaneous" button pushes,
then just increase the clock rate. I don't think there is any way this
system can get into a metastable state.

Again,it is way overkill for a human-operated button system,but I am just
trying to offer a possible solution,because I don't see why this problem
should be theoretically un-solvable.

Sean


At 05:41 PM 7/16/99 -0400, you wrote:
>> R. Martin wrote:
>>
>> > I didn't totaly follow the argument at the time it was of the nature
>> > of a law of physics or mathemetics (or death and taxes). It was
>> > calculated that the memory systems would lock up about once every
>> > ten years. Nobody confirmed this experimentaly.

|
| Sean Breheny
| Amateur Radio Callsign: KA3YXM
| Electrical Engineering Student
\--------------=----------------
Save lives, please look at http://www.all.org
Personal page: http://www.people.cornell.edu/pages/shb7
RemoveMEshb7TakeThisOuTspamcornell.edu ICQ #: 3329174
________________________________________________________
NetZero - We believe in a FREE Internet.  Shouldn't you?
Get your FREE Internet Access and Email at
http://www.netzero.net/download/index.html

1999\07\16@210423 by Wagner Lipnharski

picon face
TC74HCT00AP at NetBuy is only $0.10 each for 278 units... you are not
building just one device, are you?  :)

Greg Brault wrote:
> Wagner,
> I see your point.  It would be slightly more than a dollar, but hey,
> cheap at that.

1999\07\16@213352 by Richard Martin

picon face
"Sean H. Breheny" wrote:
<snip>
Again,it is way overkill for a human-operated button system,but I am just

> trying to offer a possible solution,because I don't see why this problem
> should be theoretically un-solvable.
>
> Sean
> >> R. Martin wrote:
> >>
> >> > I didn't totaly follow the argument at the time it was of the nature
> >> > of a law of physics or mathemetics (or death and taxes). It was

It may be that "classically" any realizable attempt to resolve
actual simultanaiety leads in some cases to metastable results.
But quantum mechanics 'rolls the dice' giving an unambiguous
(if unpredictable) result. Maybe THATS why we got such a
strange theory?. (Still doesn't make me feel at home with it!)

R.Martin

Now I think we have gone TOTALY [OT]!

1999\07\16@222824 by Wagner Lipnharski

picon face
Richard Martin wrote:
{Quote hidden}

Ok, now, everyone agree with me, when I started (months ago) a topic
(and a long thread) about MDP (multi dimension processors), where there
is not time involved (as we know it), and it could solve zillions of
parameters at once (not simultaneous, because it would imply time).  LOL
:)

We also need to remember that an even condition (draw) is always
considered when the actual technology can not identify (or go further
into the analysis) the real winner, or the faster one.  We can identify
this "actual technology" as something you can buy without selling your
eyes for it, lets say, up to $20 :), so according to my point of view,
this is the money you need to consider to think about what chips would
you use to design the *best* Quiz Master identification system.

Up to now, everything we suggested fits inside this price range, just a
matter to shake, stir, cook and come up with a solution.  If looking for
a cheap solution, the PIC unit is not the most recommended, just few
gates could do it (all the pic job) much cheaper with a more confident
time resolution. But if the PIC is imperative... I sincerely would not
trust a sacrificied 5 cents external solution in favor to have an
expensive PIC involved.

MDP's would do it easily. :)

Wagner

1999\07\16@223527 by Greg Brault

picon face
Actually yes, I am only building a few of these.

Wagner Lipnharski wrote:
>
> TC74HCT00AP at NetBuy is only $0.10 each for 278 units... you are not
> building just one device, are you?  :)
>
> Greg Brault wrote:
> > Wagner,
> > I see your point.  It would be slightly more than a dollar, but hey,
> > cheap at that.

1999\07\16@230923 by Donald Riedinger

picon face
Greg Brault wrote:

> again, i fooled around with dualling each i/o pin as input and output.
> i also ran into probs thinking about what would happen if the same
> player hit their switch again, while the pin was set as output.  at
> least with my couple designs i tried to come up with, i couldn't get > > one t
hat wouldn't short something out

Greg,

You could put a 270 ohm resistor in series with each contestant switch
to limit current in case a PIC I/O pin was incorrectly high while the
program was running.  With a similar value resistor for the current
limiting for the LED, the 2 volts of drop across the LED will still give
you a low input into the PIC when the switch is pressed.

But why? If the program never makes an output high there is no problem.
You are either grounding an input or grounding a low output pin.

If the program tells a pin to go high and the switch burns out an
output  you need to throw the OTP part away, fix the program and program
another chip anyway.

Yea, for development purposes you would want to stick a scope or at
least a meter on any pin before you ground it or limit current.

Also you might look at the Motorola MC14490 Motorola Hex Contact Boune
Eliminator CMOS chip in their data book for information on switch bounce
and dealing with it.

For reference:

Connect momentary N/O switches to ground the I/O pins and LED cathodes
when pressed.

Your program sets all 10 pins as inputs then continuously scans them
looking for a low input.  You'd probably need 100k pull-ups on the I/O
pins.

When a switch is pressed, it lights the corresponding LED through the
switch.

(The LED anode is connected to power(+5v) and the switch grounds the LED
cathode through a resistor and the PIC input at the same time)

The PIC sees that input is low and then jumps to a routine to make that
input an output and then make it low until reset.  The LED for the first
contestant will stay on after the switch is released and no other LED
can light.

Again, the problem is swiches bouncing (causing square waves) when
closing or opening and a contestant pushing a switch when the PIC is
scanning at the other end of the 10 switches.

I'll bet the above would work just fine.

Build one and test it.  Good luck.

Don

1999\07\17@003154 by Mark Willis

flavicon
face
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

Greg Brault wrote:
{Quote hidden}

1999\07\17@122508 by Donald Riedinger

picon face
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

1999\07\18@074815 by paulb

flavicon
face
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.

1999\07\18@152424 by Donald Riedinger

picon face
Paul B. Webster wrote:

> 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".

Paul,

In what I was talking about, Pressing a button with a diode in series
would short a high output through the diode and switch to ground.  I'm
saying just don't instruct any pin to go high when it is an outputs
(living dangerously is OK if you are careful). -- if there is a
justification like lower parts count.

You could drive buffers connected to LED's off the PIC's I/O pins
instead of directly to LED's.  You need pull-ups in the input mode
anyway. Input mode = high, Output mode, low out = a low.  You'd need
stiffer pull-ups than 100k to get the switches to work right with out
the LED current.  Then you could disable the loser LED's after a winner.

Or you could connect a 4 to 16 decoder to the I/O pins with one I/O pin
to enable.  It doesn't matter what you do with the I/O pins after you
detect "Who is the first".  Except making them high unless you
disconnect the common ground to the switches.

Paul B. Webster wrote:

> 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.

Paul,

You're right,  I was thinking too much about hardware.  I was thinking
of looking at each I/O pin or bit of the port word, in sequence.  Now I
remember Microchip had an app note like this. But I can't find it.

What about reading port B to see if it has changed from FFh (no buttons
pressed).  Then read port A to see if bit zero and bit one are still set
then loop back to port B (alternating between ports).  If a low (pressed
button) is detected the program samples n times more.  If the values for
port B and Port A are the same during the time from a button press being
detected to the end of the n samples after that, there is one clear
winner.

But what if more than one button is pressed during the n sample (tie
breaker) time?  With 10 samples after button press detected: Port B =
FFh 3 times, FEh 4 times, EFh 2 times, EEh 1 time and port A =  03h 8
times, 02h 2 times.

Are we all agreed that you need to sample a mechanical switch for at
least 20 ms to see if it has actually settled to a different state after
bouncing?  Debouncing each switch before the PIC with hardware (cross
coupled gates, S-R flip flops, etc.) would be good but add parts and
without close tolerances give an advantage to some contestant(s).
Optical switches like opto interupters (cheaper than medium cost push
buttons) from 5 1/4 FDD write protect sensors would be nice and also
reliable.  Or maybe Greg would like it to be like selecting dueling
pistols.

I'm trying to think of an efficient way to increment a register for each
low per sample for each contestant.  Count hits.  Count continuous
button pressed time.  Probably with fsr.  An algorithm to increment each
of 10 contestant registers that have a low input bit at that time,
derived from the port value that was just read.

At the optimum sampling rate for the tie detection after the first byte
detected with a low bit (button pressed) I think your are going to see
to see alternating highs and lows then solid low as the switch stops
bouncing and settles to the closed (button pressed) state.  If the
sampling rate is too fast and/or too short, you will just see a few
scattered bits for the contestants in question about a tie.  If the
sampling rate is too slow and/or late you'll see the contestants in
question both low for the entire sampling period.  Like aliasing with a
scope.

1999\07\18@175025 by paulb

flavicon
face
*Partial* reply for now.  Work beckons!

Donald Riedinger wrote:

> Are we all agreed that you need to sample a mechanical switch for at
> least 20 ms to see if it has actually settled to a different state
> after bouncing?

 No.  In *this* application, debouncing is neither necessary nor in any
way desirable.  If any switch closure is detected at any time, it *has*
been pressed; it was not an accident.

 My thesis was that if it is impossible to be sure whether two switches
were pressed at once and/ or which was first, then it is probably
"fairer" to simply accept a delay *of the order of* 50 µs in the
determination (this being well within the mechanical variances of the
switch design, let alone the human interface) and use a tie-breaking
algorithm that is *scrupulously* equitable.  My suggestions as made,
follow accordingly, and I think already cover most of your comments.
--
 Cheers,
       Paul B.

1999\07\18@175644 by paulb

flavicon
face
I thought I'd better re-post my circuit by way of reference.

 OK, let's use efficient LEDs so that 20mA for half the time will
suffice to light each LED.  (This comment presupposed lighting one LED
in each of two banks.)  You won't need transistors.

          LED in row 1              Set Port B pullups ON.  To light
      +---|<|-------+             the LED in row 0, Set PA0 high,
      |  Si  P/B    |             PA1 tri-state (hint, use TRIS
      +-|>|--o/o----+             instruction, not bank select).
____   |   LED in row|0            Clear PORTB and set a mask using
PBx|--+---|<|-----+ |             TRIS PORTB with the only zero in
   |  |  Si  P/B  | |             the bit corresponding to the LED
   |  +-|>|--o/o--+ |             to be lit.
   |  180 ohm     | |
PA0|--VVVVV-------+-u--o Other      After 8ms, set up the LED in
   |  180 ohm       |      row 0  row 1 in the same fashion (leave a
PA1|--VVVVV---------+--o Other    "1" in both bits 0 and 1 of port A.
   |                       row 1  
____|                                To read the row 0 switches, TRIS
                                   PORTB to $FF (inputs), set both
bits 0 and 1 of PORTA to "0", TRIS PORTA bits 1,0 to "10" and read
PORTB which will contain a "0" corresponding to any switch closed.
Read row 1 switches with  "01" in TRIS PORTA bits 1,0.

 The cycle of lighting the row 0 LED for 8ms, lighting the row 1 LED
for 8ms, reading row 0 for about 5µs (i.e., insert a few NOPs between
setting up the ports and reading PORTB) and reading row 1 for 5µs will
both multiplex the LEDs and give you a basis for de-bouncing the push-
buttons.

 (The instructions for the Quiz game application, of course, vary!)
--
 Cheers,
       Paul B.

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...