To leave notes somewhere...
I use msp430 MCUs of Texas Instruments in my devices. My main chip is msp430fr5726 of a FRAM MCU family.
There are several instruments of developing firmware for msp430 MCUs under Linux-base operating systems. I'm interested in free instruments and so I tried:
Code Composer Studio (CCS)
Code::Blocks
but didn't try
Eclipse (I have enough of overhead with CCS - look ahead).
Coding
I like C::B (v.13.12) more then CCS (v.6). A lot of reasons, the main - C::B is lighter, simpler in creating projects, has less unnecessary windows and options. Still, C::B allows the usual list of project coding features.
Compiling
CCS allows options: proprietary TI compiler or MSPGCC. The former is just excellent, though limited to 16K of code in a free version. I compared the size of code generated by these two compilers, but cannot give exact data. TI compiler made somewhere 15% shorter code.
Moreover, MSPGCC had a very unpleasant bug that led to a total crush of a FRAM MCU. And though there is at least one workaround, yet I had to use either CCS with TI compiler or C::B under Windows. Till September 2014, when Red Hat & TI released their joint project.
The MSP430-GCC-OPEN-SOURCE has not that bug and it can be used for linking programs for FRAM MCUs.
So, we can use C::B under Linux now with Red Hat compiler. No mortal bugs, no limitations of code. Maybe it is less efficient then TI compiler, at least TI writes something about it - but I don't know exactly what is meant.
Programming the MCU
If you use MSP-FET or older (classic) MSP-FET430UIF programmer-debugger (both $115), you can program and debug from CCS without problems.
I don't know it exactly, I just hope. Because I use cheaper programmers: MSP-EXP430FR5739 Experimental Board ($35) and even MSP-EXP430G2 Value Line LaunchPad ($9.99). Both of these modules are upgraded and support FRAM MCU of msp430fr57xx family.
But the CCS wants MSP-FET for connecting to a msp430 MCU. So "we need a permanent solution to our problem", as a Caiaphas said almost 2000 years ago...
MSPDEBUG is certainly a solution. A simple command in terminal window
makes all the work. Of course, other programmers require other arguments.
This command may be called from C::B as a Tool (main menu). It can be invoked from CCS as well - External Tool.
But MSPDEBUG can do more. It can be used for debugging.
Debug
Disclaimer: I mean only hardware debugging here, when we can load the program, set breakpoints, step, run and examine MCU with JTAG or SBW.
Alas! So far I cannot debug my programs as well as I could in Atmel Studio. Here are my attempts and the results.
1) MSPDEBUG standalone. The program has relevant commands but to use them manually is very tedious.
All we can get from this program (except loading the program in MCU) - use it as proxy for a GDB. But GDB itself needs a GUI (well, I've read the example of GDB command line using, but it is just an example).
<here will be my routine of using MSPDEBUG + GDB in 2 terminals>
2) CCS, most obviously. It demands MSP-FET for debug. Wrong answer.
Or we can use GDB with MSPDEBUG - but "we" is not "me". I could not manage this combination.
3) C::B can debug too. The same tandem MSPDEBUG + GDB, I believe. And still, I cannot make it run.
4) DDD program. Cannot link a source program and GDB. So - no breakpoints, only run or stop...
So I decided to drop my attempts so far. To debug complex projects or not so complex but real-time projects in a step-by-step mode is not the best idea. Let it wait...
I use msp430 MCUs of Texas Instruments in my devices. My main chip is msp430fr5726 of a FRAM MCU family.
There are several instruments of developing firmware for msp430 MCUs under Linux-base operating systems. I'm interested in free instruments and so I tried:
Code Composer Studio (CCS)
Code::Blocks
but didn't try
Eclipse (I have enough of overhead with CCS - look ahead).
Coding
I like C::B (v.13.12) more then CCS (v.6). A lot of reasons, the main - C::B is lighter, simpler in creating projects, has less unnecessary windows and options. Still, C::B allows the usual list of project coding features.
Compiling
CCS allows options: proprietary TI compiler or MSPGCC. The former is just excellent, though limited to 16K of code in a free version. I compared the size of code generated by these two compilers, but cannot give exact data. TI compiler made somewhere 15% shorter code.
Moreover, MSPGCC had a very unpleasant bug that led to a total crush of a FRAM MCU. And though there is at least one workaround, yet I had to use either CCS with TI compiler or C::B under Windows. Till September 2014, when Red Hat & TI released their joint project.
The MSP430-GCC-OPEN-SOURCE has not that bug and it can be used for linking programs for FRAM MCUs.
So, we can use C::B under Linux now with Red Hat compiler. No mortal bugs, no limitations of code. Maybe it is less efficient then TI compiler, at least TI writes something about it - but I don't know exactly what is meant.
Programming the MCU
If you use MSP-FET or older (classic) MSP-FET430UIF programmer-debugger (both $115), you can program and debug from CCS without problems.
I don't know it exactly, I just hope. Because I use cheaper programmers: MSP-EXP430FR5739 Experimental Board ($35) and even MSP-EXP430G2 Value Line LaunchPad ($9.99). Both of these modules are upgraded and support FRAM MCU of msp430fr57xx family.
But the CCS wants MSP-FET for connecting to a msp430 MCU. So "we need a permanent solution to our problem", as a Caiaphas said almost 2000 years ago...
MSPDEBUG is certainly a solution. A simple command in terminal window
mspdebug -n rf2500 "prog <file>"
makes all the work. Of course, other programmers require other arguments.
This command may be called from C::B as a Tool (main menu). It can be invoked from CCS as well - External Tool.
But MSPDEBUG can do more. It can be used for debugging.
Debug
Disclaimer: I mean only hardware debugging here, when we can load the program, set breakpoints, step, run and examine MCU with JTAG or SBW.
Alas! So far I cannot debug my programs as well as I could in Atmel Studio. Here are my attempts and the results.
1) MSPDEBUG standalone. The program has relevant commands but to use them manually is very tedious.
All we can get from this program (except loading the program in MCU) - use it as proxy for a GDB. But GDB itself needs a GUI (well, I've read the example of GDB command line using, but it is just an example).
<here will be my routine of using MSPDEBUG + GDB in 2 terminals>
2) CCS, most obviously. It demands MSP-FET for debug. Wrong answer.
Or we can use GDB with MSPDEBUG - but "we" is not "me". I could not manage this combination.
3) C::B can debug too. The same tandem MSPDEBUG + GDB, I believe. And still, I cannot make it run.
4) DDD program. Cannot link a source program and GDB. So - no breakpoints, only run or stop...
So I decided to drop my attempts so far. To debug complex projects or not so complex but real-time projects in a step-by-step mode is not the best idea. Let it wait...
