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

eMOS for AVR Released

doc: http://www.imagecraft.com/pub/emos_avr.pdf
zip: http://www.imagecraft.com/pub/emos_avr.zip

The zip file is the demo version. You are limited to up to 5 tasks. Currently you will need to unzip the content in a temporary directory and then copy the files:

copy *.h c:\iccv7avr\include
copy lib*.a c:\iccv7avr\lib

When we release the next AVR compiler demo update, the files will be incorporated directly.

****
We really feel that eMOS is a very useful tool. The core features of preemptive multitasking and message passing are nice, but we also carefully added additional features such as stack checking, virtual watchdog, and system call error checking, which can save you significantly amount of debugging time. Please check out the documentation or the demo and see for yourselve.

****
Our next port is probably either the MSP430 (the system idle task hook is ideal for low power systems) or ARM. Let me know if you have interest in either port.

Polling for the Future… TCP/IP stack

Now that eMOS for AVR is in beta, time to polish off the crystal balls some more. I have a consultant looking at CANLIB for AVR already. I’d think that a robust, fast, small, full-feature TCP/IP stack is high on the list of things we should do. Problem there is there are 4 qualifiers there, and as they usually say, you can get 2 out of 3, or 3 out of 4. So what features would you want in a TCP/IP stack?

A compiler tie-in is that someone suggested that we provide some sort of API so that a program can take a web page HTML with embedded references to C variables, e.g.

…// html stuff …
…. @foo:bar …

where bar is a local variable in foo, and the API would expand the values at runtime. I am not sure what kind of variable reference we can allow yet, but you get the idea. Yay or nay?

Comments and suggestions always welcome. Contact me at richard at imagecraft.com

eMOS is in beta

eMOS for AVR is now in beta testing. You can find the documentation here. If you are interested in participating, please contact us. We believe eMOS’ high performance features such as preemptive scheduler, tight integration with the ImageCraft compiler, combining with safety features such as stack checking and virtual watchdog set eMOS apart from other RTOS. Of course it has very competitive priced.

Being the Target

We don’t talk about our competitors much, if at all, because we believe any potential users can make the best decisions by us providing fully functional demo and they can see how well our tools fit their needs. Our dinosaur logo was something we did on a whim back in 1994. It’s whimisical and it drives right to the heart of our initial rationale for starting the company: we can make a living selling inexpensive compilers. Over the years, our products get more full features so it’s really about “Professional tools that don’t break your bank.”

Back to competitors. We must be doing something right, as we seem to be the targets of every company in competition with us. There is a well known 3-letter company who provided customers with benchmark data comparing their 5 year old compiler release with our then not yet released beta MSP430 compiler (have they no shame?). The guy who makes the cheap AVR compiler from Eastern Europe loves to use us in their release notes and forum postings, and how about that Aussie company who says their PRO M8C compiler is so much better than ours? It’s like we have a bull’s eye as our logo. Why mention all these now? Well, wouldn’t you know it, a seller of GCC ARM compiler with their own IDE now beating us on a 10 lines code fragment saying, see, GCC is really quite good.

Well OK, may be we can improve code generation in this case and that case, but I have expected better behavior from the last author. I have been in communication with him over the years, and I thought that he was a nice chap. While I don’t expect him not to publish whatever he likes, it would have been cordial to bring the matter to me? Oh well…

BTW, all these competitors neglect to mention that in terms of price performance, they can’t touch us. Also, we don’t exactly stand still as we improve our products all the time. Our customers use our $249 compilers to make commercial products everyday. Raw performance isn’t the only thing, usability, support, price performance all go into the equations.

BTW, eMOS has gone into beta testing. A full preemptive robust RTOS that doesn’t break your bank. Hmmm… wonder where I got the idea from? :-)

Propeller C user mailing list

We have added a mailing list for ImageCraft Propeller C users. Please visit here for info.

eMOS Draft documentation

We have a prototype eMOS running now. The latest document is here: http://www.imagecraft.com/pub/emos_avr.pdf. We added some features based on comments and also based on really looking at how best to make eMOS useful for embedded development. For example, dynamic memory can now be tracked, and we added a virtual watchdog system. We believe all these will make eMOS a highly competitive product.

More on eMOS

I have updated the “eMOS White Paper” entry with the current list of API. Please check it if you are interested. The tentative pricing is as follows. The initial port will be to the Atmel AVR, to be followed by MSP430/S12/ARM etc.

eMOS is licensed and not sold:

Evaluation – For non-commercial use only. Binary release included with the ImageCraft compilers. Support up to 5 tasks.

Student $99 – Binary release with no task limit for non-commercial use only.

STD $695    – binary release with unlimited end user product distribution for a single licensee (*).
ADV $1495 – source release with unlimited end user product distribution for a single licensee.
PRO (call for pricing) – source release with unlimited end user product distribution for a single developer or company.

STD to ADV upgrade: $800.

Purchase includes one year of upgrades and support. Upgrades and support may be purchased per annum basis for $300, $600 and $1000 respectively. You may continue to use your licensed copy of the product and distribute end user product after the support contract expires if you choose not to renew.

(*) a licensee is defined as one developer and one embedded product

eMOS Whitepaper

eMOS – an embedded message passing real time OS

eMOS is a real time OS for embedded systems with a preemptive message passing kernel at its core. The message passing API provides a uniform model for supporting additional software stacks such as UART driver, File System, USB stack, TCP/IP and CAN library etc.

Read the rest of this entry »

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

New ad and new products, oh my!

We just submitted a new ad to Circuit Cellar Inc. It should appear in their Nov issue. (Note: the young woman demonstrating her eBox kit IS a student, not a professional model. :) )

Meanwhile, we have a few new major and minor product releases in flight, so many that it is almost tough to keep track of them. Some highlights:

  • As blogged in a previous entry, the Parallax Propeller is an exciting new microcontroller that brings the power of multiprocessing to embedded market.  We are now prototyping a XMM (external memory model) scheme where programs can be stored in external memory, in as much as multi-megabytes of storage. With the 8 32-bit cores in the Propeller and combined them with huge amount of program memory, this could be a potent combination for experimenters.
  • Atmel is aggressively pushing out their new XMega versions of the AVR devices. Our AVR compiler already provide the basic support and we will be releasing a beta version of the Application Builder that works with the XMega soon.
  • Also in development is a CAN library for the AVR. We will be releasing the base version soon which will support the CAN128 and will be included as a part of the compiler package. Forthcoming are higher level APIs and faster performance and integration with a RTOS.

I should expand on the last entry a little bit more. We will be releasing an  embedded message passing OS, hence named eMOS, tentatively in Nov 2008. It has a preemptive scheduler with task priorities and round robin scheduling. Comparing to a cooperative kernel, it has higher overhead on RAM usage but it allows very natural use of “functions as tasks” model. The philosophy is that as much as possible, the RTOS should not impose restrictions on the user programs.

Read the rest of this entry »