While I have spent good chunks of time experimenting with the tools listed below, I have yet to develop anything like a non-trivial AVR—or any other microcontroller—project on any of them. So take it all with salt.

Here are some quick notes on some options I've investigated in alphabetical order. The more I investigate the available IDEs, the more it seems that learning the toolchain's individual tools and the commands they present is inescapable.

Executive summary (at this moment): If you are willing to run Java and deal with some intense resource demands, Eclipse CDT with the AVR Eclipse plugin is quite good.¹⁾ Geany plus some extra foo works for a very slim but usable setup. For something between these two extremes, CodeBlocks is a good choice.²⁾

Update (2011-01-16): CodeBlocks' build system for AVR development seems to be broken in Debian Wheezy. I managed to find a fix and wrote it up on one of my blogs. It's really not too horrible as you only have to do it once per profile.

Update (2011-01-21): Integrated debugging remains elusive. Another reason to use Makefiles w/CB (similar to the one used in my Geany stuff).

CodeBlocks has an AVR template that by default creates a *.cdb file with the needed build configs and commands. In addition, you can use standard Makefiles (Project > Properties > Makefile), and there are third-party tools for generating Makefiles from *.cdb files.³⁾ It has a decent interface to call external tools.

Code completion is pretty good; completions popup automatically or with Ctrl-Space; calltips are available w/ Ctrl-Shift-Space. When you set up an AVR project, make sure to add /usr/lib/avr/include to Project > Properties… > C++ parser options. This will let the autocomplete engine pick up on all the AVR stuff?

Some cautions:

• The standard CB AVR project doesn't appear to integrate support for chip programming (e.g., avrdude). You'll need to set this up as an external tool and/or use a Makefile or similar external script/build tool.
• How to change the MCU and clock frequency used isn't that intuitive.
  • MCU: Project > Build options… > Compiler settings > Compiler flags (scroll down to the middle) and Project > Build options… > Linker settings > Other linker options:
  • Clock frequency: Project > Build options… > Compiler settings > #defines

Any external scripts developed to fill in the holes above (debugging and programming) will require redundant entry of information—because there doesn't appear to be a convenient way to ask CB for the MCU type and clock speed. This could lead to a host of possible problems in use. So despite the platform-independence and apparent ease of using the CB build system, maybe going with a Makefile based setup is in the long run a better option.

This is how I got a Makefile to play nice with an AVR project on Debian Wheezy (as of 2012-01-14) and CB 10.05.

The following assumes you have only one build configuration in your Makefile. We'll call it a Debug build below because that's what you'll be building most of the time.

1. Create a regular AVR project. (Actually, it appears you can create any kind of project since everything will be overridden by the Makefile)
2. Create a Makefile in the project's root directory.
3. Open Project > Properties > Build Targets
4. Click the Projects Settings tab and check the “This is a custom Makefile” box.
5. Click the Build Targets tab and delete the “Release” target.
6. Click the C/C++ parser options tab and add /usr/lib/avr/include to Additional search paths.
7. Close the dialog and File > Save project
8. Open Project > Build options… and on the Pre/post build steps tab under both the {project-name} and “Debug” options in the left pane, delete any Pre build steps and Post build steps.
9. Click on the “Make” commands tab and under both the {project-name} and “Debug” options in the left pane change things as follows:
   
   (In words: replace $target with the actual name of the target you want.)
10. Close the dialog and File > Save project

Once you have done this, you can File > Save project as template… and you'll never have to repeat this again.

For good measure, use Tools > Configure tools… to configure additional tools and/or targets. Below is an example of a make hex command:

Alternately you might just add a custom tool to launch a terminal emulator and then manually invoke

make {target}

there—in which case CodeBlocks becomes essentially a glorified code editor with semi-automated autocomplete adding—which really isn't such a bad thing.

You should be aware that tools added this way are added globally, not on a per-project basis—so if you use CB for other tasks, these tools will pollute the interface. You can work around this by using separate CB personalities, which you can get going by starting CB with the -p <name-of-[new]-personality>, –personality <name-of-[new]-personality>, or–profile <name-of-[new]-personality> command line arguments.

Update (2011-01-23): In the grand tradition of all the other IDEs here, integrated debugging doesn't work with simulavr (at least).

