From richard at imagecraft.com Tue Feb 3 14:12:48 2009 From: richard at imagecraft.com (Richard Man) Date: Tue Feb 3 15:18:02 2009 Subject: [Icc-430] Available for programming consultation Message-ID: <200902032318.n13NI0LX059682@mail.imagecraft.com> With our current economic crisis, we must adjust to the market conditions until the time when they improve. As such, I am available to work on project programming and consultation. Please contact me off-list if you have any such needs. Thank you. // richard From richard at imagecraft.com Sat Feb 21 01:14:30 2009 From: richard at imagecraft.com (Richard Man) Date: Sat Feb 21 02:20:16 2009 Subject: [Icc-430] Comments and suggestions re: eFS: SD/FS/stdio Software stack Message-ID: <200902211020.n1LAKEjs028730@mail.imagecraft.com> I have gotten a prototype 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 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. I welcome any comments or suggestions. // richard From mark at oes.to Sat Feb 21 16:03:22 2009 From: mark at oes.to (Mark Borgerson) Date: Sat Feb 21 17:09:05 2009 Subject: [Icc-430] SD/FS/stdio Software In-Reply-To: <200902212000.n1LK01K0051322@mail.imagecraft.com> Message-ID: <200902220109.n1M194XU061269@mail.imagecraft.com> <> > > 1. Comments and suggestions re: eFS: SD/FS/stdio Software stack > (Richard Man) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 21 Feb 2009 01:14:30 -0800 > From: Richard Man > Subject: [Icc-430] Comments and suggestions re: eFS: SD/FS/stdio > Software stack > To: icc-announce@imagecraft.com, icc-avr@imagecraft.com, > icc-mot@imagecraft.com, icc-430@imagecraft.com, > icc-arm@imagecraft.com, icc-prop@imagecraft.com > Message-ID: <200902211020.n1LAKEjs028730@mail.imagecraft.com> > Content-Type: text/plain; charset="us-ascii"; format=flowed > > I have gotten a prototype 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 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. > > I welcome any comments or suggestions. I ported an open source FAT file system for SD to the MSP430 some months back. I even added some sector caching to reduce the times for FAT and directory updates. However, I could not get past one major obstacle: when adding a sector (or cluster) to the end of a very long file, the code to add a new cluster required traversing the FAT to find the next available cluster. For a 2GB SD card, the FAT may be hundreds of sectors long. Reading a hundred sectors to be able to write then next sector to the card wasn't very efficient---to say the least. Does your FAT file system include some way to cache some elements of the FAT so that the system doesn't have to traverse the whole FAT to add a cluster? Mark Borgerson From richard at imagecraft.com Thu Feb 26 05:08:30 2009 From: richard at imagecraft.com (Richard Man) Date: Thu Feb 26 06:15:06 2009 Subject: [Icc-430] eMOS for 430 is alive Message-ID: <200902261415.n1QEF5CL096259@mail.imagecraft.com> 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. // richard blog: On-line orders, support, and listservers available on web site. [ For technical support on ImageCraft products, please include all previous replies in your msgs. ] From richard at imagecraft.com Thu Feb 26 16:21:57 2009 From: richard at imagecraft.com (Richard Man) Date: Thu Feb 26 17:28:18 2009 Subject: [Icc-430] 430X lives!! Message-ID: <200902270128.n1R1SH8j010828@mail.imagecraft.com> Besides eMOS for 430 working, I now also have confirmation that CALLA/RETA work across the 64K page! Yes! :-) // richard blog: On-line orders, support, and listservers available on web site. [ For technical support on ImageCraft products, please include all previous replies in your msgs. ]