[DJBecker]

We are currently using a slot opto-interrupter to sense shaft rotation. The detector side is hooked directly up to an AVR pin with the internal pull-up (nominally 20K to 50K ohms) enabled -- no other input-side components were needed.

The signal disk is screwed to the front shaft of the motor. It's made of credit-card-like plastic that we rounded with a chisel after mounting. The "slot" is a round hole -- better than a notch to avoid snagging.

I didn't really expect it to work. We didn't characterize the device before using it, and the AVR's pull-ups are pretty loosely specified. But the scope showed a workable signal almost immediately. I think that we only needed a slight change of the LED drive resistor since it wasn't the same device I had tried on the breadboard.

The original plan was to paint a black-white pattern on the shaft coupler and use a reflective sensor rather than an interrupted slot. But this will do until we need the front shaft to drive the A/C compressor. (Note: Use white paint for reflection, since "silver" paint often absorbs IR light.)

Anyway, the point is that very little is needed for the RPM sensor. But you cannot add a feature like this later if you don't plan for it. You might have unused pins, but you can't use them if you do not have a way to get signals to the pins.

Our base controller board is the Mega 1280. It's great because it has a zillion I/O pins brought out on headers. But not quite all of them. We would like to use the analog comparator to trigger an interrupt on overcurrent, but that pin dead-ends. Only timer 4 and 5 have the count inputs and ICP pins brought out. And the clock output pin isn't available.

A little more about the the RPM measurements. We wired the opto-interrupter to a pin that is either general purpose I/O or the timer 5 capture pin. If we use the hardware timer, the implementation is surprisingly simple. The SIG_INPUT_CAPTURE5 handler just saves the hardware capture timestamp, puts the time since the last capture in a global variable, and clears the software-maintained overflow count. The TIMER5_OVF_vect handler increments the software overflow count, holding it at a saturated maximum so we don't lose track if the motor is turning too slowly (about 15RPM).

The slow part -- doing the division -- is only done when a function is called to requests the RPM. When we do that division we save the period and result so we don't have to needlessly recalculate.