Next-Gen IDE, Code::Blocks pre-Alpha

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.

Crisis and Opportunity

The Chinese words for crisis is 危機 (weiji). As with most Chinese word-objects, it is made up of two independent words, 危(wei) / danger and 機(ji) / opportunity. And so the global financial crisis also presents us with some opportunities to renew ourselves.

(..click to read more…)

Competing with “Free” Software

Tough Survivors

As I said in the last blog entry, independent embedded C/C++ compiler companies are becoming rare birds. Of the independent companies that support multiple platforms, besides us ImageCraft, there are Green Hills (US), IAR (SE), Cosmic (FR), Rowley (UK), and… um, I think that’s it. Since being bought up, Hiware/Metrowerks primarily target Freescale chips; Hi-Tech clearly will concentrate only on Microchip’s PIC; Keil, despite being an “ARM company,” still sell tools for the 8051, C166 etc. probably because the money is good, but who knows how long that will last?… Most  if not all compiler companies were started by compiler gearheads (who else would be crazy enough to start a compiler company?) a while ago. In fact Cosmic and ImageCraft are tangentially related through our lineage with Whitsemiths. With the different product pricing and the vast number of embedded devices, most of us in fact do not compete directly with each other per se. However, there is …

The GCC Equation 

(dun dun duuuuunnnn…..)

Different embedded compiler companies “die” for different reasons, most likely financially related, and in 2009, the GCC equation must be a factor directly or indirectly. (Click on …more… to continue)

Product Development Update

There are only about 50-100 assembly lines (if that) in the core executive portion of eMOS, but like all other executives, it takes blood, sweat, and tear to get it right. After a night of hardcore debugging, I am happy to say that eMOS for 430 is alive with the messaging routines working quite well. A bits more testing and code cleanup, and modifying the documentation and it’s good to go.

As per design, only3-4 lines of C code need to change, to accommodate the difference between AVR and the MSP430 (other than the device specific code of course). There may be more opportunities to take advantage of the low power mode of the msp430, I will be working on that. For those who do not know what eMOS is, please refer to http://www.imagecraft.com/pub/emos_avr.pdf. It’s the AVR document, but the functionality is nearly identical.

***

In another news, regarding the minimal support for the 430X in the form of > 64K support, I have gotten the CALLA/RETA code in, and it works well for the below 64K cases. I have trouble loading > 64K program so it has not been tested where it counts yet, but I have just gotten a loader that should work. I hope to finish that off relatively soon also.

***

I also have a prototype SD/FAT stack working, complete with ANSI C stdio functions (fopen, fprintf, fputs, etc.) to a middleware FAT filesystem on top a SPI SD interface. The code is completely portable, currently being tested on an AVR Mega32.

The current plan is to release a standalone version and a version adapted for eMOS RTOS (hooks for other RTOS will also be provided), plus the FAT layer will also comes in two versions: one that is fast and support multiple concurrent devices but really requires external SRAM and one that is slower and supports only one device but works with the small amount of internal SRAM. So 4 versions altogether.

I am working on optimizing the FAT layer both at the algorithmic level and low level code generation. However, it’s probably not recommend for devices with less that 32K of flash or 2K of SRAM.

The application API is strictly ANSI C, based on the Dinkumware library, written by PJ Plauger, my former boss and the code is as complete and as rock solid as it gets.

The hardware interface initially supports SD card using the SPI protocol, but the code can be easily adapted for other memory devices or protocol.

The proposed pricing is $200 binary only, with the needed functions supplied in source code for any customization.

The initial release will be for the AVR, but ports to all targets with built-in SPI should be trivial. The Propeller requires a bit bang version of SPI interface using a separate Cog. Other devices without hardware SPI can use bit banging.

New Year, New Challenges, New Plans

One aspect being a small company is that we can and often need to move fast. Back in 1996 or so, we were one of the first embedded compiler companies to have  a presence on the web. To wit, guess how many variation of imagecraft and imagecraftXYZ .com .net etc. are out there?

In response to the current financial situation, we need to make changes in our plans. First and foremost, we will continue the path began by the eMOS release – we will add more software stacks to our offering. It makes sense for the customers and it makes sense for us business wise. The plan is still to release eMOS for the MSP430 next, and then SD/FAT support next.

Core IDE enhancement wise, the plan for the next-gen IDE has changed. We have decided that the best option is tokeep our IDE, which is nice and simple, and a) integrate a new editor engine with more modern features (e.g. code folding), b) update the look and feel with more modern looking icons, and c) add more user friendly features. We have decided to leverage the Open Source Scintilla editing engine which supports all the modern editing features.

In the MSP430X support front, we will release a new version of the MSP430 tools that support > 64K function calls first, without the additional support for the other new 430X instructions. Those will be added later. The > 64K support is the most important and this allows us to make a release sooner rather than later.

eMOS for TI MSP430

