dukevimto

Halloween comes round, and I can't face all that orange goo everywhere.... so I went cardboard.
Rectangular things are easer. What about doing  a cube?

 
Oh, yes!
 
And, of course, it needs some good lights:
 

 
The 5mm round LEDs are RGB, the larger ones are high-brightness white. These are driven with a high pulse current to create the impression of lightning.
 
Code is here:
 
Video:

Halloween comes round, and I can't face all that orange goo everywhere.... so I went cardboard.
Rectangular things are easer. What about doing  a cube?

 
Oh, yes!
 
And, of course, it needs some good lights:
 

 
The 5mm round LEDs are RGB, the larger ones are high-brightness white. These are driven with a high pulse current to create the impression of lightning.
 
Code is here:
 
Video:

So you now build all of your projects on breadboard, and the Launchpad just gets used as a progammer/debugger adaptor. The 20 pin DIP socket gahters dust.
I have put this to use by writing a SPI-UART adaptor that runs on a 2553 in the DIP socket, while using the Launchpad to debug my project.
The project code can thus output console data using a bit-banged SPI output. This only consumes port pins, no timers or UARTS, and is not timing-critical, as the data output is synchronous.
 
This shows how you would use it:

 
... and here it is on my desk...
 

 
Code is at https://github.com/shufflebits/SPI-Adaptor-2553
 
The code incorporates a self-test mode, so you can check that the UART link is working correctly. Just put links on where I have blue links here:

 
This enables a test output on P1.4 and P1.6.
Set the COM port to 9600,n,8,1.
 
In normal operation, the red LED on P1.0 indicates when data is being received, and the green LEN on P1.6 indicates when the SPI input is reset.
To explain: Since with a synchronous link, a single missed clock pulse will screw up all data received in the future, the code resets the SPI receiver after a second of idle time. This idle time-out is shortened by pressing S2 (P1.3).
 
You may find it worth while to add a pull-down resistor on your target on the SPI clock out, as when it floats on reset you get spurious data.
 
Code for the bit-banged SPI output can be found in printf.c and printf.h. Edit printf.h to define which ports will be used for output. Props to opossum for the original printf code, which I'm sure has been copied by just about everybody!

So you now build all of your projects on breadboard, and the Launchpad just gets used as a progammer/debugger adaptor. The 20 pin DIP socket gahters dust.
I have put this to use by writing a SPI-UART adaptor that runs on a 2553 in the DIP socket, while using the Launchpad to debug my project.
The project code can thus output console data using a bit-banged SPI output. This only consumes port pins, no timers or UARTS, and is not timing-critical, as the data output is synchronous.
 
This shows how you would use it:

 
... and here it is on my desk...
 

 
Code is at https://github.com/shufflebits/SPI-Adaptor-2553
 
The code incorporates a self-test mode, so you can check that the UART link is working correctly. Just put links on where I have blue links here:

 
This enables a test output on P1.4 and P1.6.
Set the COM port to 9600,n,8,1.
 
In normal operation, the red LED on P1.0 indicates when data is being received, and the green LEN on P1.6 indicates when the SPI input is reset.
To explain: Since with a synchronous link, a single missed clock pulse will screw up all data received in the future, the code resets the SPI receiver after a second of idle time. This idle time-out is shortened by pressing S2 (P1.3).
 
You may find it worth while to add a pull-down resistor on your target on the SPI clock out, as when it floats on reset you get spurious data.
 
Code for the bit-banged SPI output can be found in printf.c and printf.h. Edit printf.h to define which ports will be used for output. Props to opossum for the original printf code, which I'm sure has been copied by just about everybody!