Month: January 2006

Support for C and C++ is officially supported in Eclipse by the C/C++ Development Tools (CDT) project. It offers a plethora of features for the language, including a C/C++ editor, a debugging environment, content assist, makefile generator, and parser. If you are building an Eclipse-based IDE for an embedded processor, is it the right choice? Or are you better off starting from scratch with the base platform? That’s the question that I’ll be examining in this post.

With all the features that the CDT offers, already designed, implemented and tested, you might wonder why anybody would choose not to base an IDE for their embedded processor on it. It’s a no-brainer, right? Especially when you consider how much effort you’d have to spend to replicate even the most basic features it provides out of the box.

This is a deceptively tough decision, though, and a lot of it depends on what you want out of the IDE.

Do you want your IDE to be different?

The CDT offers a full-featured standard platform on which to build a C/C++ development environment. The key idea here is standard. When you choose to use the CDT, you are accepting all of the design choices that went into it, and limiting the range of possibilities for customization.

To be sure, there are ways that you can customize a CDT-based C/C++ environment. But the possibilities are much narrower when you base your environment on the CDT rather than the base platform.

When do you need it?

While choosing the CDT reduces the range of design choices, it also reduces the length of the todo list.

If you need to get a C/C++ development environment out the door quickly, the CDT can get you there. Most of the hard work has already been done by the CDT developers.

The time-to-market benefit is especially noticable if the processor you are targeting is already supported by the GNU tools, in which case there is very little work to do. I’ve heard of IDEs built in a couple weeks this this way.

Market Fit

The CDT is a huge piece of software. It solves problems that I never even knew existed. Out-of-the box, it sports its own disassembly view, code completion, and an extensive build system, among other things. However, in the course of building all these features, the CDT developers committed to a host of decisions about how it would work.

These decisions, though, might not coincide with what your end user expects or wants. It could be as superficial as their being more familiar with the look and behaviour of another development environment or as fundamental as the CDT not supporting some essential debugging feature.

At AMI Semiconductor, our digital signal processors are so resource-constrained that it only makes sense to program them in assembly (we don’t even offer a C compiler). A highly-tuned assembly programming environment, then, was essential for our customers, and something we found lacking in the CDT when we first considered it.

Opportunity Costs

The do-it-yourself option is an expensive one. And in more ways than one. When you choose against the CDT, you end up devoting considerable resources to recreating features that already exist in the CDT, and in many cases falling short of their mark. What’s more, all that effort spend on re-inventing the wheel could have been spent tayloring the CDT to your processor.

If you are planning to build an Eclipse-based IDE for an embedded processor, you have some important decisions to make; decisions that will set the stage for all of your future development.

In this series of posts I’ll discuss 10 of these decisions. I’ll identify some of the factors you should consider in making them, and tell you how we, at AMI Semiconductor, decided for our IDE.

These are the decisions I’ll address:

1. CDT vs. DIY
2. GNU tools vs. DIY
3. ant vs. make
4. stable vs. latest
5. coordinated vs. independent release schedules
6. branch and fix vs. wait for Eclipse developers
7. replace views vs. live with it
8. stand-alone product vs. set of plug-ins
9. open source vs. proprietary
10. join Eclipse Foundation vs. work independently

[Disclosure: Mark Melvin and I are slated to give a talk at EclipseCon on this topic in March. Any comments or feedback you can send our way before the February 17th content deadline would be greatly appreciated.]

Dave Pollard explains why republicans want a huge national debt:

So now you know why Bush is not only unworried but actually pleased with skyrocketing deficits. They give him the excuse to cut government services and programs (if you read the harsh rhetoric of his annual budget he makes no bones about the fact he sees only defense and ‘homeland security’ expenses as essential), and to sell off ‘priceless’ parks, national forests and other public lands inexpensively to Republican campaign donors.

Steve Pavlina has some tips for building a high-traffic website:

My traffic-building strategy isn’t based on tricks or techniques that will go out of style. It’s mainly about providing genuine value and letting word of mouth do the rest. Sadly, this makes me something of a contrarian today, since I happen to disagree with much of what I’ve seen written about traffic-building elsewhere. I do virtually no marketing for this site at all. My visitors do it for me, not because I trick them into doing it but simply because they want to.