CodeLite is workable, but a little unstable (e.g., it crashes when you try to re-dock the Workspace View panel). The UI is also kinda rough. For one, it's not platform aware—dialog buttons are in the wrong order for GNOME/GTK+. Also, the buttons on at least one dialog were barely reachable on my 1280×800 lappy. The default toolbar items and locations are remarkably persistent.

Still, it has good autocompletion and some refactoring support (of which “Rename symbol” is probably the only one that's really relevant to AVR projects). In spite of the roughness, this one is growing on me.

CodeLite lets you add custom toolchains pretty easily. Here's what I did to add an avr-gcc toolchain.

1. Open Settings > Build Settings… > Compiler and create a new entry called avr-gcc.
2. Rather than manually editing all the stuff for a custom avr-gcc entry, close CodeLite and open ~/.codelite/config/build_settings.xml in a text editor.
3. Copy over all the stuff from the regular gcc toolchain to avr-gcc.
4. Reopen CodeLite, open the Settings > Build settings… > Compiler dialog, and under the “Tools”, prefix gcc and ar with avr-⁴⁾.
5. Under the “Advanced” item, I added /usr/lib/avr/include to “Global Paths: Include Path.” I have no idea if that did any good or not.

1. Open Workspace > Workspace Settings…
2. Select the “Code Completion” tab and add /usr/lib/avr/include to “Search paths” and be prepared to wait a long time for CodeLite to parse the whole deal.

1. Open Projec Settings > Common settings > Compiler and a -mmcu={device-name} switch to the project compiler configuration.
2. You might also consider -DF_CPU={clock-speed} here.
3. There are probably other switches that should be added here as well, but I'll need to check the toolchain documentation and other people's makefiles.

1. Open Workspace > New project, then then under “Categories:” select “All” and under “Templates:” select “Custom Makefile”. Enter a Project name and verify the path where the project file and directory are being generated. You probably want “Create the the project under a separate directory” checked. I don't think the compiler type matters since that will be governed by the makefile.
2. Right click on the project icon in the Workspace browser and select “Settings…” Expand the “Customize” list item and select “Custom Build.” Then:
   • “Enable custom build” should be checked
   • Set “Working directory” to $(ProjectPath). (To see a complete list of available macros, click “Help”.)
   • Leave the “Build” and “Clean” targets as they are—unless you want them to be associated with different targets in the Makefile. Set “Compile Single File” macro to “make $(CurrentFileName)”.
3. Finally, select the “Code Completion” list item and add /usr/lib/avr/include to “Search paths” and be prepared to wait a long time for CodeLite to parse the whole deal. The good news is that it only needs to do it once—unless it changes. Which might actually turn out to be problematic if you forget. : Is this better done at the Workspace level? At the toolchain level?

To actually use the new project you must right click on it and “Set As Active”. Note the “Save As Template…” item. This could be good.

Update (2011-01-19): I am having a bear of a time getting Eclipse CDT to interface with simulavr. I get an error message that the gdb server (i.e., simulavr) doesn't respond to the run command—and you can't seem to make the Eclipse debugger startup not issue run. It may not be the end of the world not to be able to use simulavr, but if there's a similar problem with avarice, it'll be very annoying. Suggested workaround: create Makefiles (or similar) for simulavr and ddd support and create an external tool that launches a terminal.

Eclipse is a massive beast, but its autocompletion is really good. And it's one of the few FOSS tools available that will do C/C++ refactoring. There are two approaches worth investigating here: using CDT with Makefiles and using the CDT with the AVR plugin.

Initial testing suggests that you can use Eclipse CDT to develop AVR projects with a Makefile even without the AVR Eclipse plugin.⁵⁾ Here's how I set up a Makefile-based AVR project in a virgin Eclipse CDT install:

1. Open File > New > Makefile Project with Existing Code, select <none> for the “Toolchain for Indexer Settings,” take care to check/uncheck C and C++ as appropriate (i.e., you probably want C checked and C++ unchecked), browse to the folder with which the project should be associated, and click “Finish”.
2. Select Project > Properties > C++ General > Paths and Symbols > GNU C and Add… the path to the AVR libraries (e.g. /usr/lib/avr/include—use the “Filesystem” button on the dialog to navigate to the directory). This will let the editor find files referenced in directives like #include <avr/io.h> and so keep it from barking at you. If you get question mark markers in the editor for stuff you know is right, you may need to add more paths here.
3. Eclipse will automatically map Build to “make all” and Clean to clean all. You can add more targets by doing Window > Show View > Make Target and adding target names to the Make Target panel that appears (on the right pane in my setup). You can also add targets via Project > Make Target > Create… and run them with Project > Make Target > Build…, but I find the panelish way of doing it easier.

Now you can copy or create a Makefile and main.c file in the root of the project using the standard Eclipse mechanism for adding files. Note that files you add to the project will need to be manually added to the Makefile.

There are a couple things you could do to make life easier:

• Create an AVR skeleton C file for Eclipse
• Create an AVR Makefile template for Eclipse

Eclipse CDT automatically picked up code completions after I added /usr/lib/avr/include to the paths and symbols. This is a good deal.

Note that creating a project templates in Eclipse is not a trivial activity.

Aside from suffering from the general configuration inconveniences that Eclipse presents (i.e, config stuff is all over the place and split up), this setup seems to work pretty well. It generates Debug and Release builds in different subdirectories and supports avrdude. Once you add /usr/lib/avr/include to the project's paths and symbols, it automatically picks up the code completions.

The project has been around since at least 2008 and as of January 2012 appears to be active—suggesting that it will be around for at least a while longer.

Geany is awesomely lightweight, and its project support seems reasonably well-suited to Makefile-based projects.

Geany's biggest problem is that code completion is based only what is open in the editor and some basic language-specific stuff. It's other problem is that it really is basically an editor plus stuff tacked on to give it some mojo—so by itself it won't solve your build and MCU programming woes without some help. I've put together a small bundle (still quite beta however) that leverages Geany's mojo and turns it into a reasonably credible, Makefile-enabled “almost IDE” for AVR development. Debugging with simulavr (using the hideous but effective DDD for the debugger interface) is pretty easy to make go and seems to work as expected in this setup.

Even with the bundle above, Geany won't parse files referenced in the file you're editing for autocomplete symbols—meaning that local header files will need to be open if you want things defined in those to be autocompleted. The simplest workaround to this that I can think of is to have all the headers that are part of your project open during the session. Geany doesn't have any refactoring goodness—but the search/replace support is quite good.

Update (2011-01-20): As was the case with Eclipse, I can't get debugging with simumavr to work with Netbeans. I get the same “debugger doesn't repsond to 'run'” message, and I can't find a way to turn the autorun off. However, unlike Eclipse, Netbeans has a very convenient way of opening up a shell right in the IDE, from which make gdbinit, make simulavr, and make ddd (which you have thoughtfully put in your makefile, right?) can easily be invoked. So, a plus for Netbeans.

It's something of a tossup between Netbeans w/C++ and Eclipse CDT. Both have about the same intense hunger for resources, both have really excellent code completion, both can be configured for Makefile-based builds, both can be directed to additional includes on a per-project basis so autocompletion and tooltips work as expected, both support some C/C++ refactoring.

Netbeans has an edge in that it makes it easy to define custom toolchains—after which the built-in “Build”, etc. will work as desired. However, it has an issue with how it reports compiler errors. On my test project, Eclipse marked erroneous code in the editor with a red 'X', highlighted the compiler output error as well as a warning earlier in the compile, and made the errors and warnings active links into the editor. The same code in Eclipse produced the same compiler output, but only the warnings were active links (!) and the problem was not marked in the editor until you clicked the warning text, upon which the irritation-causing line would get a yellow triangle. Maybe there's a setting somewhere for this…

Use a text editor, a terminal emulator, and a Makefile. Clean. Minimal. Hardcore. This so frightfully close to the Geany setup above that you may as well reference that.

Qt Creator offers really outstanding code completion. The default “Regular C++ project” option for Qt Creator still relies on qmake. To make a Makefile-based project, you need to New project > Other project > Import Existing Project, and that gives you autogenerated {project-name}.config, {project-name}.files, and {project-name}.includes files—so it still seems to have some expectations about how things are set up. This process also generates {project-name}.creator and {project-name}.creator.user files in the project's root.

Thus, one of Qt Creator's problems in this context may be that it's cumbersome to set up an AVR project: the wizard selection isn't obvious and you need a Makefile. Another (and possibly larger) problem with Qt Creator is that you need the whole Qt development setup just to get the IDE. So, while I really love this IDE, I think it's not the best match for AVR development.