We are now porting eMOS to the TI MSP430. The TI MSP430 excels at minimizing power consumption, and with eMOS’ system hooks to shut down the system when it is quiescent, eMOS is a good fit for the MSP430 family. We expect porting and testing will take about a month so production release should be around the beginning of March.

FileSys and SD modules, plus eMOS update

First, a quick update on eMOS: we have modified the eMOS_MsgReceive function to include a timeout value, so that the call may timeout if no message is received within the specified time period. A couple minor functions are also added. See the doc for details.

// EDIT: yes, the goal is to support both FAT16 and FAT32. Long File Name under FAT32 may require end user to pay Microsoft a licensing fee of $0.25 per copy used, or we may support a different LFN implemenation

We are now looking into our first plug-in module for eMOS, which is a file system and SD driver. We will probably also include a standalone version that does not require eMOS. The eMOS version will of course fully support multitasking.

In terms of API, the obvious choice for the FS is in fact the stdio.h C API, in summary:

(more under the …more…)

Propeller Bundles – Buy A Compiler, Get a Free Board…

For limited time, we are offering a free Propeller Demo Board when you purchase a Propeller C compiler, both the -NC and STD versions. This is the same board that retails for $80. This is a great way to get into C programming for the Propeller. Take advantage of the sales now, while supplies last. Go to our website, http://www.imagecraft.com, click on Hardware, then “Special Price Bundles,” and select the version you want.

-NC Non Commercial Use License and Low Cost Hardware Bundles

We have released -NC Non Commercial Use license for all the V7 products. In addition, we have created some very attractively priced bundle kits – perfect for people starting embedded development. For more information, click on the “Harwdare” button on our website, then “Special Price Bundle Kits.”

Commodity pricing, PSoC, Propeller, XMega, 430X, XGate, Cortex, new IDE et. al.

Our company was incorporated in 1994 on the assumption that while embedded development tools are not a commodity product per se, if we lowered the price of entry and provided products and services with a good price/performance ratio, then we could satisfy a market need and create a decent business.  Now that we have been in business for over 14 years, I’d say we were correct in that aspect.  Not that we don’t have competitors, of course!  In fact, some of our competitors have now been adopting a “scorched earth” strategy: they put out free versions that are limited in code size, to provide a seemingly lower cost of entry.  However, most people that stay with the free versions will never buy our competitor’s $$$$-pricey versions anyway,  so clearly the main purpose of the strategy is to take potential customers away from ImageCraft in order to hopefully  “get rid of” us.  One response for us is to release even lower-cost non-commercial use versions for students and hobbyists; this would also help us to draw in hobbyists that are looking at Open Source compilers purely from a cost standpoint. So, we plan to be rolling out NC (non-commercial use) licenses in the next few months.

WordPress provides statistics about their hosted blogs, and consistently, the most-searched phrases that people use to find the ImageCraft blog are “Propeller C” and “PSoC Compiler.”

Propeller C is interesting in that currently a lot of Propeller customers are hobbyists. We expect that as Propeller increases its popularity amongst professional users, our C compiler sales may really take off there.

The PSoC compiler is a different story. Currently, Cypress is giving out a free C compiler that is at best at parity with the compiler we developed for them (which they used to sell for $149) and now has less extant bugs.  However, now Cypress has been cutting off their customers at the knee: once their customers grow beyond the usability of their free compiler, they will once again have to shell out $$$$ for a better compiler to meet their needs. We could produce a compiler that is probably 20% better than the free compiler and sell it at relatively low price, but with the non-cooperation we have been receiving from Cypress at this point, we do not see that as a good business move. It’s sad, too, as clearly Cypress customers are looking for a better compiler solution, and Cypress has currently chosen not to provide it.

The Atmel XMega AVR is a new series that has many compelling features, including an event system that basically provides DMA-like features between the peripherals without CPU involvement. It also provides greater than 64K data memory access. Our next release will support the extended data memory in forms of library functions.

The TI MSP430X extends the MSP430 architecture by providing greater than 64K bytes of flash. We are now working on the assembler support for this new series, and will be working on C compiler support for extended functions in a future release.

At least the Freescale S12 and S12X already have supported greater than 64K-byte memory since 2000 or thereabouts (albeit with a baroque paging scheme). The S12X has a coprocessor called XGate. We put XGate support in our assembler a while ago, but we never finished debugging it. We are now back to debugging the remaining issues, and hopefully we will release an XGate capable assembler soon.

As for Cortex!… we are making good progress with a Cortex assembler and linker based on our ARM asm and linker.  Once that is done, we will port our compiler to Cortex, pending ImageCraft’s resource allocations in the near future.

Finally, we have now decided to write our own next-generation IDE by leveraging Open Source project. This should provide a light-weight solution still  in the tradition of the ImageCraft IDE, with the added features that our customers want, and to provide a foundation for future versions. We expect to fast-track this, so expect an official announcement relatively soon.