Using the TI LaunchPad from your KoP

[ayeckley]

Update:

We've verified that the FANUC pulse generator will work tolerably well using a 3.3VDC supply, although the output pulse train may be cutting it a bit close to the LVTTL threshold for input logic "high". More on that later.

We've succeeded in modifying the default LaunchPad-FRC software and inserting our encoder data into the HID data stream to the DS (and on to the robot). We discovered that the Read Joystick.vi automatically scales the button array size to the number of button bits received, which is a pleasant surprise since we were expecting to have to create a custom VI to do that for us. We're using the upper 16 bits of the button datatype for encoder values (allowing us to make 120+ full knob rotations in either direction before overflow occurs), and keeping the bottom 16 for actual button inputs or LED (etc.) outputs. We simply split the Button array output from the Read Joystick.vi in half and treat those upper bits as a signed 16-bit integer.

What we're currently having challenges with is "missing" ticks. The way things are implemented right now, we're not detecting about 30% of the encoder ticks that we are providing. It does seem to be rate-sensitive (proportionally more ticks are lost the faster the knob is turned). We've determined that the likely cause is due to use of a polled-input approach. The default code for the Launchpad-FRC polls at 10ms, but at a realistic knob-turning rate the rising edges of the ticks from Phase A can occur at ~5ms apart. Anyone see a problem there? By switching to an interrupt-based approach and a reasonably tightly-coded ISR we expect to resolve the issue [hopefully] without screwing up the interrupts used in the serial communications process. We considered simply increasing the speed of the polling loop, but since that would require a 4X increase in the rate we decided that the risk of unintended side-effects (such as screwing up the settling times of the ADC inputs) makes that a less-attractive option (for now). Who knows, we may just jack up the polling rate and see what happens; it's easy enough to undo.

Although the waveform is still a nicely shaped pulse train when using 3.3V to power the pulse generator, the output logic "high" from the pulse generator can be as low as 2V under some conditions, which is right on the hairy edge of the EIA-published standard for input logic high (don't have the MSP430 datasheet handy to see if it differs from the standard or not). We may need to add some circuitry to bring logic high closer to the power supply rail. Once we switch to the interrupt-based approach we should know if this will be important enough to worry about or not.

Thanks to anyone following along...