Select the root of the project. Screen should look similar to:
Connect a TI Launchpad to your computer via USB.
On the ‘Run’ Menu, select ‘Debug’. (note: Hitting F11 on the keyboard performs the same function)
You may see a pop up window talking about ‘Low Power Modes’. It is okay to check ‘Do Not Display This Again’ and then ‘Proceed’.
CCS will now shift over to the ‘Debug Perspective’ and should look like this:
At this point, your code has been uploaded onto the Launchpad and code execution has commenced, but has been paused on the first line of the ‘main’ method. Press F8 to unpause.
Find the red square in the ‘Debug’ tab of the ‘Debug Perspective’ and click it. (It should be on the upper left of the CSS window.) This stops the debugger and releases the Launchpad board to operate without the need of the computer.
Since your code has been uploaded, you can unplug your Launchpad from your computer and use it wherever you plan to use it.
Code Composer Studio(CCS) is the Interactive Development Environment(IDE) you will need for creating and/or uploading software onto your TI board. While there are a few choices when it comes to IDEs, CCS is the ‘standardized’ IDE for the Launchpad For Model Railroaders (LP4MRR) initiative.
You will likely have to fill out a form explaining why you are worthy of downloading TI’s software. Don’t sweat it. Just fill out the info and make sure you don’t use CCS for commercial purposes (without paying TI their due, anyways).
Installing is a snap on windows and is just the same as installing nearly any other piece of software.
Last round of modifications to this project for a while. Rev 2 was pretty good, but the memory limitations of the MSP430G2553 chip posed a challenge: 512 bytes of ram! I was only able to get three flashing sequences plus the logic loops into that little memory. So another rework was needed.
Instead of using a byte broken down into 1bit/7bit status/time chunks, for Rev 3 I went with a hardcoded 50ms time chunk constant and used every bit in each byte as a status flag. Example: 00111100 would tell the logic loop that the first two 50ms steps are ‘OFF’, the next 4 steps are ‘ON’ and the last 2 are ‘OFF’. This allows me to compress 8 steps into one byte… an initial 8x memory efficiency increase.
The trade off to this is that counters like ‘CurrentStep’ are now moved out of the flashing sequence. Which, when you think about it, the notion of which step a sequence is on is not necessarily an attribute of the sequence itself, but rather a bookkeeping value by the logic loop. This increases memory usage however, stealing the thunder of my previous 8x decrease in memory use.
The overall effect is still a large reduction in memory use. Rev 3 ups the number of LEDs controlled from 8 to 11 (3 red, 3 blue, 2 yellow, 1 white takedown light, and 2 headlights.) as well as increasing the flashing sequences from 3 to 10 (Technically 15). The LEDs are also now grouped into 3 groups which allows for changing of the flash sequence on one group without interrupting the sequence of the other groups. Rev 2 had a ‘jitter’ problem when the sequences changed. Barely noticable, I think, but the power of my OCD compelled me to fix it.
The final feature enhancement is the concept of ‘Modes’. Currently, there are only two modes installed: Demo and Random. Demo will iterate through each sequence, spending about 8 seconds on each sequence. Random will pick a sequence at random and spend 2-6 seconds on that sequence. (Note: There is some room for improvement on the random chooser)
Anyways, code and how-to are posted below, so for now here’s a video of what Rev 3 can do:
Spend some time reworking the core code as well as the storage format for the flashing sequence. Turns out that I was spoiled working with the Arduino boards, which has significantly more memory. I am endeavoring to put multiple flashing sequences into one code binary and switch them with a pushbutton attached to a DI pin on the Launchpad. Installed an old copy of Adobe Premiere and started playing with that as well. Here’s the results: