Race timer, 8 channel switch bank ~1kHz sampling

The logic for debounce could be

Detect switch closure, store time Detect first switch release Suppress any detection for (some suitable time, say 0.1 seconds). This will correctly record the time of the event, while not producing spurious events.

With almost any switch there will be the possibility of bounce, so you're better dealing with it, rather than looking for switches in which it doesn't occur.

I don't know the details of the rPi input hardware, but in the general case, you could connect a switch to each pin of an 8-bit input. As an interrupt arrives, caused by a switch closure, disable interrupts for that bit of the input. In an idle routine, re-enable the interrupt after a time period.

Why do you need to debounce the switches? Poll them as fast as possible, and the first time a switch registers as pressed is what counts. It the same switch then bounces off and on again a few more times, what do you care? It's the first impression that counts. :)

If it's a matter of detecting manually operated switch actions, an effective way of debouncing would be to use change-over switches with the centre pole feeding into a schmidt trigger input gate with its (non-invering) output fed back to the input with the side contacts fed from the Vdd and Vss rails.

Yes, there'll be a brief 'short circuit' current spike on the gate's output pin at each transition, but for switch pulses limited to manual repetition rates, this will not be a problem.

And what else will the RasPi do while it polling as fast as it can ?

Polling is so 8051 !

A 1 mSec interrupt will give you the resolution you want, and the Pi can continue working as usual.

hamilton

the software way to debounce is to have a bot of code that says 'if high, set timer, set output=high

while (timer--)

; if low set output=slow low, set timer... while (timer--)

That way the FIRST transition of state sets or reset the output, and the output is then locked down in that state for a period - about 0.1 seconds is fine.

That way the system responds rapidly to state changes time wise, but is prevented from doing more than say 10 a second.

You CAN do something similar with a mixed analog/digital circuit, but its easier to write code.

indeed.

so your ISR would be:

if (pin_state !=pin_stored_state) if (pin_counter==0) { pin_stored_state=pin_state; pin_change_time=timer; pin_counter=100; } if (pin_counter>0) pin_counter--;

timer++;

You can use an "ISR" type approach for the 8 switches on the Pi. it's capable of routing about 66K interrupts/sec into a user-land C program, so there's plenty of scope.

Reading the time to the nearest microsecond takes under 1µS, so assuming there was some 9th trigger to start the clock, you can easilly achieve the timings you want, although there is a small chance your ISR will be delayed in waking up due to Linux doing other things (and the DRAM/Video refresh going on which you can't stop), but you can reduce this by making sure the Pi isn't busy with anything else - turn off all logging (un-install rsyslog, etc.) and so on to make sure there is no SD card activity. If you can make a Pi control a UAV in real-time, then it can easilly time races, etc.

If you're just interested in the first contact, then you simply ignore interrupts for the next 20mS on that channel. photocells typically won't have bounce, but mechanical switches will - if its something like swimming lanes or a racetrack end sensor, then it's effectively a one-shot anyway, and you won't care about bounces until the system is reset for the next race.

Or you could poll all 8 inputs at once and trigger when one is non-zero (or non 255 depending on the way you wire it up)

wiringPi has all the stuff you need for this if you're programming in C under Linux. It's a fairly trivial scenario.

Gordon (wiringPi author)

Thanks all! I can make progress from here.

On Tue, 28 Jan 2014 13:58:18 +0100, "A. Dumas" declaimed the following:

If this is for some sort of finish line "winner" detection (pinewood derby cars?), is debouncing really needed. Debouncing is normally used to avoid recording multiple triggers of a switch. For a finish line, I'd presume all the switches were in a stable open state, so just detecting a closure would indicate something had crossed that point. Ignore any subsequent bounce triggers until a manual reset is performed.

For first/second/third... something that timestamps the first 8-bit value, then sets a mask to exclude that bit from subsequent tests, timestamp next value, repeat as needed.