Where should I discuss SD/MMC FAT issues?

[JD123]

YES! I came back here to say I found this, only to see you found it too. The size IS written LSByte first. I can't tell you how many places on the web fail to state this. This is what I just now found:

data length ( =4 bytes ) 

the minimum can be 00 00 00 00 - 0 and the maximum ff ff ff ff -
 4,294,967,295
gb, mb, kb, by

this entry will state the length of data to read in.
eg, AC 3B 96 00
flip these values: 00 96 3B AC
convert to decimal: 9,845,676 bytes or 9.38MB
folders have a value of: 00 00 00 00

Thanks guys for getting me out of this ditch. It's amazing how much time I waste on some of the 'simplest' problems.

skimask, thanks for letting me know what you were able to get for speed. I'm shooting for 100, 8 byte recordings per second, but if I can make 60 I'll be happy. The recordable rate will be selectable and I was picking 100 as a top-shelf goal.

Edit: skimask, sorry... I see what caused the issue about speed. I originally ment to say ONE sector per second, not 600. 600 is the byte rate, not the sector rate. I guess I really WAS pushing the limits, the way I originally stated it!!!

[skimask]

skimask, thanks for letting me know what you were able to get for speed. I'm shooting for 100, 8 byte recordings per second, but if I can make 60 I'll be happy. The recordable rate will be selectable and I was picking 100 as a top-shelf goal.

100 8 byte recordings per second? That's only 800 bytes... I said 600KB per second, as in, 614,400 bytes per second, 6,144,000 bits per second.
But again...it was a parallel operation.

Now are you talking 100 8 bytes recordings...
or 100 512 byte (sector) recordings

[JD123]

100 8 byte recordings per second? That's only 800 bytes... I said 600KB per second, as in, 614,400 bytes per second, 6,144,000 bits per second.
But again...it was a parallel operation.

Now are you talking 100 8 bytes recordings...
or 100 512 byte (sector) recordings

Yes, I messed up. See my edit.

That should be quite reachable. The real issue is reading the PWM outputs from the accelerometers and an airspeed pressure sensor. My co-worker on this project wants to read the PWM as filtered analog resolved from a 1ms PWM frame rate. I'm arguing that I can get everything done and more in the 16.66ms that we have at 60 recordings per second. Also, using the CCP and MUX'ing the inputs I can get rock solid data with a 5000 FS range. On a +/-10G accelerometer that will be .4mG resolution - well enough for what we are doing.

Gary
--

[JD123]

I'm not going to turn this into a thread of me talking to myself, but I wanted to say that I put a 24LC16 on the pic and I'm now reading the directory table into memory, working on it and writing it back to the MMC without any problems. The PC now accepts the modified files with the correct file information from the MMC.

Reading out of the MMC to the I2C takes ~3 seconds for a 512 sector. I'll be getting it faster by coding for loading the 16 byte buffer on the I2C.

[skimask]

The PC now accepts the modified files with the correct file information from the MMC.

So it was the file size issue then?

Reading out of the MMC to the I2C takes ~3 seconds for a 512 sector. I'll be getting it faster by coding for loading the 16 byte buffer on the I2C.

Post some code. I'm sure there's a way to make it faster... It only took my code about 7-ish seconds to erase a full 24LC256 (32Kbytes), while displaying the current address on an LCD.

[JD123]

I'll post the code if you promise not to laugh. When I'm in the R&D phase my goal is to understand, not to write pretty code. All I'm doing right now is building a reference for dealing with the MMC when I make a final application.

I'm at work (work has nothing to do with PICs) and the files are at home. No internet at home (yes, I live in a cave... next-door to Osama) so it will be a day or two before I get it up. Most likely I'll have the code faster by then as tonight I'll probably change it to write the page buffer on the I2C memory. I started with the recommended 10ms delay after a write and once things were stable, I moved it to 5ms. Next step will be polling for busy for the shortest delays.

[skimask]

I'll post the code if you promise not to laugh.

The difference between R&D code and pretty code is....who cares...

Most likely I'll have the code faster by then as tonight I'll probably change it to write the page buffer on the I2C memory. I started with the recommended 10ms delay after a write and once things were stable, I moved it to 5ms. Next step will be polling for busy for the shortest delays.

5ms is max. write cycle time for the 24LC16 (byte or page).
You start writing 16 byte pages, and it should speed up by a factor of about 16, with the same 5ms delay after the 16 byte packet is sent out.