> It does if it's a high volume project and a cheaper processor could > have been used. I dunno. Judging by high volume consumer gear, the price of chips doesn't have a lot to do with the product price. If you have THAT high a volume, apparently you start negotiating with manufacturers for lower prices on the chips. Thus a high-volume consumer digital camera costs less than a microcontroller "evaluation board" even though the former has chips that dwarf the complexity of the latter, and wouldn't even be purchasable in low volumes... In this case (FAT filesystem on a flash card) using a high level language has an advantage I haven't seen explicitly stated yet. Since most of the "complexity" of the problem is external to the PIC itself, the advantages of dealing directly in assembler are lessened AND the PORTABILITY of the code is VERY MUCH IMPROVED by being in C. (In many cases, portability is not important, because the application is so inherently chip-specific anyway. But this isn't one of them.) You could write some carefully portable C code (an art in itself, alas) that would work on your initial selection of a 16F628 chip, and be nearly-instantly installed on an 18F chip when you discover you need a lot more program space, or on a 24F chip when you discover you need more speed, or on a freescale chip if Microchip pisses you off and you decide to switch vendors (although usually it seems to go the other direction :-) That said, a FAT file system isn't THAT complex, and an implementation written in assembler should be pretty doable by someone with experience. And I would think that there would be a lot of people interested in seeing the resulting code, especially if it turns out to be significantly smaller than the C versions floating around. (In my experience, FAT implementations tend to get pretty bloated.) BillW -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist