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.