On 29/10/12 15:52, Peter Bigot wrote:
> On Sat, Oct 27, 2012 at 6:40 AM, David Brown <david.brown@...> wrote:
>> On 26/10/12 21:28, Grant Edwards wrote:
>>> On 2012-10-26, David Brown <david.brown@...> wrote:
>>>> Another issue is that TI make and sell their own msp430 toolchain -
>>>> Code Composer Studio. I would like to hear exactly how TI see CCS
>>>> and gcc fitting together and/or competing. It is certainly possible
>>>> for TI to support both toolchains, but it could be a delicate path to
>>> TI is still prentending that Code Composter for the '430 is "real"?
>>> The last time I went to an MSP430 event (which was a few years ago),
>>> the FAE openly discouraged people from trying CC for the '430. He
>>> told everybody to use IAR for playing with eval kits (he also briefly
>>> mentioned gcc).
>>> World+dog seemed to be of a single mind: that CC for the 430 was
>>> useless, but management at TI didn't want to admit it in public.
>> Well, I have my opinions on CC for the msp430, and they are not high -
>> we have a couple of projects that use it, because when they started we
>> needed to use 20-bit msp430's and gcc support for 20-bit was not yet
>> stable. But I don't want to go into detail about what I found bad about
>> CC for the msp430, as there have been several new versions since them -
>> maybe things have improved.
> I have not done an in-depth analysis of CCS versus mspgcc, but believe
> that CCS does generate better code in certain cases. In language
> capabilities (including GNU extensions) the current version (compiler
> version 4.1.1 coming with CCS 5.2.1 is pretty solid, whereas the
> compiler that came with CCS4 was fairly poor.
As I mentioned, the version of CCS that I used was a little older. I de
not have any complaints about the code generation - I haven't done a
serious analysis, but it looked fine. My two biggest issues are that
global data is not initialised to zero by default (and the manual only
mentions this briefly as a footnote, saying something to the effect that
they know this behaviour is contrary to the C standards, but that's what
the compiler/library do anyway!), and the default choices of warnings,
errors, and information messages was terrible in some cases.
> In fact, the only reason I haven't pushed CCS support for BSP430 out
> to the world is CCS' stdlib is egregiously bloated for an embedded
> environment: when I develop applications under mspgcc and port them to
> CCS, I have to fine-tune buffers and reduce memory all around so
> things work. To help with that I've split out the vuprintf
> implementation from msp430-libc, made a few enhancements and options
> to reduce its size, and will be releasing that as a separate library.
> The CodeSourcery stdlib is similarly bloated, and I need a capable and
> small printf(3c) function for Stellaris and EFM32 Cortex-M3
> development as well.
> Since a Code Composer Studio license gets you full compiler support
> for ARM and MSP430 (and I think C2K) microcontrollers on two hosts
> covering Windows and Linux for about $450, it's a reasonable next step
> for somebody going beyond hobbyist needs.
I hope TI does not consider gcc to be just a "hobbyist" choice - I
certainly see it as a professional choice. I have good professional
reasons for choosing gcc over "big name" commercial toolchains for many
of the microcontrollers I use - and on occasion I have picked paid-for
gcc toolchains (such as from CodeSourcery) over free versions of
commercial toolchains. But I have also done the opposite. I am a great
fan of giving users a choice, and I think it is a good think for TI to
support both toolchains (and to encourage third-party toolchains such as
IAR and ImageCraft).
> (Being a command-line--oriented developer, I do find it a little
> confusing that CCS = Code Composer Studio seems to refer to the
> development environment, whereas the compiler is a separately
> versioned anonymous component, which I think I'm calling "TI Compiler"
> where it needs to be identified.)