Here are 10 of my best suggestions for building a high traffic web site…

Guy Kawasaki shares some of the lessons he’s learned in hindsight. One in particular caught my attention:

4. People act like their last names sound. People may start to look like their dogs, but I think that they act like their last names sound. For example, I have a buddy named Will Mayall. He helps me with anything technical; for example, when I ask him if he can make my web site or blog do something, his initial response is, “I may be able to” and then two hours later he’s done it “all.” Hence, “may all.” Similarly, there’s Jean-Louis Gassée. He’s a funny guy–always armed with a great (usually sexual) metaphor to explain anything. He is a “gas” for the things that he “says”–hence, “gas say”. Then there’s Kawasaki–my high school football teammates told me that I was a “cow’s ass sagging.”

As you might guess, this didn’t find this observation encouraging.

And for those of you who might be wondering, I pronounce my last name so that it rhymes with sick, not psyche. Not that either pronunciation is all that flattering.

Cory Doctorow writes of a proposed bill that would regulate analog-to-digital converters:

The entertainment industry, always a bastion of media savvy, has proposed its “A-Hole” bill as a legal means of limiting the conversion of analog music and video to digital files. Under the bill, every maker of a device that can convert analog signals to digital ones (like iPods, camcorders, and PCs) would be required by law to be built with a detector for a proprietary watermarking technology called VEIL (the use of free/open source in these technologies would be outlawed to prevent the removal of VEIL detectors).

I wonder if the law would apply to digital hearing aids. Besides lowering the capabilities of hearing aids — today’s hearing aid processors are already squeezed to the last cycle in an effort to provide better audio so any additional processing to detect watermarks will come at the direct expense of reduced audio quality — such a law would also have the consequence of prohibiting the hard-of-hearing from listening to recorded music.

It’s surprising that such a bill would even be considered as it is relatively simple for anybody to build an analog-to-digital converter from components that can be found Radio Shack. Schematics can be found in most introductory electronics texts. Anybody intent on ripping audio from CDs could set themselves up with a few days of hacking.

I also wonder what effect such a law would have on the makers of anti-lock braking systems, which also use analog-to-digital converters; not to mention medical equipment, industrial controllers, and avionics.

In the spirit of The Long Emergency, one of the most frightening books I’ve ever read, Dave Pollard explains why oil prices are jumping again.

Guy offers some advice on how to kick butt on a panel:

Today I moderated a very good panel at a conference, and while this experience is fresh in my mind, I want to explain how to kick butt on a panel. At any given conference, there are about three keynote speakers and twenty five panelists, so the odds are much higher that you’ll be a panelist than a keynote speaker. Thus, I hope this entry appeals to a broader audience.

Note to self: Reread this before EclipseCon.

Larry Borsato announced today that Bleezer is shipping:

If you are a blogger, Bleezer will give you the ability to post to all of your blogs, regardless of what service you use, on any platform you want. The Bleezer website also has a blog so that you can keep up with new features and versions.

Larry has been cranking away on Bleezer over the past couple months. When Larry first told me about Bleezer in late November, I really wasn’t expecting very much. He’d been working on it for only a few weeks at that point, and it showed. I couldn’t even post an article to my blog with the first version I offered to beta test. But as we came through December, Larry got on a roll, fixing bugs and adding features faster than I could keep up. Before I knew it he’d tranformed Bleezer into a surprisingly capable blogging client.

Don’t get me wrong, Bleezer is still fairly bare-bones, but Larry has some big ideas for it, and at the rate he’s been going at it lately, I’m guessing they aren’t that far off.

If you like to give it a spin, you can download it for yourself from the Bleezer website.

Congratulations, Larry, on getting it out. And thanks for fun tool.

The CBC has written a pseudoblog to accompany a docudrama that aired last night. They call it the next pandemic blog:

The Next Pandemic Blog is a fictional portrayal of a hypothetical pandemic of H5N1 avian influenza – from initial outbreak through mass transmission to global spread.

Although a blog in only the loosest sense of the word — the content is static and pre-written out into June 2006 by a fictitious character — it’s an interesting read.

Obviously this shouldn’t be confused with some of the CBC’s more serious ventures into the blogosphere.