Jump to content
Sign in to follow this  
chicken

Code Composer Studio v6 now officially released

Recommended Posts

CCS6 provides a big improvement on integration with Energia.

 

It can open existing Energia sketches and create new projects based on the Energia framework. At the same time, CCS6 includes a debugger and powerful tools.

 

Unfortunately, it is available for Windows and Linux, but not for Mac OS X, although the underlying IDE, Eclipse, runs on the there OSes. So I keep using embedXcode for Xcode...

Share this post


Link to post
Share on other sites

FYI- Anyone looking to use the new msp430-elf-gcc, note that their msp430.h has an error in it:

 

C:\ti\ccsv6\ccs_base\msp430\include_gcc\msp430.h has a bunch of checks for crap like __MSP430XGENERIC__ that got stuck in the "middle" of the file, before a bunch of other F5xxx/F6xxx/FRxxx part#'s, not at the end where those sort of "last-ditch" checks should occur:

#elif defined (__MSP430F6659__)
#include "msp430f6659.h"

#elif defined (__MSP430L092__)
#include "msp430l092.h"

#elif defined (__MSP430C091__)
#include "msp430c091.h"

#elif defined (__MSP430C092__)
#include "msp430c092.h"

#elif defined (__MSP430XGENERIC__)
#include "msp430xgeneric.h"

#elif defined (__MSP430F5XX_6XXGENERIC__)
#include "msp430f5xx_6xxgeneric.h"

#elif defined (__MSP430FR5XX_6XXGENERIC__)
#include "msp430fr5xx_6xxgeneric.h"

#elif defined (__MSP430FR57XXGENERIC__)
#include "msp430fr57xxgeneric.h"

#elif defined (__MSP430F5131__)
#include "msp430f5131.h"

#elif defined (__MSP430F5151__)
#include "msp430f5151.h"

#elif defined (__MSP430F5171__)
#include "msp430f5171.h"

#elif defined (__MSP430F5132__)
#include "msp430f5132.h"

Comment those "generic" checks out, e.g.:

#elif defined (__MSP430F6659__)
#include "msp430f6659.h"

#elif defined (__MSP430L092__)
#include "msp430l092.h"

#elif defined (__MSP430C091__)
#include "msp430c091.h"

#elif defined (__MSP430C092__)
#include "msp430c092.h"

/*
#elif defined (__MSP430XGENERIC__)
#warning "Using __MSP430XGENERIC__"
#include "msp430xgeneric.h"

#elif defined (__MSP430F5XX_6XXGENERIC__)
#warning "Using __MSP430F5XX_6XXGENERIC__"
#include "msp430f5xx_6xxgeneric.h"

#elif defined (__MSP430FR5XX_6XXGENERIC__)
#warning "Using __MSP430FR5XX_6XXGENERIC__"
#include "msp430fr5xx_6xxgeneric.h"

#elif defined (__MSP430FR57XXGENERIC__)
#warning "Using __MSP430FR57XXGENERIC__"
#include "msp430fr57xxgeneric.h"
 */

#elif defined (__MSP430F5131__)
#include "msp430f5131.h"

#elif defined (__MSP430F5151__)
#include "msp430f5151.h"

#elif defined (__MSP430F5171__)
#include "msp430f5171.h"

#elif defined (__MSP430F5132__)
#include "msp430f5132.h"

The reason we see this is that by default, CCS's project generator uses "-mmcu=<ISA>" instead of the old "-mmcu=<MSP430 part#>", in the case of Wolverine, that's "-mmcu=msp430X".  So __MSP430XGENERIC__ gets implicitly #define'd by the compiler.  I believe that is the "new way" GCC is behaving going forward; no longer specifying the full part# in -mmcu but just the ISA/architecture.  Makes it easier for the GCC maintainers since they don't have to keep updating the codebase with new part#'s as TI produces them.

 

The CCS project generator correctly adds -D__MSP430FR5969__ so that msp430.h identifies the correct chip and includes the msp430fr5969.h file, but not if it catches #elif defined(__MSP430XGENERIC__) first.

 

I reported it on E2E as a bug, but if anyone is impatient to play until an update is provided just open your msp430.h and comment out that junk.

 

