I hate all IDEs. I have yet to see one that improves in any way over a good text editor plus make. Besides being large, cumbersome, and slow, IDEs don't play well with more complex systems where a build might consist of compiling/linking code for multiple different processors. Before you try to point to eclipse as being open and therefore extensible to those more complex environments, don't bother. As far as I'm concerned eclipse is a bloated mess that concentrates the worst of many IDEs in one place. And don't wrap gdb in a GUI either; if I want to use some sort of debugger at all, the GUI just gets in the way. None of this is part of the real rant, I'm just letting you know about my bias.
This rant is about tool vendors who try to force IDEs on their customers. I don't care if they provide an IDE, but I do care if that is the only way to use their parts.
I'm going to use TI as my example because their MSP430 tools are the worst offender I've dealt with in a very long time, and because it would be so incredibly easy for them to address this that it's mind boggling that they haven't. Their official development environment is Code Composer, which is built on eclipse. Their compiler/linker are, like most others, independent programs that can be used just fine from a makefile. So I'm reasonably happy with that and am willing to live with the giant download and install of Code Composer to get the compiler. The problem is with programming the flash of the MSP430 parts. TI does not provide any method of doing that outside of Code Composer.
TI provides a hardware adapter called the FETU that connects to a host via USB and can talk to an MSP430 over JTAG or SBW. They also provide a library, MSP430.dll, that controls the FETU. What they do not provide is a standalone program to write to the flash of an MSP430. A quick look at MSP430.dll reveals function names that clearly indicate it provides just the right level of abstraction to make it easy to write a standalone programmer (it has functions to erase memory, program memory, etc.). However they do not provide the API for MSP430.dll (a google search indicates that they have provided that API to some under NDA, but all attempts by my client to obtain it fell on deaf ears). Without that API it would be difficult to write a standalone programmer that makes use of TIs interface.
For a project where I had to develop for an MSP430, I ended up having to first create a programming tool that utilized an SiLabs 8051 (because I happened to have suitable hardware available) as the USB to SBW interface and all custom code running on the 8051 and on the host. Creating my own did have the advantage of no longer being tied to Windows as the development host - my tool runs on Linux, and TIs own compiler works fine using wine. However this was a significant effort that could have been avoided by TI providing a command-line tool to do the programming through their own FETU (which, given access to the MSP430.dll API, would be trivial).
The bottom line is that on many projects I have a choice of processors; on those I always choose processors that have decent tools, which leaves out the MSP430. Even though I'm now happy with my custom development environment for that family, I'm too annoyed with TI for not providing a usable environment to voluntarily design with their parts in the future (yes, I'm being punitive rather than pragmatic).
allanh@kallisti.com