OK - I tested input on my throttle panel! Apart from the afore-mentioned issue with the pull up resistors, it works fine. There are a few (like, 2) that I didn't wire with resistors, I think because I originally planned to build them in to the rotary switches, but no biggie.
None of these issues is insurmountable (I can just use a breakout to provide 5V to my switches). However, it's really tempting to start over rather than spend time hacking around them when I could just start over. I'm already excited to:
- Put everything on one board with surface mount connections.
- Use a button matrix with one I/O expander instead of 4 I/O expanders.
- Use rotary encoders!
It's a mistake to actually rebuild before I've tested everything, but there's no harm in thinking about it and planning.
Planning for Encoders
Today I'm thinking about rotary encoders. These are rotary switches that can be rotated indefinitely. They output to two pins that turn off and on in a stepped pattern such that, if you read constantly, you can tell which way they are being rotated (other people have written about this better than I). They would be so much nicer for the time warp switches and the camera zoom. But there is little consensus about how to configure multiple encoders. I'd need three, so the gold standard method of using interrupts is out. Some sources suggest that, if they are hand operated and don't go too fast, it will be fine to wire the outputs to a button matrix. A more foolproof (but more expensive) way is to purchase a couple of i2c encoder daughter boards for about $20.
How can we tell if we'd be ok polling? First, we need to know how often we need to poll to reliably capture hand rotated encoder signals. There's a lot of "it worked for me" and "I would never try that", but little data, so let's do some testing.
I'm using PaulStroffregen's Encoder library. The github page includes some example sketches that are perfect for what I'm trying to do. First, I loaded up the 'Basic.pde' sketch just to see what things worked like with interrupts (the 'right' way). Then I loaded up 'NoInterrupts'. These two work pretty much the same if there is nothing going on. Output should look like this:
Basic NoInterrupts Test: 0 1 2 3 4 5 6 7 8
As you turn the encoder, each detent corresponds to an increase (or decrease) of four. Sometimes you the detent won't quite 'land' and you get stuck in between, but it will settle to a multiple of four with a little movement (note to self: going to have to deal with this when we get to actual controls).
Next I uncommented the delay line in the NoInterrupts sketch and set it to 20ms, which is a pretty reasonable loop interval for the whole device. No dice at all - first off, even on small turns (one or two detents, a step can be missed (which would screw up some coding schemes). Large turns are completely lost - I can turn 10 detents and the counter only goes up by 9 or so (it should go up 40). So if you were using an encoder for something rather imprecise, that might be fine, but might end up crashing us in to the sun. So i2c controllers it is!