edit: or I can be a nice guy and include a fixed copy ;) msp430_h_fixed_ccsv6.zip

Share this post


Link to post
Share on other sites

FYI- Anyone looking to use the new msp430-elf-gcc, note that their msp430.h has an error in it:

Y'know, it actually hurts to see how msp430-elf-gcc is turning out under TI's supervision. It could have been so cool.

Share this post


Link to post
Share on other sites

Y'know, it actually hurts to see how msp430-elf-gcc is turning out under TI's supervision. It could have been so cool.

Meh, I'll chalk it up to a simple error... The beta releases didn't have this IIRC.  But yeah, clearly nobody tested Wolverine on it before release.

Share this post


Link to post
Share on other sites

FWIW, I don't think this actually enables Large Memory support either. Creating a section that lives in FAR_ROM (the memory ld script symbol for 0x10000+) and assigning a function to it results in a cryptic message like:

 

./ste2007.o: In function `ste2007_init':

ste2007.c:(.text.ste2007_init+0x4): relocation truncated to fit: R_MSP430X_ABS16 against symbol `ste2007_issuecmd' defined in .far_rom section in ./ste2007.o

collect2.exe: error: ld returned 1 exit status

gmake: *** [nokiahello.out] Error 1

gmake: Target `all' not remade because of errors.

 

I'll have to see tomorrow if this basic program works on the F5529, if so then at least it's a reasonable step in the future direction for free use of CCS on all the MSP430's.

 

EDIT: Quite mistaken, this GCC supports -mlarge.

Go into project's Properties > CCS Build > GNU Compiler > Miscellaneous, and add an "Other" flag as -mlarge.

 

Then looking at the ASM output, I see the "calla"'s and such.

 

And from msp430-elf-objdump -x, my "ste2007_issuecmd()" function lives at:

 

00010000 g .highmem 00000032 ste2007_issuecmd

 

0x10000 :-)

Share this post


Link to post
Share on other sites

Fwiw, I got an F5529 project going, even with one of the functions slammed up into FAR_ROM and working great.

Nokia 1202 LCD:

post-15991-0-62426000-1398913044_thumb.jpg

 

Also, I got IQmathLib working!

post-15991-0-01756300-1398913068_thumb.jpg

 

Accuracy kinda sucked there; I was adding 5.2 to the numbers, but was getting just short of that (.19, .39, etc)

 

Quick writeup on IQmathLib:

 

http://www.ti.com/tool/msp430-iqmathlib

 

After installing the IQmathLib software (C:\ti\msp430\IQMATHLIB_01_00_00_00 on my machine), the stuff you want to see is under libraries\CCS and include.

 

1. In your GCC project, under Properties > CCS Build > GNU Compiler > Directories, add "C:\ti\msp430\IQMATHLIB_01_00_00_00\include" to the include paths.

2. Link the appropriate .lib file into your project.  Note IQmathLib comes with some .lib files with the actual binaries, and a .a file which I believe contains some references to the .lib files.  GCC's linker choked on the .a archive, so I just linked the correct .lib for my particular chip architecture / data model (-mlarge so I picked large code large data).

 

To link in a library into a CCS project, I opened up the folder in a Windows explorer window, and drag & dropped the appropriate .lib file up onto the project name in the Project Explorer view in CCS, then with the dialog box that came up, "Linked" it into the project relative to PROJECT_LOC.

 

The libraries are organized under libraries\CCS as:

1xx

4xx

5xx_6xx_FRxx

G2xx

 

Naturally I selected my .lib file from the 5xx_6xx_FRxx folder, and chose IQmathLib_CCS_5xx_6xx_FRxx_MPY32_large_code_large_data.lib

 

Quick recap on what IQmathLib is:

It's a library of functions and datatypes that allow you to utilize floating point numbers using integer-only operations.  A "Q" datatype is a 16-bit signed integer packing in an integer and fractional portion of a number.   A "IQ" datatype is a 32-bit signed integer, likewise.  Obviously on the smaller chips, the "Q" datatype will go faster if you can spare the precision.

 

There are various forms of the datatypes, depending on how many bits you want available for the integer portion.  The IQmathLib User's Guide explains it all: http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/IQmathLib/latest/exports/MSP430-IQmathLib-01_00_00_00.pdf

There's a GLOBAL_Q or GLOBAL_IQ #define you should put in your code just before #include "IQmathLib.h" to define the precision of your _iq and _q datatypes.  I chose 22 for mine, which is -512 to +511.something, and I wanted to play with numbers from 0-360 (hue of a color wheel).  The canonical form of this is _iq22, and likewise the various functions can be referenced as _IQ22<funcname> instead of just _IQ<funcname>.

 

_iq and _q types can be added, subtracted or compared with native C primitives such as +, - and < > ==.  Since they are really just 32- and 16-bit signed integers respectively, that works fine.  Multiplication and division need support and for the chips that have an MPY, the library contains optimized functions to use those.  Likewise, conversion of datatypes involves some functions as you'll see in the user's guide.

 

For my Nokia 1202 LCD example, the relevant output code looks like this:

_iq hue = _IQ(0.0);
while(1) {
    __delay_cycles(25000000);
    lcd_printf("hue=%l.%l\n", _IQint(hue), _IQint(_IQmpyI32(_IQfrac(hue), 100L)));
    hue += _IQ(5.2);
    if (hue > _IQ(360.0))
        hue = _IQ(0.0);
}

The _IQint() function returns the integer portion of the number as a signed 32-bit integer, and _IQfrac returns the fractional portion as another _iq variable.  This is still a fraction, so doing _IQint(_IQfrac(iqnum)) would always return 0, but as you see above multiplying that fraction by some number e.g. 100 will turn a controlled portion of the fraction into an integer.  There are a variety of _IQmpy() functions, _IQmpyI32() multiplies an _iq by a 32-bit signed integer, likewise _IQmpy() takes two _iq arguments.

 

Up top, I have:

#define GLOBAL_IQ 22

#include "IQmathLib.h"

 

So all my _iq and _IQ* references are implicitly rewritten as _iq22 and _IQ22.  So my 'hue' variable is of type _iq22, and I'm using _IQ22int(), _IQ22mpyI32(), and _IQ22frac() in my code up above.

 

edit: Guess not everything is working.  The _IQmpy() (multiply with rounding) barfs with missing MPY stuff:

C:/ti/msp430/IQMATHLIB_01_00_00_00/libraries/CCS/5xx_6xx_FRxx/IQmathLib_CCS_5xx_6xx_FRxx_MPY32_large_code_large_data.lib(__IQNmpy.o): In function `_IQ22mpy':
__IQNmpy.asm:(.text:_IQ22mpy+0x6): undefined reference to `MPY32CTL0'
__IQNmpy.asm:(.text:_IQ22mpy+0xe): undefined reference to `MPY32CTL0'
__IQNmpy.asm:(.text:_IQ22mpy+0x12): undefined reference to `MPYS32L'
__IQNmpy.asm:(.text:_IQ22mpy+0x16): undefined reference to `MPYS32H'
__IQNmpy.asm:(.text:_IQ22mpy+0x1a): undefined reference to `OP2L'
__IQNmpy.asm:(.text:_IQ22mpy+0x1e): undefined reference to `OP2H'
__IQNmpy.asm:(.text:_IQ22mpy+0x28): undefined reference to `RES1'
__IQNmpy.asm:(.text:_IQ22mpy+0x2c): undefined reference to `RES2'
__IQNmpy.asm:(.text:_IQ22mpy+0x30): undefined reference to `RES3'
__IQNmpy.asm:(.text:_IQ22mpy+0x4c): undefined reference to `MPY32CTL0'
c:/ti/ccsv6/tools/compiler/gcc_msp430_4.8.371/bin/../lib/gcc/msp430-elf/4.8.0/../../../../msp430-elf/bin/ld.exe: nokiahello.out: hidden symbol `MPY32CTL0' isn't defined
c:/ti/ccsv6/tools/compiler/gcc_msp430_4.8.371/bin/../lib/gcc/msp430-elf/4.8.0/../../../../msp430-elf/bin/ld.exe: final link failed: Bad value
collect2.exe: error: ld returned 1 exit status
gmake: *** [nokiahello.out] Error 1
gmake: Target `all' not remade because of errors.

