On Thu 2007-June-21 08:49,  "Sir Oregano, Duke of Chutney"  wrote:

> 3) Cruising through the recent archives of this list, it seems there
> are a handful of people who are using mspgcc successfully for active
> development of mainstream products. From these folks, I'm interested
> in hearing your take on the maturity of the toolchain...

I've been using mspgcc for commercial development since February 2003. 

> What % of
> your seat time do you spend coding for the target vs. troubleshooting
> toolchain issues?

I've not kept any records, but it has to be way over 95%. Toolchain issues 
seem to arise mostly when a new device has some special feature, or to work 
around some bizarre device erratum such as the 2131 return from 
subroutine/interrupt bug. 

To my mind, the important thing is precisely that I  *can*  fruifully put 
some time into solving such an issue at the toolchain level. With a few 
compiler modifications following advice from this forum, consuming perhaps a 
day in all, I was able to produce reliable (if somewhat sub-optimal) code 
for the badly-flawed early 2131 chips. 

> If you've got experience with both mspgcc and a 
> commercial package, how do they compare? 

Like most developers, I tried the IAR freebie compiler that comes with the TI 
FET first. It works, but I outgrew its limitations really fast. I then found 
mspgcc, and it has been sufficiently satisfactory that I've not had a motive 
to try the full IAR or any other commercial compiler. My job is developing 
hardware and its associated firmware, not tool evaluation, so I have to curb 
my natural instinct to to test exhaustively everything available, and pick 
the best. In practice, the first thoroughly workable toolchain I try gets 
the vote. 

> _Every_ toolchain has its 
> issues, and I have no expectation that mspgcc should be any exception
> to this, so I think this is a reasonable question. 

Right. Every processor has exceptions, many of them documented. Every 
toolchain has bugs. As Dijkstra so memorably put it, "All significant 
systems still contain bugs". Of course we'd all like everything to be 
perfect, but we have to face the fact that the person who never made a 
mistake never made anything. I think the important thing evolving in 
open-source software is the co-operative attitude to detecting, analysing, 
and fixing bugs. 

Whenever I move from a commercial product to an open-source one, the support 
and speed of bugfixing improve, and the tolerance of foolishness, 
impatience, and bluster drops. This suits me perfectly. I know that if I do 
a really good job of isolating a bug, and reporting it, it will be gone in 
days, and that's very motivating. It also ensures that, if the "bug" is 
really my foolishness or misunderstanding, there's a good chance I'll 
isolate the cause myself, the fastest possible fix.

The best thing about mspgcc is that, being based on a mature compiler 
technology, it works very well nearly all of the time. The second best thing 
is this forum, which has put me right when I've made my own mistakes, and 
unfailingly offered useful help whenever I've had a problem. 

-- 
Rick Jenkins <[email protected]>
Hartman Technica           http://www.hartmantech.com 
Phone +1 (403) 230-1987
221 35 Avenue. N.E., Calgary, Alberta, Canada T2E 2K5

Reply via email to