AMagill

Why bother with the pull-up/pull-down resistors on the switches? You could drop them from your circuit and set:

P1OUT |= 0x08; // Pull P1.3 resistor high P1REN = 0x78; // Enable internal resistors for P1.3, P1.4, P1.5, P1.6

Copied from the November 2010 contest thread, so there's a separate space to discussion.
 
My project is a programmable strobe controller for high speed photography. A device like this is crucial for many types of high-speed photography, as it can orchestrate multiple sensors such as photogates and contact microphones with several outputs, such as a flash trigger and a camera's shutter release, so as to capture a photograph of just the exact right instant with microsecond precision.
An example; I connected my device to a small electronic water valve, to my camera's cable release port, and to a flash. I arranged it so water could flow down from a bottle, through the valve, out a small nozzle, and down into a bowl of water below whenever the valve is powered. Then I wrote a script to control the device;

while (true) { if (RIN0 == 1) { // Button 1: Double drip reg delay1 = 50; reg delay2 = 192; ROUT.T3 = 1; // Prime the camera waitms(10); // Setup time ROUT.T2 = 1; // Open valve waitms(15); // Wait for drop ROUT.T2 = 0; // Close valve waitms(delay1); // Put some space between drops ROUT.T2 = 1; // Open valve waitms(15); // Wait for drop ROUT.T2 = 0; // Close valve waitms(delay2); // Wait for drops to fall ROUT.R3 = 1; // Fire the camera waitms(63); // Wait for shutter to open ROUT.R1 = 1; // Fire flash waitms(10); ROUT = 0; // Finish flash pulse, close camera waitms(200); // Lockout } }
Once I got the timing just right, this script has the valve release exactly two drops of water such that the second will collide with the splash from the first, and take a picture of the result. It produces pictures like this, each and every time I press a button on the device;

 
Here's the device itself. I call it Strobr.

That's an MSP430F2274 in the center, driven by a 16MHz clock crystal (to keep timing more precise and repeatable). On the top left are two analog input ports, each with one input pin and a software-switchable power pin (because some sensors, like photogates, need power to work). In addition to being polled by the MSP430's ADC, it can also route them through the MSP430F2274's built-in op-amps for small signals like microphones. Top middle are a pair of buttons, just two more inputs available to the chip. Top right are a pair of ports that can be connected to each other via a pair of solid-state relays, of course software controlled as well. The idea behind adding these was to be able to switch on and off an audio signal to a speaker, for making sound sculptures. Haven't tried it yet. On the bottom right are four output jacks, each with a pair of digital output pins. Finally, on the left there's a FTDI FT232RL USB-to-serial converter, and under the power switch, you can just barely make out a USB port on the bottom side of the board.
The device connects to my computer by USB. The PC application I've written allows you two write simple scripts for the device, error-check and compile those scripts, load the compiled bytecode onto the device, and poll the device's status and display it in realtime. It looks like this;

The MSP430, in addition to maintaining communication with the PC, runs a very simple virtual machine that executes the scripts that have been loaded onto it. The virtual machine is fixed instruction length (32 bits), and has no stack or memory of any kind except for 16 general-purpose registers and 16 specialized registers. In the screenshot of the PC application, you can see the bytecode that the script is compiled into, as well as the registers that the virtual machine operates on. Those registers are; RIN0 (buttons input), RIN1(analog input 1), RIN2 (analog input 2), RD1 and RD2 (analog input deltas, change since last sample), RLED (the ring of LEDs), ROUT (the eight digital outputs), RPWR (power to the input ports and to the relays), RAIM (analog input mode- no amps, one amp on each port, daisy-chained amps on one port, etc.), RG1 and RG2 (amplifier gain setting), RAP (automatically poll state to the host), RFLG (flags- running, test truth), and RPC (program counter).
 
Schematic (click for full size):

 
PCB layout (clicky clicky):

 
And finally, for source code, you'll have to go to my web site, since the file is too big to attach to this post. It includes Eagle files for the schematic and PCB layout (including a detailed bill of materials totaling about $100), CAM files for the PCB (in case you want to get one made and don't care to muck about with Eagle), source code for the MSP430 and for the PC application, and even a few scripts to run on the whole contraption. If you do decide to make one of these, though, you should note that my design isn't perfect, and you would do well to double-check my work and address a number of issues first.
 
My web site, where I have writeups for this project and others, is OminousHum.com.

My project is a programmable strobe controller for high speed photography. A device like this is crucial for many types of high-speed photography, as it can orchestrate multiple sensors such as photogates and contact microphones with several outputs, such as a flash trigger and a camera's shutter release, so as to capture a photograph of just the exact right instant with microsecond precision.
An example; I connected my device to a small electronic water valve, to my camera's cable release port, and to a flash. I arranged it so water could flow down from a bottle, through the valve, out a small nozzle, and down into a bowl of water below whenever the valve is powered. Then I wrote a script to control the device;

while (true) { if (RIN0 == 1) { // Button 1: Double drip reg delay1 = 50; reg delay2 = 192; ROUT.T3 = 1; // Prime the camera waitms(10); // Setup time ROUT.T2 = 1; // Open valve waitms(15); // Wait for drop ROUT.T2 = 0; // Close valve waitms(delay1); // Put some space between drops ROUT.T2 = 1; // Open valve waitms(15); // Wait for drop ROUT.T2 = 0; // Close valve waitms(delay2); // Wait for drops to fall ROUT.R3 = 1; // Fire the camera waitms(63); // Wait for shutter to open ROUT.R1 = 1; // Fire flash waitms(10); ROUT = 0; // Finish flash pulse, close camera waitms(200); // Lockout } }
Once I got the timing just right, this script has the valve release exactly two drops of water such that the second will collide with the splash from the first, and take a picture of the result. It produces pictures like this, each and every time I press a button on the device;

 
Here's the device itself. I call it Strobr.

That's an MSP430F2274 in the center, driven by a 16MHz clock crystal (to keep timing more precise and repeatable). On the top left are two analog input ports, each with one input pin and a software-switchable power pin (because some sensors, like photogates, need power to work). In addition to being polled by the MSP430's ADC, it can also route them through the MSP430F2274's built-in op-amps for small signals like microphones. Top middle are a pair of buttons, just two more inputs available to the chip. Top right are a pair of ports that can be connected to each other via a pair of solid-state relays, of course software controlled as well. The idea behind adding these was to be able to switch on and off an audio signal to a speaker, for making sound sculptures. Haven't tried it yet. On the bottom right are four output jacks, each with a pair of digital output pins. Finally, on the left there's a FTDI FT232RL USB-to-serial converter, and under the power switch, you can just barely make out a USB port on the bottom side of the board.
The device connects to my computer by USB. The PC application I've written allows you two write simple scripts for the device, error-check and compile those scripts, load the compiled bytecode onto the device, and poll the device's status and display it in realtime. It looks like this;

The MSP430, in addition to maintaining communication with the PC, runs a very simple virtual machine that executes the scripts that have been loaded onto it. The virtual machine is fixed instruction length (32 bits), and has no stack or memory of any kind except for 16 general-purpose registers and 16 specialized registers. In the screenshot of the PC application, you can see the bytecode that the script is compiled into, as well as the registers that the virtual machine operates on. Those registers are; RIN0 (buttons input), RIN1(analog input 1), RIN2 (analog input 2), RD1 and RD2 (analog input deltas, change since last sample), RLED (the ring of LEDs), ROUT (the eight digital outputs), RPWR (power to the input ports and to the relays), RAIM (analog input mode- no amps, one amp on each port, daisy-chained amps on one port, etc.), RG1 and RG2 (amplifier gain setting), RAP (automatically poll state to the host), RFLG (flags- running, test truth), and RPC (program counter).
 
Schematic (click for full size):

 
PCB layout (clicky clicky):

 
And finally, for source code, you'll have to go to my web site, since the file is too big to attach to this post. It includes Eagle files for the schematic and PCB layout (including a detailed bill of materials totaling about $100), CAM files for the PCB (in case you want to get one made and don't care to muck about with Eagle), source code for the MSP430 and for the PC application, and even a few scripts to run on the whole contraption. If you do decide to make one of these, though, you should note that my design isn't perfect, and you would do well to double-check my work and address a number of issues first.
 
My web site, where I have writeups for this project and others, is OminousHum.com.

My project is a programmable strobe controller for high speed photography. A device like this is crucial for many types of high-speed photography, as it can orchestrate multiple sensors such as photogates and contact microphones with several outputs, such as a flash trigger and a camera's shutter release, so as to capture a photograph of just the exact right instant with microsecond precision.
An example; I connected my device to a small electronic water valve, to my camera's cable release port, and to a flash. I arranged it so water could flow down from a bottle, through the valve, out a small nozzle, and down into a bowl of water below whenever the valve is powered. Then I wrote a script to control the device;

while (true) { if (RIN0 == 1) { // Button 1: Double drip reg delay1 = 50; reg delay2 = 192; ROUT.T3 = 1; // Prime the camera waitms(10); // Setup time ROUT.T2 = 1; // Open valve waitms(15); // Wait for drop ROUT.T2 = 0; // Close valve waitms(delay1); // Put some space between drops ROUT.T2 = 1; // Open valve waitms(15); // Wait for drop ROUT.T2 = 0; // Close valve waitms(delay2); // Wait for drops to fall ROUT.R3 = 1; // Fire the camera waitms(63); // Wait for shutter to open ROUT.R1 = 1; // Fire flash waitms(10); ROUT = 0; // Finish flash pulse, close camera waitms(200); // Lockout } }
Once I got the timing just right, this script has the valve release exactly two drops of water such that the second will collide with the splash from the first, and take a picture of the result. It produces pictures like this, each and every time I press a button on the device;

 
Here's the device itself. I call it Strobr.

That's an MSP430F2274 in the center, driven by a 16MHz clock crystal (to keep timing more precise and repeatable). On the top left are two analog input ports, each with one input pin and a software-switchable power pin (because some sensors, like photogates, need power to work). In addition to being polled by the MSP430's ADC, it can also route them through the MSP430F2274's built-in op-amps for small signals like microphones. Top middle are a pair of buttons, just two more inputs available to the chip. Top right are a pair of ports that can be connected to each other via a pair of solid-state relays, of course software controlled as well. The idea behind adding these was to be able to switch on and off an audio signal to a speaker, for making sound sculptures. Haven't tried it yet. On the bottom right are four output jacks, each with a pair of digital output pins. Finally, on the left there's a FTDI FT232RL USB-to-serial converter, and under the power switch, you can just barely make out a USB port on the bottom side of the board.
The device connects to my computer by USB. The PC application I've written allows you two write simple scripts for the device, error-check and compile those scripts, load the compiled bytecode onto the device, and poll the device's status and display it in realtime. It looks like this;

The MSP430, in addition to maintaining communication with the PC, runs a very simple virtual machine that executes the scripts that have been loaded onto it. The virtual machine is fixed instruction length (32 bits), and has no stack or memory of any kind except for 16 general-purpose registers and 16 specialized registers. In the screenshot of the PC application, you can see the bytecode that the script is compiled into, as well as the registers that the virtual machine operates on. Those registers are; RIN0 (buttons input), RIN1(analog input 1), RIN2 (analog input 2), RD1 and RD2 (analog input deltas, change since last sample), RLED (the ring of LEDs), ROUT (the eight digital outputs), RPWR (power to the input ports and to the relays), RAIM (analog input mode- no amps, one amp on each port, daisy-chained amps on one port, etc.), RG1 and RG2 (amplifier gain setting), RAP (automatically poll state to the host), RFLG (flags- running, test truth), and RPC (program counter).
 
Schematic (click for full size):

 
PCB layout (clicky clicky):

 
And finally, for source code, you'll have to go to my web site, since the file is too big to attach to this post. It includes Eagle files for the schematic and PCB layout (including a detailed bill of materials totaling about $100), CAM files for the PCB (in case you want to get one made and don't care to muck about with Eagle), source code for the MSP430 and for the PC application, and even a few scripts to run on the whole contraption. If you do decide to make one of these, though, you should note that my design isn't perfect, and you would do well to double-check my work and address a number of issues first.
 
My web site, where I have writeups for this project and others, is OminousHum.com.