* 2004-12-09, Geoffrey Brown:

> I downloaded code composer essentials.  It appears to be eclipse + gcc 
> +gdb.  Anybody know if the
> gcc and gdb ports are related to those on the mspgcc sourceforge page ?  
> Also, it doesn't appear
> that TI has made the gcc and gdb sources available; the downloadable 
> sources appear to be
> for eclipse.

      http://focus.ti.com/docs/toolsw/folders/print/msp-cce430.html

 Even if CCE is based on the GNU toolchain without GNU GPL's "make source
 available in case of binary distribution", i think, after many years of
 GNU philosophy brainwashing and FOSS development experience, that it is
 better than nothing.

 Better in sense, that it is TI's supported product. The no-charge
 version is good suitable start option for users and MSPGCC active
 developers:

* as it seems to me, there are almost no pure-non-Windows(R) people here
* 8k is quite better, than IAR's 4k
* without fsck-ups form compiler vendors
  ** TI can control quality for both uCs and Ccs/asms
  ** same for mortals uC users -- emb. developers

- bad thing is, that generally it's not fair, if codebase was started
  from the original msp430 GCC port and nothing goes back.

 Well, from the historical perspective, GCC was holy cow for Cygnus for
 many years. They had many private GCC branches for many `customers'. I'm
 sure (see wikipedia last external link) something wasn't published as
 now is restrictively (sue FUD) required as per GPL.

 Not fair, *if* msp430 port developers require themselves more than 8k
 binary and much quicker uC support/errata patches. *But*, it is fair to
 allow to link many binaries in more than 8k final. After all many of
 FOSS developers deserve some sweets and cakes sometimes. If asm output
 is encrypted, then it isn't possible technically, if license is
 restrictive, then...
  
 Publishing source is low hanging fruit for any kind of proprietary
 compiler vendor's piracy. Making output binary linkink format easy to
 reverse engineer, is one for TRUE-developers :).

 OTOH, "sharing" and "maintaining" codebase is a very deep FOSS
 problem.
 
 But all this is not the case for Atmel's brand new AVR32, as it seems...

         http://atmel.com/dyn/products/tools_card.asp?tool_id=4118
--
-o--=O`C
 #oo'L O
<___=E M


Reply via email to