I guess I'll have to conjure up some sort of linker script addendum to provide what it's looking for.

edit: Adding this to the end of the linker script, before the closing brace, shut up the linker and the code seems to work:

  PROVIDE(MPY32CTL0 = 0x0004EC);
  PROVIDE(MPYS32L = 0x0004D4);
  PROVIDE(MPYS32H = 0x0004D6);
  PROVIDE(OP2L = 0x0004E0);
  PROVIDE(OP2H = 0x0004E2);
  PROVIDE(RES1 = 0x0004E6);
  PROVIDE(RES2 = 0x0004E8);
  PROVIDE(RES3 = 0x0004EA);

This GCC compiler doesn't include the SFRs in linker symbols, it's all coming from #define's, whereas the TI code expects those SFRs to be linker symbols.

Share this post


Link to post
Share on other sites

Is it just me or is the content assist broken in the latest version? (00190)

I removed all versions of xdctools and reinstalled ccs6, but still nothing.

Share this post


Link to post
Share on other sites

[Edit: while this is interesting code for example purposes, if you really want to shrink your code size, look at the -minrt flag when you link instead of this solution]

 

Seeing as we are piling on with gcc changes  : ) ...

 

So if you run out of rom or ram space when trying to compile on the smaller chips like an msp430g2231, add this file to your project and check the box that disables the use of startup libs and default libraries.  This code will take the place of the gcc c runtime startup initialization code:

