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

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.

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.

(..click to read more…)

ImageCraft ICCV7 for M8C will be free!

Through an arrangement with Cypress Semiconductor Corporation, ImageCraft ICCV7 for M8C STD is now available free of charge to PSoC Designer users. The compiler is included as part of the PSoC Designer V5 SP4.5 and beyond.

- ICCV7 for M8C incorporates enhancements we have developed since the last official release to Cypress in 2006. The code size is 10-15% better than the previous free compiler available in PSoC Designer 5.0. We expect to continue to add enhancements to support the evolving PSoC devices.

- We expect to release a PRO optimized version by the end of 2009 with code size expected to be 30%-35% better than the previously available free compiler. Exact features and pricing TBD but we expect the price will be in line with our current product pricing range of $300-$549.

- As a good will gesture, we will offer customers who purchased our Cypress compiler licenses in 2009 a discount for the PRO compiler. Details TBD.

- ICCV7 for M8C is fully supported by ImageCraft. Any C related questions should be addressed to us directly at support @imagecraft.com

****

So what else are we planning to do? One lesson we learned from this financial crisis is that to compete effectively, avoid competition! Unsurprisingly, we will need to move to a Next-Gen IDE, add full support the the Atmel XMega, and add new target such as the Cortex M processors.

I will provide more progress reports as warranted.

// richard

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)

A one paragraph summary of GCC (GNU Compiler Collection, previously known as the GNU C Compiler back in 1985 when I was arguing with Richard Stallman why it’s a bad idea and he argued why I should join in the Cause) is this: GCC is a high quality compiler collection that is free to use if you agree with its terms (the GNU Public license or GPL). The base GPL stipulates that under some conditions, you grant your users certain rights  (“Freedom”) to your code. A less restrictive LGPL license gives you more freedom on what you need to release. As each GPL release takes months of Stallman’s time to write, I’d not attempt to summarize or interpret them beyond the above, as any such attempt would be inaccurate (as surely would someone say that I already mis-characterized GCC in the above). Interested parties should visit http://fsf.org instead.

GCC is used in many embedded projects. While anyone can build their own GCC binaries, you can download them pre-built and in some cases, some commercial vendors would sell you GCC with support, or with their own IDE, or libraries etc. GPL does not restrict you from making money per se, even selling GCC if you wish (finding customers is of course a different story).

It’s tough to argue for buying a multi-thousands ARM compiler when GCC is Free. So how does one compete with Free, regardless whatever license restriction it may or may not have? Different companies have different solutions, and after looking at this problem for a while, this is what will do:

The 8-bit Solution

Despite a movement to adopt 32-bit architectures, there will continue to be a big market for the 8-bit (and 16-bit) MCUs. This is the market where GCC does not excel in due to the inherent limitations of the GCC compiler architecture. So, to be more successful in this market, we will need to take advantage of GCC’s weakness and optimizes better. For the AVR, we are already better than GCC code quality wise but competing against Free is still tough. What this means is that we will be implementing mixed pointer qualifiers (e.g. __far, __near, __huge etc.) and generate optimal code for each type of pointer access. As 8 bit MCUs typically have different address space, this will be a big win. For the AVR, this means better control of flash data, especially for the XMega (GCC doesn’t support the simple flash space well already and the XMega will definitely stretch GCC’s limit); for the Cypress PSoC1 M8C (if we were to reenter the market), this means much better code density for data access.

Some compilers implement whole program analysis to support mixed pointer usage, but we believe that the programmers can give better guidance in most cases, resulting in a more robust compiler. Embedded programmers who are concerned about code size know their stuff well.

The 32-bit Solution

For the 32-bit, we already have an ARM/Thumb compiler and the Propeller C compiler. Nothing needs to be done about them. However, it does not make sense for us to compete with the free GCC on potentially new targets such as the AVR32 and the ARM Cortex. As our resource is limited, in this space, we will leverage GCC and give commercial users a better solution by integrating GCC with our simple to use IDE and Dinkumware’s rock solid C/C++/EC++ Library. This eliminates any possible encumberment for the users from LGPL, thus providing values to our customers. This also frees up resource so that we can work on software stacks (e.g. eMOS, SD/File System, etc.) for the targets, giving our customers a complete solution. Or may be even porting to OSX or Linux etc.

We will continue to keep our pricing competitive and tools easy to use. GCC presents a challenge, but then again, each challenge presents an opportunity. Life is never boring.

// richard

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.

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.

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.