> > *Why* did TI make the CCE tools, especially the compiler? TI makes chips, > and wants to sell chips - development tools are just a way to give > customers > the tools they need, so that they'll buy more chips. So why have they > gone > to the effort and expense of writing their own compiler? If TI felt that > the market needed a tool that was powerful (ruling out simpler tools like > ImageCraft), easy-to-use (ruling out mspgcc in the eyes of many), and > reasonably priced (ruling out IAR), then the obvious solution would be to > work with the mspgcc guys and produce a nice IDE and wrapper (Eclipse is a > sensible choice) round mspgcc. Producing a compiler as good as mspgcc > would > take far longer and cost far more than providing professional help to the > mspgcc project (for example, paying someone to get the port up to gcc 4.1, > providing information and header files for all the devices, especially the > newest ones). When Altera and Xilinx needed compiler tools for their > processors, both existing "hard" processors like the ARM and PPC, and > their > new soft processors, they turned to gcc as the ideal solution - and both > these companies have more software developers than hardware engineers. >
We already had compiler technology for other instruction set architectures that we reused. I don't think this is really the appropriate place to get into a pitch about why we think our compiler is better than someone else's but I'll just say that we have a lot of features that we feel are compelling. > One of the big reasons that I like the msp430 is that it's C-friendly > architecture has allowed for an excellent gcc port. If TI had supported > the > gcc (and gdb) work from the start, instead of being content ignoring all > non-IAR developers, I'd have been using msp430s for much longer and we'd > have far fewer AVRs at our company. When the 430X chips are available, if > they are not supported by gcc then they will not be an option for me - IAR > or CCE do not fullfill my requirements for development tools. When we > start > to need a small, cheap micro with more than 64k internal address space, > we'll pushed into using ARMs (unless the tiny ColdFires are out by then). > I can't really comment as to that as that's all handled by the MSP430 team and I really don't have anything to do with the support of the MSPGCC project. I'm just a lowly tools engineer :-P IMHO though, the more tools the merrier. I've been evangelizing for a long time that we should just plain give our tools away, period, and open source the whole lot, but as you can imagine that idea is hard to gain traction with. With CCE we've at least open sourced the portions that we can. BTW TI makes plenty of nice arm chips you can use too ;-) > Obviously no one in the TI management is going to cry about losing sales > to > a small company like mine (and we expect to use the ordinary msp430 for > many > years to come). But my point is that you ( TI ) should be supporting > something like mspgcc (and other tool vendors - I know ImageCraft had to > fight tooth and claw for information and support from TI in their early > days) in every way you can. The mspgcc developers should have all the > information available - or you should be writing patches and contributing > directly. I'm fully aware that there are complications in this, such as > specifications which change - but generally these things can be worked > out. I agree but it's not my call to make I'm afraid. ___________________________________________ Chris Recoskie Software Designer Texas Instruments, Toronto http://eclipse.org/cdt
