Ancient History
When we started ImageCraft back in 1994, I don’t think any embedded compiler has an IDE at the time. We released our first Windows IDE before just about everyone else. It was a Windows 3.1 program, if I remember correctly. Around 2001 we released the V6 IDE with compatibility with 32-bits Windows. Then around 2005 we released the V7 IDE with a slightly more modern look.
IDE is a funny thing – it’s the first thing that potential customers see, but our customers have always told us that in the end, quality code generation is the number one priority. We agree with that and we have improved code quality steadily while making our tools easier to use. Besides, it takes a lot of resource to write a good IDE, and with the onslaught of Eclipse and a few quality IDE/editors that are either free or available for a low cost, it does not make sense for us to devote limited resource that cannot compete with the vast resource IBM and others devoted to Eclipse.
So we started the quest for a next-gen IDE. The good news is that our compilers are command line programs and we have always opted to generate standard format makefile and use “make” to drive the build process. This means that our customers may use our IDE, other IDE/editors, or plain forego GUI tools and use command line tools. I’d guess that the split might be 40%50%-10% respectively.
We rejected Eclipse early on. It’s just too bloated and it has this “everything for everybody” philosophy that I feel uncomfortable with. For a while, the Visual Studio extension sounds promising as it leverages the Microsoft Visual Studio environment. However, Microsoft is, well, Microsoft, and the VS footprint is not significantly smaller than Eclipse, and there is the issue of “free” VS 2005 vs. VS 2008 (and now VS 2010) etc.
We even contemplated licensing some new IDE, but for one reason or another, they didn’t work out.
Enter the Code::Blocks
So finally, I am glad to say that we have a next-gen IDE in the work, and it is based on the Open Source Code::Blocks (C::B for short). It uses a modern editor engine and has good IDE features. It’s highly configurable with a plug-in architecture, and the licensing allows us to keep certain of our IP proprietary, which is important to keep our competitors at bay.
You can now get a pre-alpha version for ICCAVR here. Keep in mind that the link will change as we move through the alpha/beta process, and currently it is definitely not ready for prime time – you sneeze wrong, and it probably will break. OTOH, it has a good editor, and since it doesn’t touch the underlying command line compiler, it should generally be harmless to try.
Currently you must have a ICCAVR license to use this. The link is to a zip file, which you should unzip to your c:\iccv7avr directory. You run the IDE by invoking c:\iccv7avr\ImageCraftCB\codeblocks.exe. One of the first things you need to set is the location of the compiler. Go to Settings->”Compiler and debugger settings”->”Toolchain Executables” and type c:\iccv7avr (or where you install the AVR compiler) in the “Compiler’s installation directory.” Then go to the “Other Settings” tab, and make sure “Compiler logging” is set to “Full Command Line.” All of these will be made transparent later of course.
To create a C::B project, you can use one of the existing projects as a starting point. For example: invoke File->New->Project, and select the “ImageCraft AVR Project” icon. You can browse to one of the existing example projects, e.g. c:\iccv7avr\examples.avr\led and call the new project CB_LED. This creates a subdirectory called c:\iccv7avr\examples.avr\led\CB_LED. On the next tab, be sure to deselect the debug target build.
C::B automatically gives you a main.c file. You can right click on the file name on the project list and remove it. Then you can add the actual project source back. Right click on the project and invoke Build Options. Make sure you select the right target device and the Compiler->Output is set to “COFF/HEX with debug.” Set the “Return Stack” to 20-30 and generally just make sure the correct radio buttons etc. are selected. Eventually the behaviors will match that of our current IDE.
After that, you can build or rebuild your project, just like before. The C::B project operates independent of the current IDE project so both can exist independently (but also must be maintained independently).
There you have it. The first step of a modern IDE environment for your ICC compiler. C::B has a lot of potential, including existing support for debugging.
What’s Next?
C::B will be the V8 IDE. We will release it as an optional IDE for V7, for testing and feedback purpose, but it will probably not be a supported option for V7 per se. We will of course offer generous upgrade options (recall V6 to V7 upgrade was only $50 for at least 2+ yars): for ICCAVR, we will offer free V8 upgrades to any purchase since Sept 2009. We have not committed the V8 IDE for other platforms besides AVR yet, but the future compiler ports will use C::B as the basis. As for now, we are still debating whether to target the Atmel AVR32, or the ARM Cortex M0/M3 first.
With V8, we will also continue to improve code generation and post link optimizations, to build on top of our Code Compression technology. This will also be made on the Cypress PSoC ImageCraft PRO compiler, but that’s for another post.