Moving to Our Own Server

ImageCraft blog is now our own server. See you there!

ICCV8 for AVR Released

After a year+ of researching and various false starts, and after surviving through the biggest downturn our industry has seen, and after some hard work by our consultant in porting the CodeBlocks IDE, and finally on the account of my birthday

ICCV8 for AVR is here. You can download the demo from our site. The Purchase page is up. The upgrade from V7 equivalent version is priced at $75 until July 1st.

Thank you for your support. Now I can go to sleep

ICCV8 for Cypress PSoC1 (M8C Core) PRO Released

We have just formally released ICCV8 for Cypress PSoC1 PRO. You can download the 45 day fully functional demo from our website.

In 2009, Cypress and our company signed an Agreement that allows Cypress’ PSoC Designer software to include a license to our ICCM8C STD compiler. The STD compiler is found to generate code that is approximately 15%-20% smaller than the previous available free compiler from another vendor.  The PRO compiler is fully compatible with the STD compiler so no code change is needed.

Currently the code size reduction of the PRO compiler over the STD version is about 10%. We expect to release updates this year that will push the performance envelope further.

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)

And Then There is One Less….

Embedded compiler and tool companies are endangered species. When I first joined Whitesemiths, the whole C compiler market was still new. Since then, there must have been at least a dozen DOS/Windows C compiler companies that have come and gone, and probably even more embedded C compiler companies have disappeared in the same period.

A popular trend is for silicon vendors to buy up compiler companies, nominally to ensure that they have full support for their chips. Motorola bought Hiware a few years back, and now Microchip just purchased Hi-Tech software.

Among embedded compiler companies that support multiple platforms, we are among a small handful of survivors. We understand the difficulties facing us.  We have been in business since 1994 and expect to be around for quite a bit longer. The economic situation made us re-examine our business model and development strategiesand we think that we can remain independent and continue to be successful.

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.