Where should I discuss SD/MMC FAT issues?

[BrianT]

http://www.mmca.org/compliance/buy_s...EDSD84-A43.pdf

Cheers
BrianT

[JD123]

http://www.mmca.org/compliance/buy_s...EDSD84-A43.pdf

Cheers
BrianT

Thanks Brian. I have a copy of that. It reads like the USA budget passed by Congress :0 I couldn't find any information about FAT in the doc, though it may be in there.

Last night I decided to see if I could find a file armed only with the file name. I was able to do it. I started to write a post that cuts to the chase in explaining how I find a file but decided if I was going to get up in the morning, I'd have to finish it later. I'll post it when it's finished. It will be a real time saver for the first-time MMC user.

In short, I only need to read a few items from the MBR, Partition Record and the Directory Table (I think that's all I was reading - it was late). It's not hard once I know what to look for and stay within the structure of the FAT.

[skimask]

Thanks Brian. I have a copy of that. It reads like the USA budget passed by Congress :0 I couldn't find any information about FAT in the doc, though it may be in there.

It's only an MMC document.
I forget, do you have the FAT spec's document? (fatgen103?)

[JD123]

Skimask, yes. I have the one you were talking about and about 10 other pages found on the net. Together it's concise.

Thanks again for the LSB information. As I worked last night, I come to find out that all Word and Dword data that points to an address or its offset are written this way in FAT. I never have used the SWAP function of PBP before, but it's coming in very handy right now.

{4 data bytes, LSB first} D,C,B,A

swap A, D
swap B, C

{4 data bytes, MSB first} A,B,C,D

I understand this is just a work-around for the fact that "I" work with Word & Dword addresses as MSB first. I'm stuck in my ways... what can I say!

[JD123]

Oh, and for what it's worth, I just ordered some FRAM chips from Mouser. That should speed up sector reading a bit. I got 64K's so I can have up to 16 sectors or 4 clusters in RAM at one time. Since it will be so fast (up to 1mhz), I might use it to hold other data too. Having bigger and faster memory is like buying a Ford Excursion after owning a VW Rabbit.

[JD123]

Okay, the F-RAM chip is in place and working. Taking all delays out of the code I can get a sector (517 bytes) of the MMC onto the F-RAM in about 13.5ms (MMC > PIC > I2C). That's much faster than the old I2C. It's nice not having to stop and write the buffer page!

I'm still looking for a faster way to move the I2C data line, so I'm writing my own I2C handler routines. My whole program cycle has to fit into 16.67ms. It doesn't look like I'll be able to load the I2C with sample data then move it to the MMC in this window unless I can get the program cycle, minus the data captures, down to about 6ms. It's going to be close.

[skimask]

I'm still looking for a faster way to move the I2C data line, so I'm writing my own I2C handler routines. My whole program cycle has to fit into 16.67ms. It doesn't look like I'll be able to load the I2C with sample data then move it to the MMC in this window unless I can get the program cycle, minus the data captures, down to about 6ms.

What speed is your osc running at?
I know you can get 500-ish bytes inside of a few ms...
Show some code!