The switches, they are debounced!

Skip to first unread message

Warren Young

Dec 4, 2016, 3:52:46 AM12/4/16
to PiDP-8

If you've been running the stock version of the PiDP-8/I software or have been using software from my code repository but have backed out the incandescent lamp simulator patch, you may be wondering why I've been babbling on this list about switch contact bounce for the last week or so.

The reason is simple: the incandescent lamp simulation patch sped up the GPIO scanning loop by 60x, making it 60x more likely that the code would report a false contact closure to the core of the simulator, causing it to act on that false edge as well as the one(s) that inevitably followed as the contacts settled down.

Fixing the problem turned out to be relatively simple because the GPIO loop is off in its own thread, so it has the freedom to hold off on reporting switch contact changes until it is certain they've stopped bouncing.

This change is now in the trunk of the tree as well as integrated into the no-lamp-simulation branch. That latter is not immune from contact bounce problems, just 60x more resistant to it than the trunk.

I will be releasing new packages shortly.

Ian Schofield

Dec 4, 2016, 1:12:34 PM12/4/16
to PiDP-8
Dear Warren,

 Absolutely correct. This does need sorting out! Many thanks for this. I will re-sync with your files as there are some other minor changes to make. Specifically, the sampling of processor state information is not quite right.

Regards, Ian.

Warren Young

Dec 4, 2016, 11:05:23 PM12/4/16
to PiDP-8
On Sunday, December 4, 2016 at 11:12:34 AM UTC-7, Ian Schofield wrote:

there are some other minor changes to make. Specifically, the sampling of processor state information is not quite right.

If by that you mean you're going to dive back into the incandescent lamp simulator code, I'd like you to consider rewriting it so that it gets the desired LED status via the `ledstatus` bitfield like the normal version does, as this constitutes a kind of "API" to other modules.

I've written up my ideas on this here, along with two motivating cases for why doing this is a good idea.

If you do this, first thank you, I wasn't looking forward to doing it myself. :)

Second, if you can do it in a single checkin, go ahead and check it in on the trunk. Otherwise, please use a branch. Within a branch, you're free to break as many things as you'd like, so long as the tip of the branch is eventually mergeable back into the trunk without a lot of trauma. I'll stay out of the gpio and scp modules for the next week or so to avoid creating merge conflicts.

Warren Young

Dec 4, 2016, 11:11:36 PM12/4/16
to PiDP-8
Another thought: can we switch to hardware PWM for driving the LEDs? That may allow the feature to work even on single-core Pis.
Reply all
Reply to author
0 new messages