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.

Posted in new product. Tags: , , . 2 Comments »

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)


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. :)

The Cypress PSoC C Compiler Saga

Some people may wonder about our Cypress PSoC C compiler plan. The original plan from a couple years ago was to release our PRO compiler, significantly increase the performance of the compiler. During the last couple years though, many unexpected factors came into play, but before we discuss the future, lets visit the past.

At the early 2000s, Cypress MicroSystems (CMS) was a small company with a big plan. Its idea of reconfigurable analog and digital blocks coupled with a MCU gave it a unique entry to the competitive microcontroller market place. Backing CMS was the Cypress fab, allowing CMS to mix flash, RAM, logic and the digital and analog blocks on the same chip. They headquartered in the scenic greater Seattle, allowing them to draw existing talents in the area.

And they have an impressive development team. They spec’ed their IDE to work with the innovations of the chips, giving the users a drag and drop experience of using the PSoC. The team knew that “everyone” would want a C compiler for the M8C CPU core, and they also smartly knew that growing their own compiler team was not in their best interests. ImageCraft was fortunate to be selected as their compiler development partner and the race is on to debut the PSoC to the world with world class software tools. If I recall correctly, the CMS software team and the ImageCraft compiler were ready in time for the hardware release. The hardware went through a few edit-modiy-tapeout cycle, but in the end, there was much rejoicing in the CMS campus when the product was released, around 2001/2002.

The M8C core is a fairly primitive 8 bits architecture. A single page summarizes all the instructions but it is by no mean a RISC processor. It’s accumulator based meaning that with few exceptions, all operations go through the 8 bit accumulator. There is also a single 8 bits index register, and there is no 16 bits operation. Unfortunately a proper C compiler (and it’s the “right thing to do” anyway) uses 16 bits int. So right off the bat, there were concern about performance, with assembler programmers coming out of the woodwork saying how this can be done better this way and that.

In time, many of the performance issues were fixed, but fundamentally the M8C is a poor match for a C compiler. It can be done, but it certainly is not ideal. We also improved the code size issues by introducing our whole program compression technology to the M8C. On our AVR target, we get 10-15% code size reduction using this technology, and as much as 30%+ in some cases.  On the M8C, our own study showed that a 5-15% code size reduction is typical. Not too bad and certainly would be important.

Fast forward to around 2005/2006. CMS was no longer a separate company and was fully back in Cypress. Lots of management and business unit changes happened. Their CAPSENSE version of the PSoC took off in a spectacular way. Unfortunately, the CAPSENSE is not the high performance end of the market. Meanwhile, PSoC max’ed out at 32K flash, and an elaborate SRAM paging scheme brought tears to the programmers’ eyes. Sadly, those are not the tears of joy.

During that time, we found out that due to some issues which they did not inform us about (so that they can be dealt with), Cypress has been telling their customers to turn off the code compressor. Lets think about this: in a competitive microcontroller market where they go up against established players, they have been recommending their customers to throw away 10% of the code size! *headdesk*

Under that environment, we thought that if ImageCraft were to produce the PRO compiler, we could work with customers directly and together with the code compression technology, we should be able to get 10-20% better code, and we could offer them the upgrades at very attractive prices. So we began working on the project. Then we noticed a “funny thing:” the new Cypress management is decidedly less communicative and we no longer have contact with the technical team.

Nevertheless, looking over the business situation, we made one last proposal to them: basically, for the royalty they would have paid us in the next few years, they would have unlimited rights to the M8C compiler. This is especially important if PSoC is to be pushed “everywhere” within Cypress and outside. We went back and forth a few rounds, but judging from the lackluster responses, clearly something is up.

So it came as no surprise that they formed an alliance with another company with their LITE-mode compiler available free of charge. I have no insight with their financial arrangement, but I am betting that a small amount of NRE (emphasis on small seeing how tightfisted the current Cypress management is) is paid and the theory is that the compiler partner will make money on their $1500 PRO tools. Riiiiigggghhht. The PSoC market is small, and the number of users who would move to asm programming to get the performance is large. It leaves one to wonder about the revenue model.

And what is the current state of the PSoC tools? The LITE-mode compiler is certainly no better than our compiler was, but now the customers have to go through cycles of debugging their code again. On top of that, they just introduced PSoC Designer 5.0 which has its share of teething pains. Meanwhile, any customer who wants better performance is looking at a single $1500 option.

If we are convinced that there is a market, it would still make sense for us to introduce a PRO compiler at 1/3 of the price of the competitor’s. Yes, our performance level goal is lower, but in many cases, it would be sufficient. However, given the rapid decline of the business relation, and looking at the potential market of PSoC in general, at this moment in time, I am no longer certain that it would make a good business case for us.

It’s too bad too. The PSoC has some really good ideas. More bug free devices earlier on,  higher performance devices with non-brain dead paging would have made them a better competitor in the marketplace. There are rumors of next-gen and next-next-gen devices, but they dated back in 2006 and none has shown up so far. The world matches on, and while the CAPSENSE business is still good, there is a limit to that growth as other vendors jump onto the market: once you spec out a PSoC device to do some fixed functions, then it loses its primary advantage of peripheral programmability and configurability. A CAPSENSE with a CPU core from another vendor may start to make as much sense.

As a final note, it appears that we are not the only one who is unsatisfy with the current PSoC situation. Check out Oliver Bailey’s blog http://oliverhbailey-psoc.blogspot.com/ for his “PSoC Chronicles.”