Where should I discuss SD/MMC FAT issues?

[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!

[JD123]

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

Codes at home. The proto board is running at 16mhz and the final version will run at 20mhz.

I know what's slowing it down. In my rush to write the code (I wanted to see if this F-RAM really was a drop-in replacement for the 24C64's), I simply re-addressed the I2C for every write and this is sending way too many bits per write. It's kicking out 48 bits per byte write yet my I2C handler will send out 9 bits per byte (after a one-time command/address string) and at about twice the clocking speed. That will bring the data transfer rate up to about 10 times faster overall.

I was about to go ahead and write a variable string of say 16 bytes per I2C_WRITE to speed things up, but decided not to waste my time, knowing I'd sooner or later bit-bang the I2C for the fastest results. I'm writing the I2C handler to run at the 20mhz speeds, so what I get at 16mhz will be off of top possible speeds by 20%.

I should get the simple use of my I2C handler finished tonight. It would have been done last night, but I went to bed early. I've been puting in some long days the past few weeks thanks to this project. I'll see if I can remember to bring some code to work to post. I think it's about 500 lines now (text editor lines, not instruction lines) but should be easy to follow because I tab, space and sub block in logical places, except when I'm debugging fast. The code is still full of unnecessary debug lines.