Where should I discuss SD/MMC FAT issues?

[JD123]

Hey there guys and gals, new poster here, long time tinker of PBP.

Where (what forum) should I post questions and issues revolving around SD/MMC FAT16 and FAT32? My project could use the memory card as a bit-bucket and then 232 the data out, but I'd rather have the cards PC readable.

For the first time ever, I've bit-banged an MMC card into submission using a 16F876A. I'm finally in and reading data after about 5 hours of chit (not including the hardware), but working with FAT's is giving me a migraine. I guess I don't really know what questions to ask right now as I'm still learning the FAT structure. I'm still trying to sort out the strait-line math 2^x AND (2^z(y+1) >> 7) ... etc. ... yadi, yadi, yadi... just to find the next location of the next math nightmare.

Just would like to know where would be the best place for this topic?

Thanks,

Gary

[BrianT]

Hi JD123,

I am also trying to use a MMC card as a large data store that MUST be PC readable. I bought some development hardware from Ron Diol at Compsys a year back but the project got pushed aside by the urgent driving out the important. Ron was very helpful and there are some good links there.

http://www.compsys1.com/workbench/On...c_project.html

http://elm-chan.org/docs/mmc/mmc_e.html


I am thinking along the lines of preformatting the SD/MMC card in FAT 16 or 32 and loading two files of known names on the card. The SPI mode does not require any CRC calculations (I think) and is plenty fast enough for my needs.

The PIC code would open one file and append the latest data. It would close that file and open the second file, write the same code a second time and close. The two file are so if the card is removed while a file is still open, the data should be recoverable from the other file. No doubt there are better ways.

I want to keep the PIC side code as lean as possible and I can always preformat the cards but the final data must be directly readable by a PC.


Please keep this going in any forum as I think it will be a pretty interesting thread as you get it all going.

Cheers
BrianT

[JD123]

Hi Brian,

This is where I'm at. I can format the MMC on the PC, make a singel file using the PC, find the directory listing for the file using the PIC, find the file using the PIC, read and modify the file on the PIC and read the results on the PC via the MMC card reader.

What I now need to do is modify the directory listing to reflect the changes made to the file, so that the PC can understand the file information correctly. For example, I originally made the file "TEST123.TXT" 10 bytes long with the string "1234567890" so that it was easy to search the MMC to locate the file. As I made changes to the file using the PIC, if I went over the original 10 byte length, the data gets recorded, but the PC only sees the original first 10 bytes.

I found the file size information in the directory listing at offset 28 and this falls into what I was expecting based on that I've read. Problem is that the file size information is a 4 byte Dword and FAT specs call for the 4 bytes to START at offset 28. In reality, I would have thought that the "10" for the file size would have been in offset 31 (LSByte of the 4 bytes). I'm trying to figure out where I place the additional 3 bytes of the file size information. I can't find anything to support that the file size should be written low byte first and that wouldn't make sense anyway. So, I'm thinking that there's something wrong with my understanding of where the bytes are stored.

Anyway, this is where I was last night. I was tickled-pink just to see that I could get the PIC to make changes to the MMC that the PC could read. One thing that became real clear last night was that I'll have no choice but to add RAM to my hardware. I've got to be able to work on a sector's individual bytes and that's only going to happen if I have it in RAM and then send it back to the MMC when I'm done tinkering with the sector. I happen to have some 64KBit I2C EEPROMS handy, so tonight I'll press one of them into service on the proto board. This alone will put the breaks on FAT work for a few days (I only get a few hours a day to 'play' with PICs) while I deal with the hardware and I2C code.

I'll post updates as they come. If anyone can help me understand the offset location and data style (MSB or LSB first) of the file size data I'd appreciate reading your thoughts.

Gary

Edit: Brian, I forgot to say thanks for the links. I've been to both before and the second one was very helpful in getting me started.
--

[skimask]

I found the file size information in the directory listing at offset 28 and this falls into what I was expecting based on that I've read. Problem is that the file size information is a 4 byte Dword and FAT specs call for the 4 bytes to START at offset 28. In reality, I would have thought that the "10" for the file size would have been in offset 31 (LSByte of the 4 bytes). I'm trying to figure out where I place the additional 3 bytes of the file size information. I can't find anything to support that the file size should be written low byte first and that wouldn't make sense anyway. So, I'm thinking that there's something wrong with my understanding of where the bytes are stored.

Isn't the file size in FAT32 stored at 2 different places? And both of them have to be identical? I forget...it's been awhile since I read the FAT32 documentation...

I'll have no choice but to add RAM to my hardware.

I built an MP3 player awhile back based off an 18F4620 reading from CF cards in IDE mode. Had enough ram to buffer 6 complete sectors with room left over for a load of variables.
Also, if that's not enough, look into the F-RAM options. Serial EEPROM just like a 24C256 type, but it's ram, read/write just as fast, not slow writes/fast reads like eeprom, and practically unlimited lifetime.

understand the offset location and data style (MSB or LSB first) of the file size data I'd appreciate reading your thoughts.

Keep track of your little and big ENDIAN formats according to the FAT32 documentation. I don't know how many times that sort of thing tripped me up bad...

EDIT: Just dug out the FAT32 doc file.
Is the file you're basing your FAT32 code from called 'fatgen103.doc'?
If so, that file has a few issues in itself, wrong places for some values, some values omitted, and so on...
gain, it's been awhile. I'll see if I can't dig up the specifics.

[JD123]

Hi Skimask,

Isn't the file size in FAT32 stored at 2 different places? And both of them have to be identical? I forget...it's been awhile since I read the FAT32 documentation...

Sorry, I forgot to say that I'm using FAT16 when I format the MMC. It's the native format that the MMC's came with. I don't know what version of FAT16 I'm using. I understand there at least several versions or revisions to the FAT16 system. The MMC's I'm using are 128MB in size.

...look into the F-RAM options.

Yes, for a final in-field application this would be the way to go. As it is, I'm cheap and have the EEPROM's on hand. My application is data recording at about 100 sectors a second. For writing the data it will be sent directly to the card. The EEPROM use in my ap would only be at the first and end of the recording events (about 10-15 minutes long) and this would be just to address the FAT issues.

I'm back off to some of my web haunts where I've been reading about FAT16. Maybe I'll find the answer by going back over these sites. I do have this odd recollection of there being some part of the FAT where data is written LSByte first. Maybe it was the file size?

Gary
--

[skimask]

Sorry, I forgot to say that I'm using FAT16 when I format the MMC.

That fat32 document has a load of info in it, and specifies where it differ's from fat16...not that it matters much

My application is data recording at about 100 sectors a second.

I was able to shove a bit over 600K/sec into the CF card on my player, but that's using the IDE mode, parallel data transfer. 600K was as fast as the PIC could go @ 40Mhz.
You'll be limited to the max SPI speed, and I think you'll be lucky to be able to handle 100 sectors/second (100 sectors = 512000 bytes = 5.12mbps) and still have any time leftover to do any sort of interrupt processing.

I do have this odd recollection of there being some part of the FAT where data is written LSByte first. Maybe it was the file size?

Do a search for fatgen103.doc and you'll see what I'm looking at.
And yes, offset 28 is the file size, and yes, it is LSB first...little endian...