/*  -*- Mode: Asm -*-  */
;-----------------------------------------------------
; _start.S - minimal c runtime for msp430-elf-gcc
;   This is a hacked up version of the crt0.S from msp430-gcc
;   modified to work with msp430-elf-gcc. This allows the
;   smaller msp430g2xxx chips to link successfully with
;   very little extra code
;
	.section .text, "ax", @progbits
	.align 1
	.global _start
_start:

;-----------------------------------------------------
__init_stack:
	mov     #__stack, r1

;-----------------------------------------------------
__copy_data:
	mov     #__romdatacopysize, r12
	tst     r12
	jz      2f
1:
	decd    r12					; assumes data section aligned to word boundary
	mov.w   __romdatastart(r12), __datastart(r12)
	jne     1b
2:

;-----------------------------------------------------
__clear_bss:
	mov     #__bsssize, r12
	tst     r12
	jz      2f
1:
	decd    r12					; assumes bss section aligned to word boundary
	clr     __bssstart(r12)
	jne     1b
2:
	jz      main

;-----------------------------------------------------
	.section .resetvec, "ax", @progbits
	.word  _start				; point reset vector to init code above

save the code above as _start.S and put it in your project.

 

Note: You will also have to move the '*(COMMON)' line from the .noinit section to the .bss section in your linker script file.

 

-rick

Share this post


Link to post
Share on other sites

Y'know, it actually hurts to see how msp430-elf-gcc is turning out under TI's supervision. It could have been so cool.

 

Well, seeing as this is developmental software which is still a long way from even an alpha level release, I am willing to withhold judgement.

 

However, I do think that it is rather irresponsible of TI to release software in this state without any notification that it is still developmental software.

Share this post


Link to post
Share on other sites

TI has claimed this is at least a beta since its release in December; I don't know whether they believe it's evolved beyond that.

 

What's in CCSv6 is:

gcc version 4.8.0 20130315 (experimental (msp430-130423-317)) (Red Hat/devo) [trunk revision 196673] (GCC)
What TI makes publicly available with source through their website is:

gcc version 4.8.0 20130315 (release (msp430-130423-272)) (Red Hat/devo) [trunk revision 196673] (GCC) 
I'm completely uninterested in the forked version TI is shipping as binaries in CCSv6, and more interested in what's in gcc 4.9.0, which is what will replace mspgcc as packages for debian, Ubuntu, Fedora, OSX, etc. That there are things in the forked version (like __delay_cycles()) that have not been back-ported to the open version is, to me, a warning about how much priority is placed on support of the toolchain decoupled from CCS. Once Red Hat's job is done and TI is the sole maintainer of the version that goes into CCS I fear the GNU version will be as moribund as the msp430 support added in binutils back in 2004.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×