Yahoo Groups archive
Thread
2005-11-09 by Joel Winarske
For anyone interested in implementing SD card with FAT12/FAT16 support this is worth a look: http://tinyurl.com/3ozdl -or- http://www.prllc.com/productcart/pc/viewPrd.asp?idcategory=10&idproduct=29 It's a great value. I ported it to IAR, and have it running on an IAR LPC2148 KS board. Joel
2005-11-09 by seangra
Call me crazy, but how is $150 for something that you can get for free a good value? There must be dozens of open source FAT drivers that could easily be ported, no? Or am I missing something? --- In lpc2000@yahoogroups.com, "Joel Winarske" <joelw@i...> wrote: > > For anyone interested in implementing SD card with FAT12/FAT16 support this > is worth a look: > > http://tinyurl.com/3ozdl > -or- > http://www.prllc.com/productcart/pc/viewPrd.asp? idcategory=10&idproduct=29
> > It's a great value. > > I ported it to IAR, and have it running on an IAR LPC2148 KS board. > > Joel
2005-11-09 by Joel Winarske
> Call me crazy, but how is $150 for something that you can get for > free a good value? There must be dozens of open source FAT drivers > that could easily be ported, no? Or am I missing something? Good point. The Circuit Cellar version was pretty limited. There were a few others I looked at. I dug through around six different implementations. Most were half baked; other's needed some major re-work. For the amount of time it would require me to massage the free code; it was cheaper to just pay the $150, and spend a couple hours porting. I get documentation, some assurance on quality, and support I can delegate a bug to. Like I said, I think it's worth a look. Joel
2005-11-09 by Tom Walsh
seangra wrote: >Call me crazy, but how is $150 for something that you can get for >free a good value? There must be dozens of open source FAT drivers >that could easily be ported, no? Or am I missing something? > > > You are, there really isn't any "good" FAT layers that are BSD licensed. Most of what the stuff is very simplistic, only read a file, and write to a new file. You don't have functions like: overwrite an existing file, etc. Take a look at a recent Circuit Cellar, issue 176(?), for the article "Portable FAT Library for MCU Applications <http://www.dtweed.com/circuitcellar/caj00176.htm>". That has the limitation that it will only create a new file, it will not overwrite an existing file (delete existing and create again). Also, program does not implement fseek(), although you can make it seek if you alter the code. IMO, there are two errors in that code as well, one deals with reading fragmented files, the other is reading from the MMC itself. The example they give for reading from MMC is flawed. The example works if you read the WHOLE file at once, subsequent calls to readPartialSector() will cause the MMC to return garbage data on occasion. Seems that everyone has $$$ in their eyes when it comes to this stuff: write-once, charge-many. I'm in the process of writing my own FAT layer that is integrated into NewLib (fopen, fclose, fputc, fseek, etc.). The plan is to release the source under a BSD license. While writing a FAT file driver is not that hard, it takes time. I was disappointed to find that no one had written one and released the source! Regards, TomW >--- In lpc2000@yahoogroups.com, "Joel Winarske" <joelw@i...> wrote: > > >>For anyone interested in implementing SD card with FAT12/FAT16 >> >> >support this > > >>is worth a look: >> >>http://tinyurl.com/3ozdl >>-or- >>http://www.prllc.com/productcart/pc/viewPrd.asp? >> >> >idcategory=10&idproduct=29 > > >>It's a great value. >> >>I ported it to IAR, and have it running on an IAR LPC2148 KS board. >> >>Joel >> >> > > > > > > > > >Yahoo! Groups Links > > > > > > > > -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." ----------------------------------------------------
2005-11-09 by Paul Curtis
Hi, > Call me crazy, but how is $150 for something that you can get for > free a good value? There must be dozens of open source FAT drivers > that could easily be ported, no? Or am I missing something? Ok, the challenge: find one that ports easily. I didn't find one, I tried the PRLLC one, but eventually I wrote my own. -- Paul.
2005-11-10 by SU
Hi,
How to be a happy SOHO who can earn enough money, also keep healthy as well.
M.T. -----Original Message-----
From: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com]On Behalf Of Joel Winarske
Sent: Thursday, November 10, 2005 3:45 AM
To: lpc2000@yahoogroups.com
Subject: [lpc2000] Cheap SD Flash File System
For anyone interested in implementing SD card with FAT12/FAT16 support this
is worth a look:
http://tinyurl.com/3ozdl
-or-
http://www.prllc.com/productcart/pc/viewPrd.asp?idcategory=10&idproduct=29
It's a great value.
I ported it to IAR, and have it running on an IAR LPC2148 KS board.
Joel
------------------------------------------------------------------------------
YAHOO! GROUPS LINKS
a.. Visit your group "lpc2000" on the web.
b.. To unsubscribe from this group, send an email to:
lpc2000-unsubscribe@yahoogroups.com
c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
------------------------------------------------------------------------------
[Non-text portions of this message have been removed]2005-11-10 by Paul Curtis
Robert, If you use MMC or SD cards, the on-board processor (an ARC is many cases, SanDisk is a fan) wear-levels the flash and swaps out defective sectors so the host can just regard it as a disk and write wherever it damn well wants. If, however, you need a NAND or NOR flash filing system, you need more complex software... -- Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk CrossWorks for MSP430, ARM, AVR and now MAXQ processors
> -----Original Message----- > From: Robert Wood [mailto:robert.wood@apostrophe.co.uk] > Sent: 10 November 2005 11:12 > To: lpc2000@yahoogroups.com > Subject: Re: [lpc2000] Re: Cheap SD Flash File System > > I am no expert on this, but I am lead to believe writing file > systems for flash based storage systems is a tricky business > if you want to get maximum life out of your flash. > Apparently, you need to try and ensure that you write and > erase sectors evenly, not just write to whatever space might be free. > > As far as I understand, the physics of how flash works means > that if you don't watch how you write to the memory, over a > period of time - not only can you wear out the cells you are > writing to, but adjacent ones as well. > > This company: > > http://www.hcc-embedded.com/site.php > > do a very neat, very small footprint flash file system for > various embedded processors - including ARM IIRC. More than > $150, but if what they say is true (and I suspect it is) you > will hugely increase the life of your flash cards. > > Cheers, > > Rob > > > > > ------------------------ Yahoo! Groups Sponsor > --------------------~--> Most low income households are not > online. Help bridge the digital divide today! > http://us.click.yahoo.com/cd_AJB/QnQLAA/TtwFAA/dN_tlB/TM > -------------------------------------------------------------- > ------~-> > > > Yahoo! Groups Links > > > > > > > >
2005-11-10 by Robert Wood
I am no expert on this, but I am lead to believe writing file systems for flash based storage systems is a tricky business if you want to get maximum life out of your flash. Apparently, you need to try and ensure that you write and erase sectors evenly, not just write to whatever space might be free. As far as I understand, the physics of how flash works means that if you don't watch how you write to the memory, over a period of time - not only can you wear out the cells you are writing to, but adjacent ones as well. This company: http://www.hcc-embedded.com/site.php do a very neat, very small footprint flash file system for various embedded processors - including ARM IIRC. More than $150, but if what they say is true (and I suspect it is) you will hugely increase the life of your flash cards. Cheers, Rob
2005-11-10 by Bill Knight
A pretty good, open-source, no-pay FAT layer is available at <http://alumnus.caltech.edu/~pje/rdcf2.txt>. The implementation there is limited to FAT16 but can be extended and has a lot of nice features. It requires read_sector() and write_sector() routines to access the logical drive. That means it can interface with floppy drives directly but will require a shim layer to properly access hard drive formated devices like CompactFlash, etc. Regards -Bill Knight R O SoftWare & http://www.theARMPatch.com
On Wed, 09 Nov 2005 15:29:35 -0500, Tom Walsh wrote: >seangra wrote: >>Call me crazy, but how is $150 for something that you can get for >>free a good value? There must be dozens of open source FAT drivers >>that could easily be ported, no? Or am I missing something? >> >> >> >You are, there really isn't any "good" FAT layers that are BSD >licensed. Most of what the stuff is very simplistic, only read a file, >and write to a new file. You don't have functions like: overwrite an >existing file, etc. >Take a look at a recent Circuit Cellar, issue 176(?), for the article >"Portable FAT Library for MCU Applications ><http://www.dtweed.com/circuitcellar/caj00176.htm>". That has the >limitation that it will only create a new file, it will not overwrite an >existing file (delete existing and create again). Also, program does >not implement fseek(), although you can make it seek if you alter the code. >IMO, there are two errors in that code as well, one deals with reading >fragmented files, the other is reading from the MMC itself. The example >they give for reading from MMC is flawed. The example works if you read >the WHOLE file at once, subsequent calls to readPartialSector() will >cause the MMC to return garbage data on occasion. >Seems that everyone has $$$ in their eyes when it comes to this stuff: >write-once, charge-many. >I'm in the process of writing my own FAT layer that is integrated into >NewLib (fopen, fclose, fputc, fseek, etc.). The plan is to release the >source under a BSD license. While writing a FAT file driver is not that >hard, it takes time. I was disappointed to find that no one had written >one and released the source! >Regards, >TomW >>--- In lpc2000@yahoogroups.com, "Joel Winarske" <joelw@i...> wrote: >> >> >>>For anyone interested in implementing SD card with FAT12/FAT16 >>> >>> >>support this >> >> >>>is worth a look: >>> >>>http://tinyurl.com/3ozdl >>>-or- >>>http://www.prllc.com/productcart/pc/viewPrd.asp? >>> >>> >>idcategory=10&idproduct=29 >> >> >>>It's a great value. >>> >>>I ported it to IAR, and have it running on an IAR LPC2148 KS board. >>> >>>Joel >>> >>> >> >> >> >> >> >> >> >> >>Yahoo! Groups Links >> >> >> >> >> >> >> >> >-- >Tom Walsh - WN3L - Embedded Systems Consultant >http://openhardware.net, http://cyberiansoftware.com >"Windows? No thanks, I have work to do..." >---------------------------------------------------- > >Yahoo! Groups Links >
2005-11-10 by Paul Curtis
Hi Bill, > A pretty good, open-source, no-pay FAT layer is available at > <http://alumnus.caltech.edu/~pje/rdcf2.txt>. The > implementation there is limited to FAT16 but can be extended > and has a lot of nice features. FAT12 is more complex than FAT16 when dealing with FAT 12-bit FAT entries that span a sector. A lot of SD cards are formatted FAT12 by default, so FAT16 is no good... Its requirements are also pretty high, requiring a 1K static buffer. The PRLLC implementation (and mine for that matter) can run with a 512-byte static or dynamic buffer. I'll take a look at this. It's something that I didn't find using Google, which is why I wrote my own implementation that is now part of NetBASIC. Regards, -- Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk CrossWorks for MSP430, ARM, AVR and now MAXQ processors
2005-11-10 by Bill Knight
On Thu, 10 Nov 2005 15:44:54 -0000, Paul Curtis wrote: >Hi Bill, >> A pretty good, open-source, no-pay FAT layer is available at >> <http://alumnus.caltech.edu/~pje/rdcf2.txt>. The >> implementation there is limited to FAT16 but can be extended >> and has a lot of nice features. >FAT12 is more complex than FAT16 when dealing with FAT 12-bit FAT >entries that span a sector. A lot of SD cards are formatted FAT12 by >default, so FAT16 is no good... Its requirements are also pretty high, >requiring a 1K static buffer. The PRLLC implementation (and mine for >that matter) can run with a 512-byte static or dynamic buffer. >I'll take a look at this. It's something that I didn't find using >Google, which is why I wrote my own implementation that is now part of >NetBASIC. >Regards, >-- >Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk >CrossWorks for MSP430, ARM, AVR and now MAXQ processors Paul I may be off on which FATxxx it supports. It has been a while since I last used it. It was written quite a while ago and lacked support for larger drives. Best check the docs and code to determine exactly what it does support. -- Bill
2005-11-10 by Joel Winarske
> Ok, the challenge: find one that ports easily. I didn't find one, I > tried the PRLLC one, but eventually I wrote my own. The port was very straight forward. The big items are change structure packing to 1 byte and #defines for your compiler. And then implement three functions in sd_cmd.c, and implement the rtc funcs for ARM. Joel
2005-11-10 by Joel Winarske
> FAT12 is more complex than FAT16 when dealing with FAT 12-bit FAT > entries that span a sector. A lot of SD cards are formatted FAT12 by > default, so FAT16 is no good... Its requirements are also pretty high, > requiring a 1K static buffer. The PRLLC implementation (and mine for > that matter) can run with a 512-byte static or dynamic buffer. On XP it's formatting a 128MB SD card with FAT16 by default. The card out of the package was FAT16. I haven't tried a smaller card to see if there's a difference. Joel
2005-11-10 by Paul Curtis
Joel, > > Ok, the challenge: find one that ports easily. I didn't > find one, I > > tried the PRLLC one, but eventually I wrote my own. > > The port was very straight forward. The big items are change > structure packing to 1 byte and #defines for your compiler. That wasn't the issue. The issue was that the PRLLC code did not handle subdirectories very well at all, it was tacked on as an afterthought. I reported some problems, didn't get a response, so moved on. Eventually a response came back... > And then implement three functions in sd_cmd.c, and implement > the rtc funcs for ARM. Like I said, that wasn't the underlying reason I wrote my own. -- Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk CrossWorks for MSP430, ARM, AVR and now MAXQ processors
2005-11-10 by Joel Winarske
> > The port was very straight forward. The big items are change > > structure packing to 1 byte and #defines for your compiler. > > That wasn't the issue. The issue was that the PRLLC code did not handle > subdirectories very well at all, it was tacked on as an afterthought. I > reported some problems, didn't get a response, so moved on. Eventually > a response came back... > > > And then implement three functions in sd_cmd.c, and implement > > the rtc funcs for ARM. > > Like I said, that wasn't the underlying reason I wrote my own. Where can one find your implementation? Joel
2005-11-10 by Tom Walsh
Bill Knight wrote: >A pretty good, open-source, no-pay FAT layer is available at ><http://alumnus.caltech.edu/~pje/rdcf2.txt>. The implementation there >is limited to FAT16 but can be extended and has a lot of nice >features. It requires read_sector() and write_sector() routines to >access the logical drive. That means it can interface with floppy >drives directly but will require a shim layer to properly access hard >drive formated devices like CompactFlash, etc. > > > Thank you for the URL! TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." ----------------------------------------------------
2005-11-10 by Tom Walsh
Robert Wood wrote: >I am no expert on this, but I am lead to believe writing file systems >for flash based storage systems is a tricky business if you want to >get maximum life out of your flash. Apparently, you need to try and >ensure that you write and erase sectors evenly, not just write to >whatever space might be free. > >As far as I understand, the physics of how flash works means that if you >don't watch how you write to the memory, over a period of time - not >only can you wear out the cells you are writing to, but adjacent ones as >well. > > Yeah, there is that too. IIRC, something like JFFS addresses that, sector wear distribution. On some CF devices, that is built into them, each time you write a sector, the device dynamically remaps. TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." ----------------------------------------------------
2005-11-10 by Sten
Bill Knight wrote: > On Thu, 10 Nov 2005 15:44:54 -0000, Paul Curtis wrote: > > >>Hi Bill, > > >>>A pretty good, open-source, no-pay FAT layer is available at >>><http://alumnus.caltech.edu/~pje/rdcf2.txt>. The >>>implementation there is limited to FAT16 but can be extended >>>and has a lot of nice features. > > >>FAT12 is more complex than FAT16 when dealing with FAT 12-bit FAT >>entries that span a sector. A lot of SD cards are formatted FAT12 by >>default, so FAT16 is no good... Its requirements are also pretty high, >>requiring a 1K static buffer. The PRLLC implementation (and mine for >>that matter) can run with a 512-byte static or dynamic buffer. > > >>I'll take a look at this. It's something that I didn't find using >>Google, which is why I wrote my own implementation that is now part of >>NetBASIC. > > >>Regards, > > >>-- >>Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk >>CrossWorks for MSP430, ARM, AVR and now MAXQ processors > > > > Paul > I may be off on which FATxxx it supports. It has been a while since > I last used it. It was written quite a while ago and lacked support > for larger drives. Best check the docs and code to determine exactly > what it does support. > Hello, does somebody have some good documentations about FAT12/16/32? (And would share it?) ;-) Sten -- /************************************************ Do you need a tiny and efficient real time operating system (RTOS) with a preemtive multitasking for LPC2000 or AT91SAM7? http://nanortos.net-attack.de/ Or some open-source tools and code for LPC2000? http://www.net-attack.de/ ************************************************/
2005-11-10 by seangra
Why would anyone want to use FAT12 on an SD card that's larger than 16 or 32MB anyway? FAT-12 was great for floppy disks, to save that few dozen KB on the FAT table because you only had 2MB to work with in the first place, but anything past 32MB and you get into huge sector sizes. A 256MB card would have 64KB sector size! Since FAT- 16 is easier to implement, why wouldn't you just stick with that? --- In lpc2000@yahoogroups.com, "Paul Curtis" <plc@r...> wrote: > > Hi Bill, > > > A pretty good, open-source, no-pay FAT layer is available at > > <http://alumnus.caltech.edu/~pje/rdcf2.txt>. The > > implementation there is limited to FAT16 but can be extended > > and has a lot of nice features. > > FAT12 is more complex than FAT16 when dealing with FAT 12-bit FAT > entries that span a sector. A lot of SD cards are formatted FAT12 by > default, so FAT16 is no good... Its requirements are also pretty high, > requiring a 1K static buffer. The PRLLC implementation (and mine for > that matter) can run with a 512-byte static or dynamic buffer. > > I'll take a look at this. It's something that I didn't find using > Google, which is why I wrote my own implementation that is now part of
> NetBASIC. > > Regards, > > -- > Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk > CrossWorks for MSP430, ARM, AVR and now MAXQ processors >
2005-11-10 by Tom Walsh
seangra wrote: >Why would anyone want to use FAT12 on an SD card that's larger than >16 or 32MB anyway? FAT-12 was great for floppy disks, to save that >few dozen KB on the FAT table because you only had 2MB to work with >in the first place, but anything past 32MB and you get into huge >sector sizes. A 256MB card would have 64KB sector size! Since FAT- >16 is easier to implement, why wouldn't you just stick with that? > > > Legacy, you will find that < 32meg is typically formatted as 12bit. Common sense just doesn't apply to all situations, I guess. :-D TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." ----------------------------------------------------
2005-11-10 by Joel Winarske
> does somebody have some good documentations about FAT12/16/32? (And > would share it?) ;-) http://www.ntfs.com/fat-systems.htm Joel
2005-11-10 by Tom Walsh
Sten wrote: >Bill Knight wrote: > > >>On Thu, 10 Nov 2005 15:44:54 -0000, Paul Curtis wrote: >> >> >> >> >>>Hi Bill, >>> >>> >> >> >>>>A pretty good, open-source, no-pay FAT layer is available at >>>><http://alumnus.caltech.edu/~pje/rdcf2.txt>. The >>>>implementation there is limited to FAT16 but can be extended >>>>and has a lot of nice features. >>>> >>>> >> >> >>>FAT12 is more complex than FAT16 when dealing with FAT 12-bit FAT >>>entries that span a sector. A lot of SD cards are formatted FAT12 by >>>default, so FAT16 is no good... Its requirements are also pretty high, >>>requiring a 1K static buffer. The PRLLC implementation (and mine for >>>that matter) can run with a 512-byte static or dynamic buffer. >>> >>> >> >> >>>I'll take a look at this. It's something that I didn't find using >>>Google, which is why I wrote my own implementation that is now part of >>>NetBASIC. >>> >>> >> >> >>>Regards, >>> >>> >> >> >>>-- >>>Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk >>>CrossWorks for MSP430, ARM, AVR and now MAXQ processors >>> >>> >> >>Paul >> I may be off on which FATxxx it supports. It has been a while since >>I last used it. It was written quite a while ago and lacked support >>for larger drives. Best check the docs and code to determine exactly >>what it does support. >> >> >> > >Hello, > >does somebody have some good documentations about FAT12/16/32? (And >would share it?) ;-) > > Sten > > > http://alumnus.caltech.edu/~pje/dosfiles.html -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." ----------------------------------------------------
2005-11-10 by Joel Winarske
> > does somebody have some good documentations about FAT12/16/32? (And > > would share it?) ;-) > > > http://www.ntfs.com/fat-systems.htm Also: http://www.microsoft.com/whdc/system/platform/firmware/fatgen.mspx Joel
2005-11-10 by Tom Walsh
Bill Knight wrote: >On Thu, 10 Nov 2005 15:44:54 -0000, Paul Curtis wrote: > > > >>Hi Bill, >> >> > > > >>>A pretty good, open-source, no-pay FAT layer is available at >>><http://alumnus.caltech.edu/~pje/rdcf2.txt>. The >>>implementation there is limited to FAT16 but can be extended >>>and has a lot of nice features. >>> >>> > > > Still, from looking over that code it appears to be a complete implementation of a FAT filesystem layer. Heh, some of that code looks suspiciously like the code from the Circuit Cellar magazine article back in March 2005. Wonder where they got their source from, eh? Regards, TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." ----------------------------------------------------
2005-11-10 by Bill Knight
On Thu, 10 Nov 2005 14:49:11 -0500, Tom Walsh wrote: >Bill Knight wrote: >>On Thu, 10 Nov 2005 15:44:54 -0000, Paul Curtis wrote: >> >>>Hi Bill, >> >>>>A pretty good, open-source, no-pay FAT layer is available at >>>><http://alumnus.caltech.edu/~pje/rdcf2.txt>. The >>>>implementation there is limited to FAT16 but can be extended >>>>and has a lot of nice features. >>>> >> >Still, from looking over that code it appears to be a complete >implementation of a FAT filesystem layer. Heh, some of that code looks >suspiciously like the code from the Circuit Cellar magazine article back >in March 2005. Wonder where they got their source from, eh? >Regards, >TomW RDCF2 was written back in 1993 and I used portions of it in 2002 so if any code liberation was done... I just rechecked my code and the original code is FAT12. The modifications for FAT16 were pretty easy. The shim necessary to work with logical drives that are partitions on a pseudo hard drive is more work. - Bill
2005-11-10 by rtstofer
--- In lpc2000@yahoogroups.com, "Joel Winarske" <joelw@i...> wrote: > > > > does somebody have some good documentations about FAT12/16/32? (And > > > would share it?) ;-) > > > > > > http://www.ntfs.com/fat-systems.htm > > Also: > > http://www.microsoft.com/whdc/system/platform/firmware/fatgen.mspx > > > Joel > I just ported the FAT32 file system stuff from WinAVR to ARM. I used both of the references above and, at the moment, I can read and follow the chains of files created by WinXP. The files don't have to be defragged but, as a limitation, I only use the short file name. Neither of those specs deals with the issue of creating a file. Do you just go look for a deleted file and use all of its' allocation until you need more? Since you only have the single directory entry, how do you grab allocation units away from other deleted files? How do you find an empty allocation unit in the FAT? How do you insure that you are building a proper short file name from a long one, and vice versa. In FAT32, both are required and the directory entries must be contiguous. There are HUGE holes in both of those docs. So, for my MP3 player, I can only read files based on 8.3 names. Not a good situation. I really want a writable configuration file that will tell the player how to deal with serial commands, telnet commands and the hardware inputs/outputs. At a minimum, I need to tie a file name to an input pin so an effect file will play if a sensor is tripped. I would like to do the configuration interactively via serial or telnet but, as I can't open a file for writing, that isn't happening, yet... It's on back burner until I get the ethernet stuff integrated with the CF and MP3 - maybe next week. Richard
2005-11-10 by Dan Beadle
When you delete an entry in the DIR by writing E5 to the first byte, you
must first deallocate all used sectors.
(If you don't, you have to old DOS problem of lost clusters)
Delete File:
Starting at First Cluster, (from Dir entry)
Walk through the cluster allocation table,
unlinking each cluster from the file (returning to free)
Then mark first byte of file name to E5.
As for writing, it is just the reverse...
Make sure the files does not exist, if it does, delete it per above.
Search the directory for an entry starting in NULL or 0xE5 (previously
deleted)
Fill in your information in that structure. (File names are fixed size,
not null terminated. Pad with blanks)
Find a free cluster from the Cluster Allocation Table.
Put that entry into the Dir.
Mark that cluster as EOF (FFFF) in the CAT
Write the first cluster of information.
If there is more, find another free cluster
Mark the new cluster as EOF in the Cat
Change the EOF on the prior cluster from EOF to point to
this cluster
Repeat till end of file...
Update the directory structure with file size, time (if desired).
_____ From: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On Behalf Of rtstofer Sent: Thursday, November 10, 2005 12:15 PM To: lpc2000@yahoogroups.com Subject: [lpc2000] Re: Cheap SD Flash File System --- In lpc2000@yahoogroups.com, "Joel Winarske" <joelw@i...> wrote: > > > > does somebody have some good documentations about FAT12/16/32? (And > > > would share it?) ;-) > > > > > > http://www.ntfs.com/fat-systems.htm > > Also: > > http://www.microsoft.com/whdc/system/platform/firmware/fatgen.mspx > > > Joel > I just ported the FAT32 file system stuff from WinAVR to ARM. I used both of the references above and, at the moment, I can read and follow the chains of files created by WinXP. The files don't have to be defragged but, as a limitation, I only use the short file name. Neither of those specs deals with the issue of creating a file. Do you just go look for a deleted file and use all of its' allocation until you need more? Since you only have the single directory entry, how do you grab allocation units away from other deleted files? How do you find an empty allocation unit in the FAT? How do you insure that you are building a proper short file name from a long one, and vice versa. In FAT32, both are required and the directory entries must be contiguous. There are HUGE holes in both of those docs. So, for my MP3 player, I can only read files based on 8.3 names. Not a good situation. I really want a writable configuration file that will tell the player how to deal with serial commands, telnet commands and the hardware inputs/outputs. At a minimum, I need to tie a file name to an input pin so an effect file will play if a sensor is tripped. I would like to do the configuration interactively via serial or telnet but, as I can't open a file for writing, that isn't happening, yet... It's on back burner until I get the ethernet stuff integrated with the CF and MP3 - maybe next week. Richard SPONSORED LINKS Microprocessor <http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2 =Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=9 3&.sig=tsVC-J9hJ5qyXg0WPR0l6g> Microcontrollers <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor& w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s =93&.sig=DvJVNqC_pqRTm8Xq01nxwg> Pic microcontrollers <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microproces sor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c =4&s=93&.sig=TpkoX4KofDJ7c6LyBvUqVQ> 8051 microprocessor <http://groups.yahoo.com/gads?t=ms&k=8051+microprocessor&w1=Microprocess or&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c= 4&s=93&.sig=1Ipf1Fjfbd_HVIlekkDP-A> _____ YAHOO! GROUPS LINKS * Visit your group "lpc2000 <http://groups.yahoo.com/group/lpc2000> " on the web. * To unsubscribe from this group, send an email to: lpc2000-unsubscribe@yahoogroups.com <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> . _____ [Non-text portions of this message have been removed]
2005-11-10 by Sten
Thanks to all! This sounds good, but what about Richard's problem concerning file names which are not 8.3 compliant? Is there a problem with this docs? Sten Dan Beadle wrote: > When you delete an entry in the DIR by writing E5 to the first byte, you > must first deallocate all used sectors. > > > > (If you don't, you have to old DOS problem of lost clusters) > > > > Delete File: > > Starting at First Cluster, (from Dir entry) > > Walk through the cluster allocation table, > unlinking each cluster from the file (returning to free) > > Then mark first byte of file name to E5. > > > > > > As for writing, it is just the reverse... > > > > Make sure the files does not exist, if it does, delete it per above. > > > > Search the directory for an entry starting in NULL or 0xE5 (previously > deleted) > > Fill in your information in that structure. (File names are fixed size, > not null terminated. Pad with blanks) > > Find a free cluster from the Cluster Allocation Table. > > Put that entry into the Dir. > > Mark that cluster as EOF (FFFF) in the CAT > > Write the first cluster of information. > > If there is more, find another free cluster > > Mark the new cluster as EOF in the Cat > > Change the EOF on the prior cluster from EOF to point to > this cluster > > > > Repeat till end of file... > > Update the directory structure with file size, time (if desired). > > > > _____ > > From: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On Behalf > Of rtstofer > Sent: Thursday, November 10, 2005 12:15 PM > To: lpc2000@yahoogroups.com > Subject: [lpc2000] Re: Cheap SD Flash File System > > > > --- In lpc2000@yahoogroups.com, "Joel Winarske" <joelw@i...> wrote: > >>>>does somebody have some good documentations about FAT12/16/32? > > (And > >>>>would share it?) ;-) >>> >>> >>>http://www.ntfs.com/fat-systems.htm >> >>Also: >> >>http://www.microsoft.com/whdc/system/platform/firmware/fatgen.mspx >> >> >>Joel >> > > > I just ported the FAT32 file system stuff from WinAVR to ARM. I > used both of the references above and, at the moment, I can read and > follow the chains of files created by WinXP. The files don't have > to be defragged but, as a limitation, I only use the short file name. > > Neither of those specs deals with the issue of creating a file. Do > you just go look for a deleted file and use all of its' allocation > until you need more? Since you only have the single directory > entry, how do you grab allocation units away from other deleted > files? How do you find an empty allocation unit in the FAT? How do > you insure that you are building a proper short file name from a > long one, and vice versa. In FAT32, both are required and the > directory entries must be contiguous. > > There are HUGE holes in both of those docs. So, for my MP3 player, > I can only read files based on 8.3 names. Not a good situation. > > I really want a writable configuration file that will tell the > player how to deal with serial commands, telnet commands and the > hardware inputs/outputs. At a minimum, I need to tie a file name to > an input pin so an effect file will play if a sensor is tripped. I > would like to do the configuration interactively via serial or > telnet but, as I can't open a file for writing, that isn't > happening, yet... It's on back burner until I get the ethernet > stuff integrated with the CF and MP3 - maybe next week. > > Richard > > > > > > > > > SPONSORED LINKS > > Microprocessor > <http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2 > =Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=9 > 3&.sig=tsVC-J9hJ5qyXg0WPR0l6g> > > Microcontrollers > <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor& > w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s > =93&.sig=DvJVNqC_pqRTm8Xq01nxwg> > > Pic microcontrollers > <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microproces > sor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c > =4&s=93&.sig=TpkoX4KofDJ7c6LyBvUqVQ> > > 8051 microprocessor > <http://groups.yahoo.com/gads?t=ms&k=8051+microprocessor&w1=Microprocess > or&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c= > 4&s=93&.sig=1Ipf1Fjfbd_HVIlekkDP-A> > > > > > > > > _____ > > YAHOO! GROUPS LINKS > > > > * Visit your group "lpc2000 > <http://groups.yahoo.com/group/lpc2000> " on the web. > > * To unsubscribe from this group, send an email to: > lpc2000-unsubscribe@yahoogroups.com > <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe> > > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of > Service <http://docs.yahoo.com/info/terms/> . > > > > _____ > > > > [Non-text portions of this message have been removed] > > > > > > Yahoo! Groups Links > > > > > > > -- /************************************************ Do you need a tiny and efficient real time operating system (RTOS) with a preemtive multitasking for LPC2000 or AT91SAM7? http://nanortos.net-attack.de/ Or some open-source tools and code for LPC2000? http://www.net-attack.de/ ************************************************/
2005-11-10 by rtstofer
--- In lpc2000@yahoogroups.com, "Dan Beadle" <dan.beadle@i...> wrote: > > When you delete an entry in the DIR by writing E5 to the first byte, you > must first deallocate all used sectors. I don't think so. If you deallocate at that point, you can never recover the file and an entire aftermarket software industry would crash and burn. I gotta think about this... Perhaps the sectors are unallocated when the directory entry is used for a new file. Anyway, deallocating a used cluster would be done by writing 0x00000000 to the cluster entry in the FAT? > > > (If you don't, you have to old DOS problem of lost clusters) > > > > Delete File: > > Starting at First Cluster, (from Dir entry) > > Walk through the cluster allocation table, > unlinking each cluster from the file (returning to free) Again, by writing 0x00000000? Or is there a linked list of free clusters? If so, I missed that somehow! Or do I just wander around in the FAT looking for a 0x00000000 entry? Maybe the closest one above the current cluster? > > Then mark first byte of file name to E5. > > > > > > As for writing, it is just the reverse... > > > > Make sure the files does not exist, if it does, delete it per above. > > > > Search the directory for an entry starting in NULL or 0xE5 (previously > deleted) > > Fill in your information in that structure. (File names are fixed size, > not null terminated. Pad with blanks) > > Find a free cluster from the Cluster Allocation Table. > > Put that entry into the Dir. > > Mark that cluster as EOF (FFFF) in the CAT > > Write the first cluster of information. Dealing with sectors per cluster along the way... > > If there is more, find another free cluster > > Mark the new cluster as EOF in the Cat > > Change the EOF on the prior cluster from EOF to point to > this cluster > > > > Repeat till end of file... No questions here... > > Update the directory structure with file size, time (if desired). > > Yes, do this in close(); So, what do you do with the remaining bytes in a partially filled sector and the remaining sectors in a partially filled cluster? My tendency from a security point of view would be to fill them with 0's, or my personal favorite 0x5A. Richard
2005-11-11 by Bogdan Teodorescu
Hello, I am not able to open http://alumnus.caltech.edu/~pje/rdcf2.txt` Does anybody knows were to find those files ? Thanks Bogdan ----- Original Message -----
From: "rtstofer" <rstofer@...> To: <lpc2000@yahoogroups.com> Sent: Friday, November 11, 2005 1:17 AM Subject: [lpc2000] Re: Cheap SD Flash File System > --- In lpc2000@yahoogroups.com, "Dan Beadle" <dan.beadle@i...> wrote: >> >> When you delete an entry in the DIR by writing E5 to the first > byte, you >> must first deallocate all used sectors. > > I don't think so. If you deallocate at that point, you can never > recover the file and an entire aftermarket software industry would > crash and burn. I gotta think about this... Perhaps the sectors > are unallocated when the directory entry is used for a new file. > > Anyway, deallocating a used cluster would be done by writing > 0x00000000 to the cluster entry in the FAT? > >> >> >> (If you don't, you have to old DOS problem of lost clusters) >> >> >> >> Delete File: >> >> Starting at First Cluster, (from Dir entry) >> >> Walk through the cluster allocation table, >> unlinking each cluster from the file (returning to free) > > Again, by writing 0x00000000? Or is there a linked list of free > clusters? If so, I missed that somehow! Or do I just wander around > in the FAT looking for a 0x00000000 entry? Maybe the closest one > above the current cluster? > >> >> Then mark first byte of file name to E5. >> >> >> >> >> >> As for writing, it is just the reverse... >> >> >> >> Make sure the files does not exist, if it does, delete it per > above. >> >> >> >> Search the directory for an entry starting in NULL or 0xE5 > (previously >> deleted) >> >> Fill in your information in that structure. (File names are fixed > size, >> not null terminated. Pad with blanks) >> >> Find a free cluster from the Cluster Allocation Table. >> >> Put that entry into the Dir. >> >> Mark that cluster as EOF (FFFF) in the CAT >> >> Write the first cluster of information. > > Dealing with sectors per cluster along the way... > >> >> If there is more, find another free cluster >> >> Mark the new cluster as EOF in the Cat >> >> Change the EOF on the prior cluster from EOF to point > to >> this cluster >> >> >> >> Repeat till end of file... > > No questions here... > >> >> Update the directory structure with file size, time (if desired). >> >> > > Yes, do this in close(); So, what do you do with the remaining > bytes in a partially filled sector and the remaining sectors in a > partially filled cluster? My tendency from a security point of view > would be to fill them with 0's, or my personal favorite 0x5A. > > Richard > > > > > > > > > Yahoo! Groups Links > > > > > >
2005-11-11 by Martin Maurer
Try
http://alumnus.caltech.edu/~pje/rdcf2.txt
It works !
Regards,
Martin
----- Original Message ----- From: "Bogdan Teodorescu" <bteo@...> To: <lpc2000@yahoogroups.com> Sent: Friday, November 11, 2005 7:26 AM Subject: Re: [lpc2000] Re: Cheap SD Flash File System > Hello, > I am not able to open http://alumnus.caltech.edu/~pje/rdcf2.txt` > Does anybody knows were to find those files ? > Thanks > Bogdan > ----- Original Message ----- > From: "rtstofer" <rstofer@...> > To: <lpc2000@yahoogroups.com> > Sent: Friday, November 11, 2005 1:17 AM > Subject: [lpc2000] Re: Cheap SD Flash File System > > >> --- In lpc2000@yahoogroups.com, "Dan Beadle" <dan.beadle@i...> wrote: >>> >>> When you delete an entry in the DIR by writing E5 to the first >> byte, you >>> must first deallocate all used sectors. >> >> I don't think so. If you deallocate at that point, you can never >> recover the file and an entire aftermarket software industry would >> crash and burn. I gotta think about this... Perhaps the sectors >> are unallocated when the directory entry is used for a new file. >> >> Anyway, deallocating a used cluster would be done by writing >> 0x00000000 to the cluster entry in the FAT? >> >>> >>> >>> (If you don't, you have to old DOS problem of lost clusters) >>> >>> >>> >>> Delete File: >>> >>> Starting at First Cluster, (from Dir entry) >>> >>> Walk through the cluster allocation table, >>> unlinking each cluster from the file (returning to free) >> >> Again, by writing 0x00000000? Or is there a linked list of free >> clusters? If so, I missed that somehow! Or do I just wander around >> in the FAT looking for a 0x00000000 entry? Maybe the closest one >> above the current cluster? >> >>> >>> Then mark first byte of file name to E5. >>> >>> >>> >>> >>> >>> As for writing, it is just the reverse... >>> >>> >>> >>> Make sure the files does not exist, if it does, delete it per >> above. >>> >>> >>> >>> Search the directory for an entry starting in NULL or 0xE5 >> (previously >>> deleted) >>> >>> Fill in your information in that structure. (File names are fixed >> size, >>> not null terminated. Pad with blanks) >>> >>> Find a free cluster from the Cluster Allocation Table. >>> >>> Put that entry into the Dir. >>> >>> Mark that cluster as EOF (FFFF) in the CAT >>> >>> Write the first cluster of information. >> >> Dealing with sectors per cluster along the way... >> >>> >>> If there is more, find another free cluster >>> >>> Mark the new cluster as EOF in the Cat >>> >>> Change the EOF on the prior cluster from EOF to point >> to >>> this cluster >>> >>> >>> >>> Repeat till end of file... >> >> No questions here... >> >>> >>> Update the directory structure with file size, time (if desired). >>> >>> >> >> Yes, do this in close(); So, what do you do with the remaining >> bytes in a partially filled sector and the remaining sectors in a >> partially filled cluster? My tendency from a security point of view >> would be to fill them with 0's, or my personal favorite 0x5A. >> >> Richard >> >> >> >> >> >> >> >> >> Yahoo! Groups Links >> >> >> >> >> >> > > > > > > Yahoo! Groups Links > > > > > > > >
2005-11-11 by Ken Wada
--- In lpc2000@yahoogroups.com, Robert Wood <robert.wood@a...> wrote: > > I am no expert on this, but I am lead to believe writing file systems > for flash based storage systems is a tricky business if you want to > get maximum life out of your flash. Apparently, you need to try and > ensure that you write and erase sectors evenly, not just write to > whatever space might be free. > > As far as I understand, the physics of how flash works means that if you > don't watch how you write to the memory, over a period of time - not > only can you wear out the cells you are writing to, but adjacent ones as > well. > > This company: > > http://www.hcc-embedded.com/site.php > > do a very neat, very small footprint flash file system for various > embedded processors - including ARM IIRC. More than $150, but if what > they say is true (and I suspect it is) you will hugely increase the > life of your flash cards. > > Cheers, > > Rob > The key phrase here is 'wear leveling' basically you need to add a flash-access sublayer that implements this. The best way to implement this technology is to add the flash-access sublayer, and to write a driver that makes this sublayer emulate an IDE hard drive. Then everything works really-really well! I currently have implemented this type of technology on a broad range of products using an off-the-shelf FAT16 file system interfaced to an IDE interface to a soldered-on FLASH array using Intel Strata-flash or the Spansion chips. Ken Wada
2005-11-11 by Joel Winarske
> Sten Wrote: > This sounds good, but what about Richard's problem concerning file names > which are not 8.3 compliant? Is there a problem with this docs? It start's on page 28 of the MS fatgen103 document: "As a consequence of this pairing, the short directory entry serves as the structure that contains fields like: last access date, creation time, creation date, first cluster, and size. It also holds a name that is visible on previous versions of MS-DOS/Windows. The long directory entries are free to contain new information and need not replicate information already available in the short entry. Principally, the long entries contain the long name of a file. The name contained in a short entry which is associated with a set of long entries is termed the alias name, or simply alias, of the file." Joel
2005-11-11 by Joel Winarske
> > Sten Wrote: > > This sounds good, but what about Richard's problem concerning file names > > which are not 8.3 compliant? Is there a problem with this docs? > > It start's on page 28 of the MS fatgen103 document: > It also illustrates the Numeric-Tail Generation Algorithm; used to generate a 8.3 compliant name from a long name. Richard can you be more specific on this? Joel
2005-11-11 by rtstofer
--- In lpc2000@yahoogroups.com, "Joel Winarske" <joelw@i...> wrote: > > > Sten Wrote: > > This sounds good, but what about Richard's problem concerning file names > > which are not 8.3 compliant? Is there a problem with this docs? > > It start's on page 28 of the MS fatgen103 document: > > "As a consequence of this pairing, the short directory entry serves as the > structure that contains fields like: last access date, creation time, > creation date, first cluster, and size. It also holds a name that is > visible on previous versions of MS-DOS/Windows. The long directory entries > are free to contain new information and need not replicate information > already available in the short entry. Principally, the long entries contain > the long name of a file. The name contained in a short entry which is > associated with a set of long entries is termed the alias name, or simply > alias, of the file." > > > Joel > Yes, the name conversion is described on pages 30 and 31 of the document. All is well, right up until: "However, one absolutely cannot count on this behavior. In a directory with a very large mix of names of this type, the selection algorithm is optimized for speed and may select another "n" based on the characteristics of short names that end in "~n" and have similar leading name patterns." It sounds like I would have to read all of the directory entries in a directory and sort them. Then try to find a place to merge the new filename that doesn't collide. Iterate the numbering scheme until it works... I guess if I were to write the code to create the short file names I would just follow the yellow brick road and not try to optimize for speed. Heck, I would create what, two or three files a month? Not a big deal. Most of the files will be loaded under WinXP. What is a big deal is to write the entire FAT32 file system. It might be better to back up to FAT16 and live with the 2GB partition size limit. After all, how many sound effect files can a person have? They are, almost be definition, only a very few seconds long so certainly less than 100k bytes. Even a 64MB CF will hold a lot of files! OTOH, I would like to have the long file names. The 8.3 notation just isn't useful when describing an effect file. So it comes down to lazy versus utility. Unless I can find the code already written.
2005-11-11 by David Hawkins
> OTOH, I would like to have the long file names. The 8.3 notation > just isn't useful when describing an effect file. > > So it comes down to lazy versus utility. Unless I can find the code > already written. You could always use another file for 'long names' and have that file map the long name to short 8.3 names. I think this is what some of the older CD burner routines used to do to put long file names onto a CD that only supported 8.3 format. The downside is that you now have to read and write long filenames using a custom WinXP file manager. Not really too difficult with a little bit of Tcl/Tk scripting to read the long filename file, display those file names, and then convert back again to access the device ... Just another option to assist in your laziness :) Dave
2005-11-11 by Bill Knight
On Fri, 11 Nov 2005 14:16:31 -0800, David Hawkins wrote: >> OTOH, I would like to have the long file names. The 8.3 notation >> just isn't useful when describing an effect file. >> >> So it comes down to lazy versus utility. Unless I can find the code >> already written. >You could always use another file for 'long names' and have >that file map the long name to short 8.3 names. >I think this is what some of the older CD burner routines >used to do to put long file names onto a CD that only >supported 8.3 format. >The downside is that you now have to read and write long filenames >using a custom WinXP file manager. Not really too difficult with >a little bit of Tcl/Tk scripting to read the long filename >file, display those file names, and then convert back >again to access the device ... >Just another option to assist in your laziness :) >Dave Another thing to consider is that Microsoft has four patents on the VFAT file system which is the layer that adds long filename support to the original FAT file system. See http://www.internetnews.com/bus-news/article.php/3415871 for some additional info. I am sure there is much more available on the net. Regards -Bill Knight R O SoftWare & http://www.theARMPatch.com
2005-11-11 by rtstofer
> > Another thing to consider is that Microsoft has four patents on the > VFAT file system which is the layer that adds long filename support > to the original FAT file system. See > http://www.internetnews.com/bus-news/article.php/3415871 > for some additional info. I am sure there is much more available on > the net. > > Regards > -Bill Knight > R O SoftWare & > http://www.theARMPatch.com > Yes but my code would NEVER be commercial. I have no interest in developing anything for anybody. I have wandered all over Google and found a couple of sites but the code is limited in one way or another. I am beginning to wonder if anyone has bothered with FAT32 outside of Windows and Linux. Then again, maybe there isn't a need for much of a file system outside of Windows and Linux. I am going to download the source for newlib and gnuarm and see what assumptions they made for functions like fopen, fclose, etc. Maybe I'll find a hint. Maybe there is a way to yank the code from Linux. Or, maybe just a lookup table. Or even a proprietary database and virtual storage. Actually, virtual memory looks like an easy way to go. Just one huge file. I like this... Just kicking it around... Richard
2005-11-11 by David Hawkins
> I am beginning to wonder if > anyone has bothered with FAT32 outside of Windows and Linux. Then > again, maybe there isn't a need for much of a file system outside of > Windows and Linux. > > I am going to download the source for newlib and gnuarm and see what > assumptions they made for functions like fopen, fclose, etc. Maybe > I'll find a hint. Check out Red Hat's RTOS eCOS too, and perhaps the RTEMS RTOS. They both implement the POSIX API and probably include file system support for FAT - I'm not sure which versions, but it shouldn't take you too long to check it out. Dave
2005-11-12 by Gus
The licence for FAT is $0.25 per product Gus --- In lpc2000@...m, "Bill Knight" <BillK@t...> wrote: > > On Fri, 11 Nov 2005 14:16:31 -0800, David Hawkins wrote: > > > >> OTOH, I would like to have the long file names. The 8.3 notation > >> just isn't useful when describing an effect file. > >> > >> So it comes down to lazy versus utility. Unless I can find the code > >> already written. > > >You could always use another file for 'long names' and have > >that file map the long name to short 8.3 names. > > >I think this is what some of the older CD burner routines > >used to do to put long file names onto a CD that only > >supported 8.3 format. > > >The downside is that you now have to read and write long filenames > >using a custom WinXP file manager. Not really too difficult with > >a little bit of Tcl/Tk scripting to read the long filename > >file, display those file names, and then convert back > >again to access the device ... > > >Just another option to assist in your laziness :) > > >Dave > > > Another thing to consider is that Microsoft has four patents on the > VFAT file system which is the layer that adds long filename support > to the original FAT file system. See > http://www.internetnews.com/bus-news/article.php/3415871 > for some additional info. I am sure there is much more available on
> the net. > > Regards > -Bill Knight > R O SoftWare & > http://www.theARMPatch.com >
2005-11-12 by rtstofer
--- In lpc2000@yahoogroups.com, "Martin Maurer" <mailingliste@c...> wrote: > > Try > > http://alumnus.caltech.edu/~pje/rdcf2.txt > > It works ! > > Regards, > > Martin It looks like rdcf2 is quite complete and includes a test suite. It supports FAT12 and FAT16 and the documentation is very good. It can also be built under DOS with TurboC so I can play with it on my DOS box before I port it to the LPC2106. Moving back to FAT16 versus getting nowhere with FAT32 seems like a good tradeoff. Thanks for the link! Richard
2005-11-12 by Joel Winarske
> The licence for FAT is $0.25 per product There's a $10k buy-in...
2005-11-12 by Tom Walsh
rtstofer wrote: >--- In lpc2000@yahoogroups.com, "Martin Maurer" <mailingliste@c...> >wrote: > > >>Try >> >>http://alumnus.caltech.edu/~pje/rdcf2.txt >> >>It works ! >> >>Regards, >> >> Martin >> >> > >It looks like rdcf2 is quite complete and includes a test suite. It >supports FAT12 and FAT16 and the documentation is very good. > >It can also be built under DOS with TurboC so I can play with it on >my DOS box before I port it to the LPC2106. > >Moving back to FAT16 versus getting nowhere with FAT32 seems like a >good tradeoff. > > > The alloc() and free() function calls have to be written out. Otherwise we are in danger of fragmenting the RAM on the LPC2000 processors. TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." ----------------------------------------------------
2005-11-12 by rtstofer
--- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote: > > rtstofer wrote: > > >--- In lpc2000@yahoogroups.com, "Martin Maurer" <mailingliste@c...> > >wrote: > > > > > >>Try > >> > >>http://alumnus.caltech.edu/~pje/rdcf2.txt > >> > >>It works ! > >> > >>Regards, > >> > >> Martin > >> > >> > > > >It looks like rdcf2 is quite complete and includes a test suite. It > >supports FAT12 and FAT16 and the documentation is very good. > > > >It can also be built under DOS with TurboC so I can play with it on > >my DOS box before I port it to the LPC2106. > > > >Moving back to FAT16 versus getting nowhere with FAT32 seems like a > >good tradeoff. > > > > > > > The alloc() and free() function calls have to be written out. Otherwise > we are in danger of fragmenting the RAM on the LPC2000 processors. > > TomW Yes but many implemtations allocate storage for a predefined maximum number of open files. Not a big deal, these are microcontrollers, not workstations. I need to correct myself re: RDCF2. I compiled it and it executes well when installed on a floppy and interacting with a floppy. It does not work from my hard drive whether interacting with the HD where it fails completely or the floppy where it gets just about everything wrong. I traced the hard drive failure to the first call to absread where the code is trying to read absolute sector 0. I have to think about this but I think it is incorrect. In any event, the call fails. Another limitation to RDCF2 is a 32 MB limit so the code is for a very early version of FAT. From the very first paragraph of the doc file: "RDCF is a reentrant and ROMable DOS-compatible file system designed for use with floppy diskettes and hard disk partitions that do not exceed 32 Mbytes in size." Anyway, scrap that version; it doesn't really work. Too bad the $139 FLASH File doesn't include CF support - it is a $49 optional upgrade! Bummer... Richard
2005-11-12 by Sten
Tom Walsh wrote: > rtstofer wrote: > > >>--- In lpc2000@yahoogroups.com, "Martin Maurer" <mailingliste@c...> >>wrote: >> >> >> >>>Try >>> >>>http://alumnus.caltech.edu/~pje/rdcf2.txt >>> >>>It works ! >>> >>>Regards, >>> >>> Martin >>> >>> >> >>It looks like rdcf2 is quite complete and includes a test suite. It >>supports FAT12 and FAT16 and the documentation is very good. >> >>It can also be built under DOS with TurboC so I can play with it on >>my DOS box before I port it to the LPC2106. >> >>Moving back to FAT16 versus getting nowhere with FAT32 seems like a >>good tradeoff. >> >> >> > > The alloc() and free() function calls have to be written out. Otherwise > we are in danger of fragmenting the RAM on the LPC2000 processors. > > TomW > > Does anybody has some experiences in what data rate can be achieved when writing to an SD/MMC card? What is the bottleneck (software/FAT or SPI)? Sten -- /************************************************ Do you need a tiny and efficient real time operating system (RTOS) with a preemtive multitasking for LPC2000 or AT91SAM7? http://nanortos.net-attack.de/ Or some open-source tools and code for LPC2000? http://www.net-attack.de/ ************************************************/
2005-11-12 by seangra
--- In lpc2000@yahoogroups.com, Sten <list@n...> wrote: > > Does anybody has some experiences in what data rate can be > achieved when writing to an SD/MMC card? What is the bottleneck > (software/FAT or SPI)? Ideally the limitation will be on use of the SPI interface. Don't forget that it's 1/4 the speed of talking natively to the MMC card. The file system layer won't add a bottleneck, assuming that you're doing block reads/writes to a contiguous area on the media. I mean once the driver knows where to read/write to, there's very little additional overhead. Not to incite a flame war, but is a FAT file system driver really that complicated? I remember back in the day hacking around with partition tables and allocation tables and copying sectors with a hex editor to fix disk problems, IIRC the filesystem isn't all that complicated, is it? I know FAT32 and VFAT complicate matters, but I think that just basic FAT isn't that difficult. I just can't believe that there is no useful open source FAT driver out there. This file system has been out for 25+ years now, used on 95% of computers in existence... Would it be that hard to fix the other driver found here to overcome the 32MB limit? It likely doesn't work reading the hard drive because the partition table is different than on a floppy. Why wouldn't it work "runinng off of the hard drive" accessing the floppy, if it works "running off of a floppy"?
2005-11-12 by Tom Walsh
rtstofer wrote: >--- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote: > > >>rtstofer wrote: >> >> >> >>>--- In lpc2000@yahoogroups.com, "Martin Maurer" >>> >>> ><mailingliste@c...> > > >>>wrote: >>> >>> >>> >>> >>>>Try >>>> >>>>http://alumnus.caltech.edu/~pje/rdcf2.txt >>>> >>>>It works ! >>>> >>>>Regards, >>>> >>>> Martin >>>> >>>> >>>> >>>> >>>It looks like rdcf2 is quite complete and includes a test suite. >>> >>> >It > > >>>supports FAT12 and FAT16 and the documentation is very good. >>> >>>It can also be built under DOS with TurboC so I can play with it >>> >>> >on > > >>>my DOS box before I port it to the LPC2106. >>> >>>Moving back to FAT16 versus getting nowhere with FAT32 seems like >>> >>> >a > > >>>good tradeoff. >>> >>> >>> >>> >>> >>The alloc() and free() function calls have to be written out. >> >> >Otherwise > > >>we are in danger of fragmenting the RAM on the LPC2000 processors. >> >>TomW >> >> > >Yes but many implemtations allocate storage for a predefined maximum >number of open files. Not a big deal, these are microcontrollers, >not workstations. > >I need to correct myself re: RDCF2. I compiled it and it executes >well when installed on a floppy and interacting with a floppy. > >It does not work from my hard drive whether interacting with the HD >where it fails completely or the floppy where it gets just about >everything wrong. > >I traced the hard drive failure to the first call to absread where >the code is trying to read absolute sector 0. I have to think about >this but I think it is incorrect. In any event, the call fails. > >Another limitation to RDCF2 is a 32 MB limit so the code is for a >very early version of FAT. From the very first paragraph of the doc >file: "RDCF is a reentrant and ROMable DOS-compatible file system >designed for use with floppy diskettes and hard disk partitions that >do not exceed 32 Mbytes in size." > >Anyway, scrap that version; it doesn't really work. > > > No, there is code in there to adapt between 12bit & 16bit FATs.. It does appear to be working, I'm writing files onto a 128Meg MMC image. More testing is needed before I'm confident that what I reworked is doing what it should: write a bunch of 32Meg files and verify contents. TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." ----------------------------------------------------
2005-11-13 by rtstofer
> >I need to correct myself re: RDCF2. I compiled it and it executes > >well when installed on a floppy and interacting with a floppy. > > > >It does not work from my hard drive whether interacting with the HD > >where it fails completely or the floppy where it gets just about > >everything wrong. > > > >I traced the hard drive failure to the first call to absread where > >the code is trying to read absolute sector 0. I have to think about > >this but I think it is incorrect. In any event, the call fails. > > > >Another limitation to RDCF2 is a 32 MB limit so the code is for a > >very early version of FAT. From the very first paragraph of the doc > >file: "RDCF is a reentrant and ROMable DOS-compatible file system > >designed for use with floppy diskettes and hard disk partitions that > >do not exceed 32 Mbytes in size." > > > >Anyway, scrap that version; it doesn't really work. > > > > > > > No, there is code in there to adapt between 12bit & 16bit FATs.. It > does appear to be working, I'm writing files onto a 128Meg MMC image. > More testing is needed before I'm confident that what I reworked is > doing what it should: write a bunch of 32Meg files and verify contents. > > TomW I really don't understand why it doesn't work, I can only report my observation and a 10 minute excursion with the debugger. It is also broken in some regard with file move because it will move a file 'junk' into a subdirectory named 'junk' and then refuse to delete or rename the file; an observation that came about because of the completely off the wall path requirements. If multiple drives are allowed, every path must include a drive. A backslash can never follow a drive specification. These kinds of things are a drag. I understand the issue of not having a current working path (or directory) but it does add a measure of confusion. I saw the code for FAT12 and FAT16 and the differences seem reasonable. The first partition of the HDD I was using was 502 MB FAT16. I'm considering buying the FLASH File driver even though the CF code is an upgrade to the basic price. I'm also considering leaving things as they are. I can read FAT32 and the write requirement may not be worth the effort. It works quite well as it is and until I have FAT32, CF, MP3 and RTOS running I don't know how much memory will be left to implement a complete file system. But several thousand lines of additional code will probably push the limit of the LPC2106. Richard
2005-11-13 by Tom Walsh
rtstofer wrote: >>>I need to correct myself re: RDCF2. I compiled it and it >>> >>> >executes > > >>>well when installed on a floppy and interacting with a floppy. >>> >>>It does not work from my hard drive whether interacting with the >>> >>> >HD > > >>>where it fails completely or the floppy where it gets just about >>>everything wrong. >>> >>>I traced the hard drive failure to the first call to absread >>> >>> >where > > >>>the code is trying to read absolute sector 0. I have to think >>> >>> >about > > >>>this but I think it is incorrect. In any event, the call fails. >>> >>>Another limitation to RDCF2 is a 32 MB limit so the code is for a >>>very early version of FAT. From the very first paragraph of the >>> >>> >doc > > >>>file: "RDCF is a reentrant and ROMable DOS-compatible file system >>>designed for use with floppy diskettes and hard disk partitions >>> >>> >that > > >>>do not exceed 32 Mbytes in size." >>> >>>Anyway, scrap that version; it doesn't really work. >>> >>> >>> >>> >>> >>No, there is code in there to adapt between 12bit & 16bit FATs.. >> >> >It > > >>does appear to be working, I'm writing files onto a 128Meg MMC >> >> >image. > > >>More testing is needed before I'm confident that what I reworked >> >> >is > > >>doing what it should: write a bunch of 32Meg files and verify >> >> >contents. > > >>TomW >> >> > >I really don't understand why it doesn't work, I can only report my >observation and a 10 minute excursion with the debugger. It is also >broken in some regard with file move because it will move a >file 'junk' into a subdirectory named 'junk' and then refuse to >delete or rename the file; an observation that came about because of >the completely off the wall path requirements. > > I'm only interested in the rdcf2.c file, I threw cache.c and file.c away. What I'm doing is interfacing it to file streams of NewLib. I don't need / want long filenames. >If multiple drives are allowed, every path must include a drive. A >backslash can never follow a drive specification. These kinds of >things are a drag. I understand the issue of not having a current >working path (or directory) but it does add a measure of confusion. > >I saw the code for FAT12 and FAT16 and the differences seem >reasonable. The first partition of the HDD I was using was 502 MB >FAT16. > >I'm considering buying the FLASH File driver even though the CF code >is an upgrade to the basic price. I'm also considering leaving >things as they are. I can read FAT32 and the write requirement may >not be worth the effort. It works quite well as it is and until I >have FAT32, CF, MP3 and RTOS running I don't know how much memory >will be left to implement a complete file system. But several >thousand lines of additional code will probably push the limit of >the LPC2106. > > Yeah, My target is an LCP2138, so I have lots of Flash but very little RAM. I am still running the code under the native gcc compiler on the Linux box and don't know how large it will end up once I get it patched into the cross-dev environment. I'll post my results. Regards, TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." ----------------------------------------------------
2005-11-13 by Joel Winarske
Sten wrote: > >Does anybody has some experiences in what data rate can be achieved when >writing to an SD/MMC card? What is the bottleneck (software/FAT or SPI)? Based on the user manual: The minimum divider value on the SSP peripheral is 2. You can run the peripheral clock at CPU speed; 1:1. The SD Card Max clock speed for SPI mode is 25MHz. So if you run the peripheral clock at 50MHz you can potentially access the SD card at the maximum SD SPI frequency. Some FAT implementations use less RAM and more ROM, some feature caching and use quite a bit more RAM. So depending on your requirements and budget you have some optimizing options. Joel
2005-11-13 by Joel Winarske
As referenced from the SanDisk Secure Digital Card Product Manual, version 1.9: **Product Maximum Clock Speed and Burst Rate** MultiMediaCard / Clock Speed / Burst Rate SPI Bus mode 20 MHz 2.5 MB/s MMC 1-bit mode 20 MHz 2.5 MB/s SD Card / Clock Speed / Burst Rate SPI Bus mode 25 MHz 3.125 MB/s SD 1-bit mode 25 MHz 3.125 MB/s SD 4-bit mode 25 MHz 12.5 MB/s Joel
2005-11-13 by rtstofer
--- In lpc2000@yahoogroups.com, "Joel Winarske" <joelw@i...> wrote: > > Sten wrote: > > > >Does anybody has some experiences in what data rate can be achieved when > >writing to an SD/MMC card? What is the bottleneck (software/FAT or SPI)? > > Based on the user manual: > The minimum divider value on the SSP peripheral is 2. You can run the > peripheral clock at CPU speed; 1:1. The SD Card Max clock speed for SPI > mode is 25MHz. So if you run the peripheral clock at 50MHz you can > potentially access the SD card at the maximum SD SPI frequency. > > Some FAT implementations use less RAM and more ROM, some feature caching and > use quite a bit more RAM. So depending on your requirements and budget you > have some optimizing options. > > > Joel > I had it written down but lost it... I think I am moving about 170,000 bytes per second using a Compact Flash (8 bit parallel mode) and an LPC2106. No cache or buffering. I have been thinking about read-ahead since my MP3 player will always play just one file and will always play it all the way through. OTOH, I think I can shovel data at 10 times the rate required so why bother? The Rogue Robotics uMP3 player uses SD and an Atmel ATmega128L so it is running at 8 MHz, using SPI and it can still keep up with the MP3 data rate of ABOUT 1 MB per minute. or 16kB per second. My development board is in complete disarray at the moment or I would just rerun the timing tests. But I think the 170kB is correct. Richard
2005-11-13 by rtstofer
There is another FAT16 library here: http://alexfru.narod.ru/os/fat/fat.html It is very complete with the exceptions noted for FAT32. Essentially the library doesn't deal with long file names. Also included is a substantial C library although I'm not sure why that is necessary. Richard
2005-11-13 by Tom Walsh
rtstofer wrote: >I'm considering buying the FLASH File driver even though the CF code >is an upgrade to the basic price. I'm also considering leaving >things as they are. I can read FAT32 and the write requirement may >not be worth the effort. It works quite well as it is and until I >have FAT32, CF, MP3 and RTOS running I don't know how much memory >will be left to implement a complete file system. But several >thousand lines of additional code will probably push the limit of >the LPC2106. > > > I can read & write files larger than 32Meg. What took me a while to figure out was why my converted RDCF2 code was not utilizing the whole drive. I would come up with 30720 bytes free (60 sectors unused), even though my code said otherwise. =============== begin =============== [tom@jtag ~]$ ls -lh /mnt/removeable/ ; df --block-size=1 /mnt/removeable/ total 120M -rwxr--r-- 1 tom tom 8.0M Nov 13 04:16 cheezbit.txt* -rwxr--r-- 1 tom tom 30K Nov 13 04:16 fails.txt* -rwxr--r-- 1 tom tom 3.9K Nov 6 00:00 lseek_r.c* -rwxr--r-- 1 tom tom 74K Jan 1 1980 main2138.lst* -rwxr--r-- 1 tom tom 40M Nov 13 04:15 whippie.txt* -rwxr--r-- 1 tom tom 32M Nov 13 04:16 whompie.txt* -rwxr--r-- 1 tom tom 40M Nov 13 04:14 whoopie.txt* Filesystem 1B-blocks Used Available Use% Mounted on /dev/sdc1 125632512 125632512 0 100% /mnt/removeable =============== snip ================ TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." ----------------------------------------------------
2005-11-13 by Joel Winarske
> There is another FAT16 library here: > http://alexfru.narod.ru/os/fat/fat.html It is very complete with the > exceptions noted for FAT32. Essentially the library doesn't deal with > long file names. I just ran across this: http://freedos-32.sourceforge.net/showdoc.php?page=fat Source download: http://tinyurl.com/9ulq3 Joel
2005-11-13 by Joel Winarske
Some informative links that reference LFN/VFAT: http://home.no.net/tkos/info/fat.html http://hjem.get2net.dk/rune_moeller_barnkob/filesystems/vfat.html http://www.maverick-os.dk/FileSystemFormats/VFAT_LongFileNames.html http://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html Joel
2005-11-14 by Bryce Schober
On 11/12/05, rtstofer <rstofer@...> wrote: > > --- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote: > > > > rtstofer wrote: > > > > >--- In lpc2000@yahoogroups.com, "Martin Maurer" > <mailingliste@c...> > > >wrote: > > > > > > > > >>Try > > >> > > >>http://alumnus.caltech.edu/~pje/rdcf2.txt<http://alumnus.caltech.edu/%7Epje/rdcf2.txt> > > >> > > >>It works ! > > >> > > >>Regards, > > >> > > >> Martin > > >> > > >> > > > > > >It looks like rdcf2 is quite complete and includes a test suite. > It > > >supports FAT12 and FAT16 and the documentation is very good. > > > > > >It can also be built under DOS with TurboC so I can play with it > on > > >my DOS box before I port it to the LPC2106. > > > > > >Moving back to FAT16 versus getting nowhere with FAT32 seems like > a > > >good tradeoff. > > > > > > > > > > > The alloc() and free() function calls have to be written out. > Otherwise > > we are in danger of fragmenting the RAM on the LPC2000 processors. > > > > TomW > > Yes but many implemtations allocate storage for a predefined maximum > number of open files. Not a big deal, these are microcontrollers, > not workstations. > > I need to correct myself re: RDCF2. I compiled it and it executes > well when installed on a floppy and interacting with a floppy. > > It does not work from my hard drive whether interacting with the HD > where it fails completely or the floppy where it gets just about > everything wrong. > > I traced the hard drive failure to the first call to absread where > the code is trying to read absolute sector 0. I have to think about > this but I think it is incorrect. In any event, the call fails. > > Another limitation to RDCF2 is a 32 MB limit so the code is for a > very early version of FAT. From the very first paragraph of the doc > file: "RDCF is a reentrant and ROMable DOS-compatible file system > designed for use with floppy diskettes and hard disk partitions that > do not exceed 32 Mbytes in size." > > Anyway, scrap that version; it doesn't really work. > > Too bad the $139 FLASH File doesn't include CF support - it is a $49 > optional upgrade! Bummer... > > Richard Look at http://www.prllc.com/productcart/pc/viewCat_P.asp?idCategory=10 and you'll see that they've simply separated their physical media support. You can get FAT+CF for $139 or FAT+MMC/SD for $139 or FAT+CF/MMC/SD for $188. SPONSORED LINKS > Microprocessor<http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=tsVC-J9hJ5qyXg0WPR0l6g> > Microcontrollers<http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=DvJVNqC_pqRTm8Xq01nxwg> Pic > microcontrollers<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=TpkoX4KofDJ7c6LyBvUqVQ> 8051 > microprocessor<http://groups.yahoo.com/gads?t=ms&k=8051+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=1Ipf1Fjfbd_HVIlekkDP-A> > ------------------------------ > YAHOO! GROUPS LINKS > > > - Visit your group "lpc2000 <http://groups.yahoo.com/group/lpc2000>" > on the web. > - To unsubscribe from this group, send an email to: > lpc2000-unsubscribe@yahoogroups.com<lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe> > - Your use of Yahoo! Groups is subject to the Yahoo! Terms of > Service <http://docs.yahoo.com/info/terms/>. > > > ------------------------------ > -- Bryce Schober [Non-text portions of this message have been removed]
2005-11-14 by rtstofer
> Look at http://www.prllc.com/productcart/pc/viewCat_P.asp? idCategory=10 and > you'll see that they've simply separated their physical media support. You > can get FAT+CF for $139 or FAT+MMC/SD for $139 or FAT+CF/MMC/SD for $188. It makes sense it would be that way but I wasn't prepared to spend money so I didn't pursure it further. I have another project coming up where a complete file system would be very useful. I'll give it a try.
2005-11-15 by latheef
Hi, Can you tell me how to work this code on windows on PC ,so that i can be familiar with the code and then work on target.
----- Original Message -----
From: Bryce Schober
To: lpc2000@yahoogroups.com
Sent: 2005 Nov 14 10:06 PM
Subject: Re: [lpc2000] Re: Cheap SD Flash File System
On 11/12/05, rtstofer <rstofer@...> wrote:
>
> --- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:
> >
> > rtstofer wrote:
> >
> > >--- In lpc2000@yahoogroups.com, "Martin Maurer"
> <mailingliste@c...>
> > >wrote:
> > >
> > >
> > >>Try
> > >>
> > >>http://alumnus.caltech.edu/~pje/rdcf2.txt<http://alumnus.caltech.edu/%7Epje/rdcf2.txt>
> > >>
> > >>It works !
> > >>
> > >>Regards,
> > >>
> > >> Martin
> > >>
> > >>
> > >
> > >It looks like rdcf2 is quite complete and includes a test suite.
> It
> > >supports FAT12 and FAT16 and the documentation is very good.
> > >
> > >It can also be built under DOS with TurboC so I can play with it
> on
> > >my DOS box before I port it to the LPC2106.
> > >
> > >Moving back to FAT16 versus getting nowhere with FAT32 seems like
> a
> > >good tradeoff.
> > >
> > >
> > >
> > The alloc() and free() function calls have to be written out.
> Otherwise
> > we are in danger of fragmenting the RAM on the LPC2000 processors.
> >
> > TomW
>
> Yes but many implemtations allocate storage for a predefined maximum
> number of open files. Not a big deal, these are microcontrollers,
> not workstations.
>
> I need to correct myself re: RDCF2. I compiled it and it executes
> well when installed on a floppy and interacting with a floppy.
>
> It does not work from my hard drive whether interacting with the HD
> where it fails completely or the floppy where it gets just about
> everything wrong.
>
> I traced the hard drive failure to the first call to absread where
> the code is trying to read absolute sector 0. I have to think about
> this but I think it is incorrect. In any event, the call fails.
>
> Another limitation to RDCF2 is a 32 MB limit so the code is for a
> very early version of FAT. From the very first paragraph of the doc
> file: "RDCF is a reentrant and ROMable DOS-compatible file system
> designed for use with floppy diskettes and hard disk partitions that
> do not exceed 32 Mbytes in size."
>
> Anyway, scrap that version; it doesn't really work.
>
> Too bad the $139 FLASH File doesn't include CF support - it is a $49
> optional upgrade! Bummer...
>
> Richard
Look at http://www.prllc.com/productcart/pc/viewCat_P.asp?idCategory=10 and
you'll see that they've simply separated their physical media support. You
can get FAT+CF for $139 or FAT+MMC/SD for $139 or FAT+CF/MMC/SD for $188.
SPONSORED LINKS
> Microprocessor<http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=tsVC-J9hJ5qyXg0WPR0l6g>
> Microcontrollers<http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=DvJVNqC_pqRTm8Xq01nxwg> Pic
> microcontrollers<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=TpkoX4KofDJ7c6LyBvUqVQ> 8051
> microprocessor<http://groups.yahoo.com/gads?t=ms&k=8051+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=1Ipf1Fjfbd_HVIlekkDP-A>
> ------------------------------
> YAHOO! GROUPS LINKS
>
>
> - Visit your group "lpc2000 <http://groups.yahoo.com/group/lpc2000>"
> on the web.
> - To unsubscribe from this group, send an email to:
> lpc2000-unsubscribe@yahoogroups.com<lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
> - Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------
>
--
Bryce Schober
[Non-text portions of this message have been removed]
SPONSORED LINKS Microprocessor Microcontrollers Pic microcontrollers
8051 microprocessor
------------------------------------------------------------------------------
YAHOO! GROUPS LINKS
a.. Visit your group "lpc2000" on the web.
b.. To unsubscribe from this group, send an email to:
lpc2000-unsubscribe@yahoogroups.com
c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
------------------------------------------------------------------------------
[Non-text portions of this message have been removed]2005-11-15 by rtstofer
--- In lpc2000@yahoogroups.com, "latheef" <abdull@b...> wrote: > > Hi, > > Can you tell me how to work this code on windows on PC ,so that i can be familiar with the code and then work on target. Not really... I built it using Borland's Turbo C (for which it is already configured) under DOS. I moved the executable to a floppy and it works pretty well - on the floppy. It doesn't work, for me anyway, on the hard drive. I haven't pursued the matter because there are other, more current, sources. Richard
2005-11-16 by sashi ono
Can Someone who has done it, just post the FAT/16 SD code up in files, so we can be done with this thread :)
2005-11-16 by Tom Walsh
sashi ono wrote: >Can Someone who has done it, just post the FAT/16 SD code up in files, >so we can be done with this thread :) > > > > Tired of waiting for the other shoe to drop, eh? ;-) I've got the RDCF2 code running now on the LPC2138. It's gone through some pretty heavy testing so far, the code is not perfect (it will thrash when deleting a file), but it seems rock solid. I'm accessing it through NewLib using the fopen(), fread(), etc, library functions. And, the new MMC driver routines are solid as well. Overall I'm pleased with the results, oh, and it made a 300Meg file on the 1Gig MMC card that I have. It took it nearly 2 hours to fill the file... I'll be releasing it very shortly (source + a project), real soon now. I've started on a webpage last night and pulling together the sources from within my project (project is proprietary, the RDCF2 is mine). TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net, http://cyberiansoftware.com "Windows? No thanks, I have work to do..." ----------------------------------------------------