I put the punchline in the title, so let me provide some justification and explanation. One of the things that initially excited me about the prospect of using the Launchpad was the presence of support on Linux. While not officially supported by TI, there is a project to add the msp430 family as a target for cross-platform gcc compilation. As an unsupported endeavor though, there exist some hiccups, both in compilation and communication with the launchpad under Linux.
On the surface, everything looks like it should be straight forward. Hack a Day has an article getting people started and while there is a bunch of compiling tools from scratch, the process is easy enough to follow. All the samples work as expected, but then you start coding and discover that nothing is so simple. I immediately noticed that the target processor you’re compiling for doesn’t match the chips included with the launchpad. Turns out that one of the limitations of the mspgcc project is that it lacks headers and support for every chip in the msp430 line. The project is aware of this shortcoming, but the product line is too expansive for them to maintain with the current system. Fortunately the MSP430G2231 (the more powerful of the two chips included with the launchpad) is functionally equivalent to the MSP430F2031 which has headers available. Simply changing around the header file linked gets past this bump in the road.
Next hurdle, compiler differences. A lot of MSP430 sample code relies on ics (ti’s compiler) specific compiler declarations and macros which GCC doesn’t replicate or emulate. For instance, this pattern
pragma vector=PORT1_VECTOR __interrupt void PORT1_ISR(void)
is fairly common in the MSP430 literature and gcc doesn’t use the same syntax. Instead, you have to do something like
#include "signal.h" . . interrupt (PORT1_VECTOR) PORT1_ISR(void)
It is important to note that these definitions (for the most part) are not part of the language specifications, so it is not that case that gcc isn’t a fully compliant compiler. Rather, compilers are free to implement their own directives at will so it is just the case that these are un-agreed to changes that TI made.
The community understands these differences, but they aren’t well documented in any central place. Instead of finding this information on the Launchpad wiki, I tracked it down by extensive googling on a thread in a launchpad discussion group. I was also pointed towards a simple perl program (you have to scroll down) someone wrote to convert code between CCS (TI’s compiler) and mspgcc. Using what I learned from these sources, I was able to successfully load all the demos I found online.
So now we can compile code examples intended to be run under Windows by changing the target processor and rewriting code. I’m ok so far – as a Linux user I’m used to things being possible but not necessarily easy. These relatively trivial issues I take as the cost of my OS choice. What pushed me over the line to doing this experimentation on a Windows computer was the instability of the serial connection.
One thing I got used to working with the Arduino was the ability to easily dump information via serial using
Serial.write(str)
Particularly since at the moment most of my exploration is testing sensor configurations, being able to watch the collected data live helpe. Having that communication channel available is also how I’ve been handling logging. Until I have a data storage and transfer system implemented, I’m reliant on having that communication channel. Which doesn’t work reliably on my linux system.
I’m not the first person to run into this issue, but have yet to find any sort of solution. I’ve found some posts that suggest flaky linux drivers or potentially bugs in the demo program. I’ve tinkered with it a bit, but haven’t had any luck getting it working. As a result, I’ll be doing my development on windows until I figure out a solution.
Now I’ve gotten some frustrations out of the way, it is time for some actual progress, so stay tuned for fun with solenoid water valves.