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

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.

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

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