1.1 A student to student intro to ide programming and ccs4  (Page 2/2)

The code perspective and writing code

Code Composer supports assembly code, “classic” C, and C++. For this class we will focus on assembly code and standard C. Most of your coding will happen in the coding perspective, a view where the screen is dominated by a massive text editing window. Code Composer’s editor can be setup in a range from straight forward wyswig to auto-tabbing, auto-highlighting, and auto-completing. Again, explore the options (window→preferences) and find what works best for you and your lab partner.

Writing assembly:

To write assembly in Code Composer, you first need to create a new project following the steps above (be sure to select “ Empty Assembly-only Project ”!). Once you have your empty project, insert a new file (file → new → file). When you input the file name, be sure to give it an “ .asm ” extension. Now that you have your freshly created asm file, you can start writing code in the code window (the big blank white space in the middle of the screen). In assembly mode, code composer parses the column most left as labels, so any non-label code must be indented at least one tab (and conversely labels cannot be indented). You will learn more about the specific components required for a functional assembly file in your specific labs, but in general, you need five common lines. The first, “.cdecls C, LIST, “msp430g2231.h”” defines all of your programming constants (such as P1IN, WDTCTL, etc.). The second “.text” tells the assembler where your actual code begins. The label “RESET” goes at the start of your program so the hardware knows where to begin code execution after a power reset. At the end of your code, you need to leave the memory address of your reset label. To do this, use the command [.sect “.reset”] to tell the compiler you are in the reset section, and then [.word RESET]to place the address of the RESET label into memory.

Writing c:

Code composer really shines writing C and C++. Like in assembly, you will need to create a new project for your new program. This time leave “treat as an assembly-only project” unchecked. Now you will create a new “c source file” (file→ new → source file). When you input the file name this time, be sure to give it a “ .c ” extension. In c mode, you don’t have to worry about line spacing or tabbing for the functionality of the program, just your own sanity and code readability. To include the file you used in the .asm projects that defined all the hardware constants, put the line “ #include “msp430g2231.h” ” at the top of your code. You won’t have to worry about the reset vector or anything like that—the c compiler will take care of it all for you. The only thing actually required in your c program is the function “ void main() {… YOUR CODE… } ”. Other more advanced operations (like interrupts) require special c syntax, but you will cover that in the specific labs when it comes up.

Debug mode, stepping, breakpoints, and watches

Debug mode differentiates an IDE like CCS4 from simpler command line tools. For better or for worse, simply pressing the debug button magically translates your source code into a running program on your attached MSP430. You will notice that after the debugger finally starts up though, your code will not actually be running. This is because the debugger starts in step mode with the first line of your code highlighted. In other words, the hardware is waiting for you to let it execute that one line of code, so your slow human reflexes can process and verify what it can do in a fraction of a second. Stepping through your code one line at a time helps you find subtle errors and see exactly where a program goes off track. Yes, as you can imagine, simply stepping through a real world multi-thousand line program (or the larger programs you will write later in this course) is inefficient and unfeasible. Breakpoints allow you to tell the debugger to stop if/when the processor gets to a certain point in your code, letting you run quickly through the code you trust and only stop at certain problematic sections you want to look into more closely. You can set several breakpoints at once, and once the program has broken, you will be able to actively see all register and memory values and step through line by line just as if you had started step mode at your break point. Watches are a little bit more abstract and more useful for larger programs, but they allow you to set a watch on a particular variable (in c) or memory location/register (in asm) and only break the program when it tries to change that particular value. This can help you find where exactly where and when a value changes into an erroneous state.

Using a combination of breakpoints, watches, and careful stepping, you can pick apart any complicated program to hunt down errors and really understand what goes on during the program’s execution.