> On Wed, Feb 6, 2013 at 5:46 PM, Paul Curtis
wrote:
>
> > The unfortunate thing is that TI have effectively killed any 3P
compiler
> ecosystem for the MSP430 by introducing Code Composer for the MSP430.
>
> I am not sure I follow this. I am still relatively new to the MSP430,
but
> it seems as if TI has been offering a toolchain for the MSP430 for as
long
> as they have been producing them.
Your immaturity in this area shows. :-)
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com
What's the best MSP430 Development Enviroment?
Started by ●February 6, 2013
Reply by ●February 7, 20132013-02-07
Reply by ●February 7, 20132013-02-07
On Thu, Feb 7, 2013 at 9:59 AM, Paul Curtis wrote:
>> On Wed, Feb 6, 2013 at 5:46 PM, Paul Curtis wrote:
>>
>> > The unfortunate thing is that TI have effectively killed any 3P compiler
>> ecosystem for the MSP430 by introducing Code Composer for the MSP430.
>>
>> I am not sure I follow this. I am still relatively new to the MSP430, but
>> it seems as if TI has been offering a toolchain for the MSP430 for as long
>> as they have been producing them.
>
> Your immaturity in this area shows. :-)
Please feel free to enlighten me.
-p.
>> On Wed, Feb 6, 2013 at 5:46 PM, Paul Curtis wrote:
>>
>> > The unfortunate thing is that TI have effectively killed any 3P compiler
>> ecosystem for the MSP430 by introducing Code Composer for the MSP430.
>>
>> I am not sure I follow this. I am still relatively new to the MSP430, but
>> it seems as if TI has been offering a toolchain for the MSP430 for as long
>> as they have been producing them.
>
> Your immaturity in this area shows. :-)
Please feel free to enlighten me.
-p.
Reply by ●February 7, 20132013-02-07
The original MSP430C series came out in the early 90's, around 92/3 I
believe, maybe even 91, as I recall a very early data book (yes they did
hard copy then!!!) dated 1991, and I certainly still have some 93 books.
I have no idea what the toolchain was like then, as these were ROM based
parts. The MSP430F came out, or at least became available with
difficulty in late 98. This was just the 149 and 1121. The available
tools then were a crude serial interfaced JTAG, and IAR kickstart, which
sometimes worked, sometimes didn't. It seemed that you had to get the
right combo of IAR, micro batch and programmer to make anything happen.
Around late 99 IIRC the JTAG grey box became available with an improved
more stable version of Kickstart. Ti them selves didn't offer Code
Composer until much later in the piece, I don't know when exactly, but I
think around 2007.
In the early days, and I mean probably post 2002, the independent
compiler companies came on board, namely Crossworks, Imagecraft and
Quadravox. These companies actually offered support for their products,
which at that time was virtually impossible to get from either Ti or
IAR. around the same time, probably 2003 Bruce Cannon started this group
(thanks Bruce if you're still around), and almost immediately the
compiler vendors were here with invaluable advice of all kinds, and not
just regarding their products.
I would say that any real support for this product line from Ti was
essentially lacking until around 2006/7.
So, from my perspective the success of the MSP430 is almost solely down
to the 3P compiler vendors and a few other individuals, Like Kris,
Bruce, Leon and many others, who filled Ti's role for most of the
products life, until it became a major market force, then, from what I
read in to Pauls post, and Richards (Man of Imagecraft), Ti brought out
Code Composer, which at first was rather shambolic, and stopped support
for the independents.
Thats my take over my 15 year relationship with the beast. My memory may
be wrong in places, but that is my retrospective view.
Cheers
Al
believe, maybe even 91, as I recall a very early data book (yes they did
hard copy then!!!) dated 1991, and I certainly still have some 93 books.
I have no idea what the toolchain was like then, as these were ROM based
parts. The MSP430F came out, or at least became available with
difficulty in late 98. This was just the 149 and 1121. The available
tools then were a crude serial interfaced JTAG, and IAR kickstart, which
sometimes worked, sometimes didn't. It seemed that you had to get the
right combo of IAR, micro batch and programmer to make anything happen.
Around late 99 IIRC the JTAG grey box became available with an improved
more stable version of Kickstart. Ti them selves didn't offer Code
Composer until much later in the piece, I don't know when exactly, but I
think around 2007.
In the early days, and I mean probably post 2002, the independent
compiler companies came on board, namely Crossworks, Imagecraft and
Quadravox. These companies actually offered support for their products,
which at that time was virtually impossible to get from either Ti or
IAR. around the same time, probably 2003 Bruce Cannon started this group
(thanks Bruce if you're still around), and almost immediately the
compiler vendors were here with invaluable advice of all kinds, and not
just regarding their products.
I would say that any real support for this product line from Ti was
essentially lacking until around 2006/7.
So, from my perspective the success of the MSP430 is almost solely down
to the 3P compiler vendors and a few other individuals, Like Kris,
Bruce, Leon and many others, who filled Ti's role for most of the
products life, until it became a major market force, then, from what I
read in to Pauls post, and Richards (Man of Imagecraft), Ti brought out
Code Composer, which at first was rather shambolic, and stopped support
for the independents.
Thats my take over my 15 year relationship with the beast. My memory may
be wrong in places, but that is my retrospective view.
Cheers
Al
Reply by ●February 7, 20132013-02-07
>
> Please feel free to enlighten me.
>
TI have not always offered a toolset for the MSP430. I believe that IAR and
TI have a commercial arrangement to offer the limited KickStart version, but
that isn't the same as offering their own tools.
TI let the MSP430 compiler market blossom, and actively encouraged
independent 3P compilers. However, without telling the vendors they were
whispering sweet nothings to, they were secretly developing their own
toolset and deployed it:
http://www.embeddedstar.com/press/content/2004/12/embedded17452.html
TI's own toolset, Code Composer Essentials, was billed as the way of
offering a "one stop shop" because "this is what our customers tell us they
want." I don't care how they rationalized it, it signified the start of the
end of the MSP430 tool ecosystem. Why? Because TI can sweeten any deal
with a large MSP430 consumer by coughing up free Code Composer licenses,
effectively excluding a sale by any independent.
Of course, TI and customers say "build a better mousetrap!" And I think we
always have done. However, we need continued software sales to fund
development, and really can't compete with TI subsidising their software to
"free" through hardware sale offsetting. Building a better mousetrap and
offering superior support is clearly not valued highly enough by bean
counters.
So, there you have it.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com
> Please feel free to enlighten me.
>
TI have not always offered a toolset for the MSP430. I believe that IAR and
TI have a commercial arrangement to offer the limited KickStart version, but
that isn't the same as offering their own tools.
TI let the MSP430 compiler market blossom, and actively encouraged
independent 3P compilers. However, without telling the vendors they were
whispering sweet nothings to, they were secretly developing their own
toolset and deployed it:
http://www.embeddedstar.com/press/content/2004/12/embedded17452.html
TI's own toolset, Code Composer Essentials, was billed as the way of
offering a "one stop shop" because "this is what our customers tell us they
want." I don't care how they rationalized it, it signified the start of the
end of the MSP430 tool ecosystem. Why? Because TI can sweeten any deal
with a large MSP430 consumer by coughing up free Code Composer licenses,
effectively excluding a sale by any independent.
Of course, TI and customers say "build a better mousetrap!" And I think we
always have done. However, we need continued software sales to fund
development, and really can't compete with TI subsidising their software to
"free" through hardware sale offsetting. Building a better mousetrap and
offering superior support is clearly not valued highly enough by bean
counters.
So, there you have it.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com
Reply by ●February 7, 20132013-02-07
Maybe the reason that the "compiler ecosystem" is dead is simply
that
3P compiler + IDEs offer nothing that Code Composer doesn't already
offer to the MSP430 users? Or maybe they offer something the users
don't need?
So is the "3P compiler ecosystem" dead for AVR's too, since Atmel is
giving out free their own IDE and openly support GNU compiler for their
chips?
Just a thought.
3P compiler + IDEs offer nothing that Code Composer doesn't already
offer to the MSP430 users? Or maybe they offer something the users
don't need?
So is the "3P compiler ecosystem" dead for AVR's too, since Atmel is
giving out free their own IDE and openly support GNU compiler for their
chips?
Just a thought.
Reply by ●February 7, 20132013-02-07
> Maybe the reason that the "compiler
ecosystem" is dead is simply that 3P
> compiler + IDEs offer nothing that Code Composer doesn't already offer to
> the MSP430 users? Or maybe they offer something the users don't need?
No, it's dead because TI can charge $0 for their product, subsidising the development tool cost using hardware sales. It doesn't have to be good, merely adequate to exclude a sale from an independent. CCE was a complete pile when it appeared, and slowly over time, it has improved and has attained "Code Composer Studio" status. TI clearly see that to get customers to use their chips, they need to offer zero-cost tools to some.
Given pre-existing tools did a great job, and TI have eventually climbed to an "adequate" level with CCE, the differential is simply in the end user pricing. 3P's can't offset software development costs using hardware sales. Dev seats these days mean paying $0 for the tool, asking the community for help, and lashing up something using a $99 emulator which pops and farts, but not enough to be thrown away.
> So is the "3P compiler ecosystem" dead for AVR's too, since Atmel is
> giving out free their own IDE and openly support GNU compiler for their
> chips?
AVR is a different beast and the AVR has enough wrinkles to make GCC uncomfortable on it for code generation. 3Ps do a much better job on AVR than GCC, hence there is enough room for 3Ps such as ImageCraft, HP InfoTec, and so on, to flourish. Should GCC on AVR and inside AVR Studio attain the comfort of 3P toolsets, then it may well displace some more customers.
TI are not offering GCC in CCS and, I suspect if they did, then the MSP430 3P ecosystem would be a different place. However, they have ideas in the MSP430+GCC arena.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com
> compiler + IDEs offer nothing that Code Composer doesn't already offer to
> the MSP430 users? Or maybe they offer something the users don't need?
No, it's dead because TI can charge $0 for their product, subsidising the development tool cost using hardware sales. It doesn't have to be good, merely adequate to exclude a sale from an independent. CCE was a complete pile when it appeared, and slowly over time, it has improved and has attained "Code Composer Studio" status. TI clearly see that to get customers to use their chips, they need to offer zero-cost tools to some.
Given pre-existing tools did a great job, and TI have eventually climbed to an "adequate" level with CCE, the differential is simply in the end user pricing. 3P's can't offset software development costs using hardware sales. Dev seats these days mean paying $0 for the tool, asking the community for help, and lashing up something using a $99 emulator which pops and farts, but not enough to be thrown away.
> So is the "3P compiler ecosystem" dead for AVR's too, since Atmel is
> giving out free their own IDE and openly support GNU compiler for their
> chips?
AVR is a different beast and the AVR has enough wrinkles to make GCC uncomfortable on it for code generation. 3Ps do a much better job on AVR than GCC, hence there is enough room for 3Ps such as ImageCraft, HP InfoTec, and so on, to flourish. Should GCC on AVR and inside AVR Studio attain the comfort of 3P toolsets, then it may well displace some more customers.
TI are not offering GCC in CCS and, I suspect if they did, then the MSP430 3P ecosystem would be a different place. However, they have ideas in the MSP430+GCC arena.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com
Reply by ●February 7, 20132013-02-07
> until it became a major market force, then, from
what I read in to Pauls
> post, and Richards (Man of Imagecraft), Ti brought out Code Composer,
> which at first was rather shambolic, and stopped support for the
> independents.
TI never withdraw support for 3Ps, but they didn't have the best support
network to begin with (or at all). TI simply prioritized developing
solutions for their own toolset and IAR's toolset, rather than trying to
support each toolset to the best of their ability.
TI said they supported each tool vendor equally, but clearly that was not,
and is not, the case.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com
> post, and Richards (Man of Imagecraft), Ti brought out Code Composer,
> which at first was rather shambolic, and stopped support for the
> independents.
TI never withdraw support for 3Ps, but they didn't have the best support
network to begin with (or at all). TI simply prioritized developing
solutions for their own toolset and IAR's toolset, rather than trying to
support each toolset to the best of their ability.
TI said they supported each tool vendor equally, but clearly that was not,
and is not, the case.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com
Reply by ●February 7, 20132013-02-07
>
> No, it's dead because TI can charge $0 for their product, subsidising
> the development tool cost using hardware sales. It doesn't have to
> be good, merely adequate to exclude a sale from an independent. CCE
> was a complete pile when it appeared, and slowly over time, it has
> improved and has attained "Code Composer Studio" status. TI clearly
> see that to get customers to use their chips, they need to offer
> zero-cost tools to some.
>
> Given pre-existing tools did a great job, and TI have eventually
> climbed to an "adequate" level with CCE, the differential is simply
> in the end user pricing. 3P's can't offset software development
> costs using hardware sales. Dev seats these days mean paying $0 for
> the tool, asking the community for help, and lashing up something
> using a $99 emulator which pops and farts, but not enough to be
> thrown away.
>
Hmm I see your point. But it still sounds to me that you're blaming TI
for ruining your business.
>
> TI are not offering GCC in CCS and, I suspect if they did, then the
> MSP430 3P ecosystem would be a different place. However, they have
> ideas in the MSP430+GCC arena.
Yes, I have seen some posts on MSPGCC mailing list concerning that. I
think they're trying to answer to Atmel's GCC support with that, but
that's just me guessing.
> No, it's dead because TI can charge $0 for their product, subsidising
> the development tool cost using hardware sales. It doesn't have to
> be good, merely adequate to exclude a sale from an independent. CCE
> was a complete pile when it appeared, and slowly over time, it has
> improved and has attained "Code Composer Studio" status. TI clearly
> see that to get customers to use their chips, they need to offer
> zero-cost tools to some.
>
> Given pre-existing tools did a great job, and TI have eventually
> climbed to an "adequate" level with CCE, the differential is simply
> in the end user pricing. 3P's can't offset software development
> costs using hardware sales. Dev seats these days mean paying $0 for
> the tool, asking the community for help, and lashing up something
> using a $99 emulator which pops and farts, but not enough to be
> thrown away.
>
Hmm I see your point. But it still sounds to me that you're blaming TI
for ruining your business.
>
> TI are not offering GCC in CCS and, I suspect if they did, then the
> MSP430 3P ecosystem would be a different place. However, they have
> ideas in the MSP430+GCC arena.
Yes, I have seen some posts on MSPGCC mailing list concerning that. I
think they're trying to answer to Atmel's GCC support with that, but
that's just me guessing.
Reply by ●February 7, 20132013-02-07
>> Please feel free to enlighten me.
>> TI have not always offered a toolset for the MSP430. I believe that IAR and
> TI have a commercial arrangement to offer the limited KickStart version, but
> that isn't the same as offering their own tools.
>
> TI let the MSP430 compiler market blossom, and actively encouraged
> independent 3P compilers.
That is not quite how I remember things. I am not a compiler developer,
so obviously I don't have the "insider" views like you - but we were
early users of the msp430, and I have followed mailing lists had contact
with compiler developers over the years. And of course I may be
misremembering things, or have misunderstood things at the time - so
apologies if anyone feels I am being unfair to them.
When the msp430 came out, TI's attitude was that there was an msp430
compiler - IAR made it. They had no interest in any other vendors or
toolchain developers, whether they were high priced (like IAR), low
priced (like ImageCraft), or free (mspgcc). TI seemed totally incapable
of understanding why msp430 customers might want an alternative to IAR
tools. I know that the msp430 gcc developers had enormous trouble
trying to get anyone at TI even to acknowledge their existence, never
mind give them any help or information - and I believe that also applied
to other commercial toolchain developers. It took a good while before
TI came round to the idea that a choice of development tools was a good
idea.
> However, without telling the vendors they were
> whispering sweet nothings to, they were secretly developing their own
> toolset and deployed it:
>
> http://www.embeddedstar.com/press/content/2004/12/embedded17452.html
>
> TI's own toolset, Code Composer Essentials, was billed as the way of
> offering a "one stop shop" because "this is what our customers tell us they
> want." I don't care how they rationalized it, it signified the start of the
> end of the MSP430 tool ecosystem. Why? Because TI can sweeten any deal
> with a large MSP430 consumer by coughing up free Code Composer licenses,
> effectively excluding a sale by any independent.
>
> Of course, TI and customers say "build a better mousetrap!" And I think we
> always have done. However, we need continued software sales to fund
> development, and really can't compete with TI subsidising their software to
> "free" through hardware sale offsetting. Building a better mousetrap and
> offering superior support is clearly not valued highly enough by bean
> counters.
>
> So, there you have it.
>
I am sure you already know this, but you've got another challenge coming...
TI have engaged Red Hat to produce a gcc toolchain for the msp430.
There has been a working gcc toolchain and library for the msp430 for
many years, and it has always produced excellent code (and being gcc, it
has lots of useful features - I much prefer it to Code Composter). But
it is a bit rough around the edges, lacks debugger support for the
20-bit devices (though the compiler supports them fine now), and for
many reasons was never part of the mainline gcc tree - and that means it
takes longer time and more work to get the benefits of later gcc
versions. Now Red Hat is in the process of completing these missing
parts, and presumably also packaging it with an IDE (perhaps CCE).
>> TI have not always offered a toolset for the MSP430. I believe that IAR and
> TI have a commercial arrangement to offer the limited KickStart version, but
> that isn't the same as offering their own tools.
>
> TI let the MSP430 compiler market blossom, and actively encouraged
> independent 3P compilers.
That is not quite how I remember things. I am not a compiler developer,
so obviously I don't have the "insider" views like you - but we were
early users of the msp430, and I have followed mailing lists had contact
with compiler developers over the years. And of course I may be
misremembering things, or have misunderstood things at the time - so
apologies if anyone feels I am being unfair to them.
When the msp430 came out, TI's attitude was that there was an msp430
compiler - IAR made it. They had no interest in any other vendors or
toolchain developers, whether they were high priced (like IAR), low
priced (like ImageCraft), or free (mspgcc). TI seemed totally incapable
of understanding why msp430 customers might want an alternative to IAR
tools. I know that the msp430 gcc developers had enormous trouble
trying to get anyone at TI even to acknowledge their existence, never
mind give them any help or information - and I believe that also applied
to other commercial toolchain developers. It took a good while before
TI came round to the idea that a choice of development tools was a good
idea.
> However, without telling the vendors they were
> whispering sweet nothings to, they were secretly developing their own
> toolset and deployed it:
>
> http://www.embeddedstar.com/press/content/2004/12/embedded17452.html
>
> TI's own toolset, Code Composer Essentials, was billed as the way of
> offering a "one stop shop" because "this is what our customers tell us they
> want." I don't care how they rationalized it, it signified the start of the
> end of the MSP430 tool ecosystem. Why? Because TI can sweeten any deal
> with a large MSP430 consumer by coughing up free Code Composer licenses,
> effectively excluding a sale by any independent.
>
> Of course, TI and customers say "build a better mousetrap!" And I think we
> always have done. However, we need continued software sales to fund
> development, and really can't compete with TI subsidising their software to
> "free" through hardware sale offsetting. Building a better mousetrap and
> offering superior support is clearly not valued highly enough by bean
> counters.
>
> So, there you have it.
>
I am sure you already know this, but you've got another challenge coming...
TI have engaged Red Hat to produce a gcc toolchain for the msp430.
There has been a working gcc toolchain and library for the msp430 for
many years, and it has always produced excellent code (and being gcc, it
has lots of useful features - I much prefer it to Code Composter). But
it is a bit rough around the edges, lacks debugger support for the
20-bit devices (though the compiler supports them fine now), and for
many reasons was never part of the mainline gcc tree - and that means it
takes longer time and more work to get the benefits of later gcc
versions. Now Red Hat is in the process of completing these missing
parts, and presumably also packaging it with an IDE (perhaps CCE).
Reply by ●February 7, 20132013-02-07
> > Given pre-existing tools did a great job, and
TI have eventually
> > climbed to an "adequate" level with CCE, the differential is simply in
> > the end user pricing. 3P's can't offset software development costs
> > using hardware sales. Dev seats these days mean paying $0 for the
> > tool, asking the community for help, and lashing up something using a
> > $99 emulator which pops and farts, but not enough to be thrown away.
> >
>
> Hmm I see your point. But it still sounds to me that you're blaming TI for
> ruining your business.
The battle lines were drawn and the scene set for TI to lay waste to the 3P
toolset ecosystem the moment they released CCE.
Why do you think ImageCraft and Quadravox, who were servicing the MSP430
toolset market, have put further development of their products on hold?
There is only one reason: TI can charge $0 for their toolset in order to
simply remove the question of tool price from a potential customer's
decision making. Perhaps Michel or Richard can chime in here with their
analysis.
So, yes, I lay the demise of 3P MSP430 toolsets (as opposed to the vendors,
make the distinction) clearly at TI's door. And I think it would be hard to
disagree with my analysis.
But, you know, it is what it is.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com
> > climbed to an "adequate" level with CCE, the differential is simply in
> > the end user pricing. 3P's can't offset software development costs
> > using hardware sales. Dev seats these days mean paying $0 for the
> > tool, asking the community for help, and lashing up something using a
> > $99 emulator which pops and farts, but not enough to be thrown away.
> >
>
> Hmm I see your point. But it still sounds to me that you're blaming TI for
> ruining your business.
The battle lines were drawn and the scene set for TI to lay waste to the 3P
toolset ecosystem the moment they released CCE.
Why do you think ImageCraft and Quadravox, who were servicing the MSP430
toolset market, have put further development of their products on hold?
There is only one reason: TI can charge $0 for their toolset in order to
simply remove the question of tool price from a potential customer's
decision making. Perhaps Michel or Richard can chime in here with their
analysis.
So, yes, I lay the demise of 3P MSP430 toolsets (as opposed to the vendors,
make the distinction) clearly at TI's door. And I think it would be hard to
disagree with my analysis.
But, you know, it is what it is.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com
