 |
 |
| View previous topic :: View next topic |
| Author |
Message |
neochrome32
Joined: 09 Jun 2013
Posts: 153
|
| "My own filesystem" what should I take into accoun |
 Posted: Fri Sep 05, 2014 10:08 pm |
 |
|
ok, its a little ambitious i know, but I'm forever finding references to Fat32 being a MS patents.. which to be fair is ok for my own projects... BUT i want to design a very very basic filesystem, allows for creating/delete files/director, folders and a format (which is pretty much on every OS ever right?) ANYWAYS
I want to design something that doesn't have to worry about SDCARDS being less than 1GIG and no more than 4GIG (32bit FS is just fine for what i need).
I realise, that in terms of what i need, on ANY basic FS you need clusters pointers, sector points and file /folder headers and file/folder atttribs..
I've looked up on many data sheets on this topic, but frankly, they're ALL over the top for something as basic as this..
I need filenames 32 letters at least, but i don't know how to handle the directory structure?
EG.
ROOT:/root/os/media/foo.txt
Would a directory and a name that has the attrib of a folder just have another sector/cluster pointer?
(sorry for not making sense)
Thank you for any advice... |
|
 |
asmallri
Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia
|
| Re: "My own filesystem" what should I take into ac |
| Posted: Fri Sep 05, 2014 10:55 pm |
|
|
| neochrome32 wrote: | ok, its a little ambitious i know, but I'm forever finding references to Fat32 being a MS patents.. which to be fair is ok for my own projects... BUT i want to design a very very basic filesystem, allows for creating/delete files/director, folders and a format (which is pretty much on every OS ever right?) ANYWAYS
I want to design something that doesn't have to worry about SDCARDS being less than 1GIG and no more than 4GIG (32bit FS is just fine for what i need).
I realise, that in terms of what i need, on ANY basic FS you need clusters pointers, sector points and file /folder headers and file/folder atttribs..
I've looked up on many data sheets on this topic, but frankly, they're ALL over the top for something as basic as this..
I need filenames 32 letters at least, but i don't know how to handle the directory structure?
EG.
ROOT:/root/os/media/foo.txt
Would a directory and a name that has the attrib of a folder just have another sector/cluster pointer?
(sorry for not making sense)
Thank you for any advice... |
Do you need to be able to read the media in some other device, such as a PC? If not then you do not need to use the FAT file system and instead can treat the SD card as basically a large eeprom but with the restriction that writes occur in 512 byte blocks on 512 byte boundaries. Microchip have an example of a very (crude) file system for use with EEPROMs. You could modify their code to add the required 512 byte buffer. Be aware that EEPROMS have significantly better flash endurance than an SD card. You could write up to 1,000,000 to an EEPROM location with confidence but you would kill a SD card by writing to the same 512 byte block with just 1/10 that number of writes.
If you do need to have the card with your proprietary file system read by an external device then you will need to write a driver for the other devices so they can interact with your file system.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19546
|
|
| Posted: Fri Sep 05, 2014 11:52 pm |
|
|
The legality of things is very 'blurred'....
Have a look at the Wikipedia entry on this. It is quite good, and 99% accurate. You can use FAT-16 up to 4GB (this was done in Win NT), and this can be read by all current MS OS's and Linus etc.. The big patent, is not FAT32, but is extended file name handling (VFAT). It is this that MS protects, and provided you are happy to stick with short file names, you can avoid this.
Realistically just go with FAT16, unless the large cluster size will be a problem. MS 'released' this to the public domain some years ago, and it is far easier to keep with things that are standard. |
|
|
neochrome32
Joined: 09 Jun 2013
Posts: 153
|
|
| Posted: Sat Sep 06, 2014 2:27 am |
|
|
hmm would i be allowed to store the LONG name in the file somewhere on the system then?
i dont mind short files appearing on windows devices (to be fair short names on the device either)
BUT to avoid using the VFAT, i could write the long names in a hidden text file somewhere lol...
FAT16 is ok and all, but i just about got the Fat32 working! LOL
currently im stuck with a directory create issue now tho.
the following code i was able to put together after reading some FAT32 stuff, currently i can only make ONE directory on the root folder, if i try to create anymore folders, it just renames the current one! LOL
i wrote a really poor mkdir function with SOME results, but if youd take a look to see what im missing?
thank you 
| Code: |
void mk_dir(char *fname){
DIR *pDir;
int32 actsector,actcl;
int16 i;
//if (f > (MAXFILES-1)) return FALSE;
if(gFile.free==false) return ;
if (gFAT32Vars.gFirstDirEntryCluster == 0x0FFFFFFF) {
// extend the directory file !!!
gFAT32Vars.gFirstDirEntryCluster = FindFirstFreeCluster();
gFAT32Vars.gFirstEmptyDirEntry = 0;
SetClusterEntry(gFile.CurrentCluster,gFAT32Vars.gFirstDirEntryCluster);
SetClusterEntry(gFAT32Vars.gFirstDirEntryCluster,0x0FFFFFFF);
actsector = gFAT32Vars.gFirstDirEntryCluster + gFAT32Vars.gFirstDataSector;
for (i=0;i<MMCSD_MAX_BLOCK_SIZE;i++)
gFile.IOpuffer[i] = 0;
WriteSector(actsector,gFile.IOpuffer);
}
actsector = gFAT32Vars.gFirstDirEntryCluster + gFAT32Vars.gFirstDataSector;
ReadSector(actsector,gFile.IOpuffer);
pDir = (DIR*)(&(gFile.IOpuffer[32*gFAT32Vars.gFirstEmptyDirEntry]));
gFile.dirSector = actsector;
gFile.dirIdx = gFAT32Vars.gFirstEmptyDirEntry;
GetDOSName(pDir,fname);
pDir->bAttr = 0x10; // a fecking dir
actcl = FindFirstFreeCluster();
pDir->hCluster = actcl & 0xFFFF;
pDir->hClusterH = actcl >> 16;
SetClusterEntry(actcl,0x0FFFFFFF);
pDir->wSize = 0;
gFile.position = 0;
pDir->hDate = GetCurrentDOSDate();
pDir->hTime = GetCurrentDOSTime();
WriteSector(actsector,gFile.IOpuffer); // writes the sector, to the parent directory
memcpy(&(gFile.DirEntry),pDir,32);
// now need to create the folder infos next
//[.]// needs to know its own cluster pointer
//[..]// needs to know its parent cluster
gFile.position = 0;
actsector = ComposeCluster();
actsector += gFAT32Vars.gFirstDataSector;
ReadSector(actsector,gFile.IOpuffer);
gFile.CurrentCluster = ComposeCluster();
gFile.posinsector = 0;
for(i=0; i<0x20; i++){
gFile.IOpuffer[i]=0x20;
}
gFile.IOpuffer[0x0B] = 0x10; // we still a folder matey
gFile.IOpuffer[0x20] = 0x00; // we still a folder matey
gFile.IOpuffer[0]='T';
gFile.IOpuffer[1]='E';
gFile.IOpuffer[2]='S';
gFile.IOpuffer[3]='T';
gFile.IOpuffer[4]='E';
gFile.IOpuffer[5]='R';
WriteSector(actsector, gFile.IOpuffer);
// made the link at the top
// now we need to create the bits for this.
// return TRUE;
}
|
|
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia
|
|
| Posted: Sat Sep 06, 2014 5:04 am |
|
|
| neochrome32 wrote: | | hmm would i be allowed to store the LONG name in the file somewhere on the system then? |
Naturally. Microsoft does not have a patent on long files names - these existed on other operating systems long before Microsoft integrated long file names. What you cannot do is use the mechanism Microsoft did by incorporating the long file names split across multiple filename entries in the directory. Exactly how Microsoft was able to patent that rubbish is beyond belief...
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9245
Location: Greensville,Ontario
|
|
| Posted: Sat Sep 06, 2014 5:17 am |
|
|
Why do you 'have' to use long file names? I've used 8.3 since mid 70s and it's never let me down.The key is to have a logical combination of letters,numbers and extensions.
I have a few Vinculum based dataloggers that have thousands of files on them(1 /day) and each is easy to 'decode' as to what it's contents are.
I'm not convinced MS cares about the file system patent infringement as they don't seem to eager to go after 'bootleg' copies of DOS,Windows,Word, etc.
hth
jay |
|
|
neochrome32
Joined: 09 Jun 2013
Posts: 153
|
|
| Posted: Sat Sep 06, 2014 6:00 am |
|
|
long names are helpful for song names and .SID names, its ok to use 8.3 filenames, but i dont want to end up renaming 1000's of songs lol.
im building a JukeMOX it plays .SID files and good old MOD files... the names are pretty easy to get from the files them selfs, but it takes a long time as im only using a 1bit SPI for the SDcard read so , pretty time consuming |
|
|
neochrome32
Joined: 09 Jun 2013
Posts: 153
|
|
| Posted: Sat Sep 06, 2014 7:23 am |
|
|
| is there any merit to the FAT.C drive supplied with CCS C? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19546
|
|
| Posted: Sat Sep 06, 2014 7:38 am |
|
|
It is the Vfat method of implementing LFN's giving reverse compatibility on existing OS's that they patented.
There is no reason you can't implement your own system, and for your own use this is not a problem. However if you marketed a system that did this, it could well be impinging parts of the patent...
I think there is a better way to work for what you want.
Use a hash.
Have a simple text file with your own format allowing long song names to be stored.
Hash the long names to produce a number code, and use this as the filename. Store this in the text file as well. So (say) a int16 hash, and give the corresponding song the filename Snnnnny.xxx where nnnnn is the hash, and xxx is the extension you use for the songs, with 'y' used as an extra digit to handle the case where two hashes match (rare if the hash is well designed).
Then you can select songs from the list, and immediately read their hash, which directly gives the filename. Conversely, from the filename, a direct search in the extra digits in the list, allows you to find the corresponding name.
On the fat.c, it is there, and after a couple of minor tweaks, works. |
|
|
neochrome32
Joined: 09 Jun 2013
Posts: 153
|
|
| Posted: Sat Sep 06, 2014 8:43 am |
|
|
i think i might have to just write my own FileSystem for fun later, but that fat.c it looks complete, i have a working disk IO ..
which parts need to be tweaked?? if you know that is? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19546
|
|
| Posted: Sat Sep 06, 2014 11:12 am |
|
|
| Look in the code library. Asmallri has published the fixes. Some only apply in specific circumstances, but they are minor, and make the code work correctly. |
|
|
neochrome32
Joined: 09 Jun 2013
Posts: 153
|
|
| Posted: Sat Sep 06, 2014 7:55 pm |
|
|
| liking the longname by #hash !! seems to work out well, the only issue im having is, file size, when it gets a bit big, its gonna have to scroll through the names.. i am using external RAM, but thats ment for external media files...... i have 53k of internal but the bank switching is a pain!! |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19546
|
|
| Posted: Sun Sep 07, 2014 12:31 am |
|
|
Given that space is probably not an issue, consider working the other way.
Have a file with (say) 65536 locations for just a song title.
When a title is entered, generate the hash, and look at this location in the file. If the title is there, you go straight to the data file required. If not, you write the new name at this location, and create the new file. |
|
|
neochrome32
Joined: 09 Jun 2013
Posts: 153
|
|
| Posted: Sun Sep 07, 2014 2:50 am |
|
|
your talking about a File based file systems! LOL i like it, from what i've read over the fat32, it is OVER powered for small devices! but i got mkdir to work, its crude.... oddly i just created two files, named . and .. and changed the attribs to 0x10 (directory) after clearing out the sector with 0x00!
lol its crude, but appears to be working! |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19546
|
|
| Posted: Sun Sep 07, 2014 3:26 am |
|
|
No. Think again.
Yes, this approach can be 'file based', but can equally well just be your own single data 'entity'. The point is that the hash defines directly, where you go in the file, or your initial data 'block'. This location can then point to the file, or to another location in your data area. This is how indexes are done on data-bases, and means that instead of having to search for a particular name, you can index directly to it's record(s). |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
