I’ve been slowly chipping away at yet another additional side project. What’s that make, 18? 19? This one should have been prioritized higher, but I just never got around to it. Anyways, the whole aim of the LP4MRR community as envisioned by Terry Terrance was to put inexpensive, relatively easy to use, feature full electronics options into the hands of the average model railroader. Unfortunately, spread of the awesomeness that is the Launchpad has been somewhat slow due to the high learning curve of everything it takes to program and use a Launchpad.
A few months back, I asked myself the very dangerous question of: “So, what if….” More specifically, I asked, “So, what if I could find a way to get an average Joe Model Railroader the ability to upload a precompiled ‘sketch’ of code onto a Launchpad without Joe ever needing to use Code Composer Studio?”
There is so much left to experiment with concerning the Launchpads connectivity with JMRI that it’s mind boggling. One thing that has captivated quite a few of my brain cells recently is the notion of Virtual IO points.
The basic concept of IO points is relatively straightforward. A pin on the Launchpad is a single IO point. It’s either Input or Output. But the Launchpad is so much more powerful than just a bit setter or a bit reader! When thinking about such a waste of ‘power’ using the Launchpad as a 12 pin CMRI node, it hit me like a ton of bricks:
In my continuing research into CMRI Emulation on an MSP430G2553 chip, I recently tackled a few new challenges. Firstly, I wanted to expand the IO of the MSP430 via shift registers and control those pins from JMRI. Secondly, I wanted to address the issue of smoothly render a 16KHz PWM signal while simultaneously performing other tasks. To date, I have had success with PWM only when the MSP430 is performing just the PWM calcs and no other tasks. Previous attempts at using algorithm based PWM have resulted in jittery flashing on the LED being controlled by PWM while there are other items being processed by the MSP430.
The most recent sets of experiments have been a major success. Short video:
CMRI + 16KHz PWM Proof of Concept from claymore1977 on Vimeo.
No visual update for this post, but rather some tidbits of advice. When programming in C for the MSP430, I’ve been very tempted to treat Interrupts as more like Events from Object Oriented Languages. Knowing that there is only 1 ‘thread’ of processing and the Interrupt function is executed at any point during the main code execution, I never fully appreciated this until I started this CMRI project.
I quickly found out that interrupt processing seriously messes up real time operations like PWM. For instance, I was attempting to simulate the slow pulsing of the red lights on a Cell Phone tower on the same MSP430 that I was running the CMRI serial IO code on. Every time a POLL was received from the computer, the PWM used for the red light would ‘hiccup’. The time it took the Serial code to write the 8 bytes (64 bits) to the serial wire was just too much to keep the PWM animation smooth.
The solution came to me in the middle of the night (go figure) and I believe has applications in many other aspects of coding on the MSP430. Instead of using your interrupt handler to do the ‘work’, in my case a Serial SEND, use it to set a flag and perform that work in the main loop of your application. For my example, the Serial code processes one Byte at a type on the RECV, and when the POLL command is recieved in full, a ‘TRANSMIT_REQUESTED’ flag is set to true. Each pass in the main loop checks this flag and, when its set to true, begins to send the GET packet, one byte at a time. This way, the main loop can update the PWM once every byte that is SENT or RECVd, rather than having to wait till all 8 bytes are SENT. This results in a very smooth pulsating light, all the while serial IO is happening in the ‘background’.
More on this in coming days. Cheers!
I’ve been hacking away at getting the CMRI Emulation working on the Launchpad. When it comes to a standalone unit, it is currently working like a champ. Getting multiple Launchpads to talk on the same serial bus has been quite unsuccessful thus far. Next endeavor is to use Shift registers and ramp up the number of Inputs and Outputs off of a single Launchpad.
A single launchpad that handles massive amounts of IO via Shift Registers is not the most user friendly approach. I would prefer to either hookup multiple Launchpads via the USB ports on them, or use a single USB connection and have multiple Launchpads share the Serial bus. Both of those approaches are problematic at this time, and more research is needed. For now, I’m going to get the Shift Registers angle tackled.
Here’s a link to the CSS5 project.
And here’s a video:
CMRI Emulation on a Launchpad 430G2553 from claymore1977 on Vimeo.
TODO List for CMRI on Launchpad
- Test chaining multiple launchpads together, with different addresses, via Pins 1.1 and 1.2
- Increase Baud Rate higher than 9600
- Test multiple launchpads sharing the same address, but handling different ranges of IO bits.
- Clean up, consolidate and minify code.
- Experiment with using Shift registers to increase a single Launchpad’s capability from 12 IO pins.
- Determine which of the MSP430G2 chips can be used besides the ‘top of the line’ 2553
- Develop more advanced CMRI nodes other than simple On/Off command and sensing.