Where should I discuss SD/MMC FAT issues?

[JD123]

{getting out my reading glasses...} Yup, it's a 2550.

I don't see a "MrE, Mr. E, Mr.E or Mr E" in the member list???

[skimask]

I don't see a "MrE, Mr. E, Mr.E or Mr E" in the member list???

http://www.picbasic.co.uk/forum/show...ghlight=mister

I got this one in my hotlinks...

[JD123]

Thanks. That's a thread I wish I was around for back in 06.

[JD123]

Something is wrong with my Tcy counter. It must be rolling over. I didn't make provisions for it rolling over because I couldn't imagin it taking more than 65K Tcy to move the data off the MMC and onto the F-RAM. I guess I was wrong... very wrong.

Best condition Tcy's to move data:

gosub to MMC read - 2Tcy

get byte - 24Tcy (3Tcy per bit)

return - 2Tcy

gosub to write F-RAM - 2Tcy

write F-RAM - 117Tcy (13Tcy per bit (min. clock delay 5Tcy), 9 bits w/ack)

Ack overhead - 9Tcy if tested, 3Tcy if blind read

return - 2Tcy

total for single byte loops - 158Tcy

repeat 512 times - 80,896Tcy

I must be moving data WAY slower than I thought. Time to detect TMR1 rollover and see what it really is.

[skimask]

Something is wrong with my Tcy counter. It must be rolling over. I didn't make provisions for it rolling over because I couldn't imagin it taking more than 65K Tcy to move the data off the MMC and onto the F-RAM. I guess I was wrong... very wrong.

Make an interrupt for the overflow interrupt and increment another word based on that.
Also, I was looking thru your code again.
Whenever you multiply or divide by a power of 2, you can easily use a shift to accomplish the same thing. Saves a bunch of cycles, and some code space.
For instance, you've got:
OP = OP * 512 (at least 9 shifts, 9 double word adds + carry's, probably 100-ish cycles)
That can be rewritten:
OP = OP << 9 (9+ cycles)

repeat 512 times - 91,136Tcy

Put some of your shorter Gosub/Returns in-line with the loop that runs 512 times. For each Gosub/Return you eliminate in the loop, you save at least 2,048 cycles (about 2% for each one).

[JD123]

Noted. I'll spend a bit more time on this, but with 80K+ Tcy's, I won't come even close to using this function while recording the 8 byte data every 16.67ms. Since this function will come into play only when starting and ending a session, time won't be an issue.

By the first of next week I need to get back on track with the core of the project.

[JD123]

We'll, I've done my best and yes, about 84K Tcy is as fast as this thing is going to read 512 bytes from the MMC and write the 512 bytes to the FRAM. It's 83,968 Tcy to be exact. Last night I thought I'd give it one more go.

At the start of the evening I got my latest code loaded and checked for timer1 overflows. Yep, it was running over. The true transfer times were 166,837 Tcy. I started dissecting the code bit by bit and embedding timers to catch cycle times. Turns out I had a very inefficient MMC routine. I strait-lined the code and got it back up to speed. I tweaked the I2C as well as moving the two function subs WRITE_I2C and GET_BYTE to the top of the program. Within an hour or two I got it down to 129,837 Tcy. After doing some math, I figured I was eating 45 Tcy with every loop and couldn't account for where it was coming from. The last part of the routine to be counted was the time needed to simply perform the FOR-NEXT loop.

Bingo! Turns out using WORD sized variables in a FOR-NEXT loop can be a huge Tcy eater. The solution I used was to break up the 512 count in the for-next loop to two 256 count loops. Boom! The cycle times fell to 83,986 Tcy. So, in a few hours, I saved 82,869 Tcy, saved 400 lines of complied code and gained about twice the speeds. I'm currently at 16mhz ripping the MMC sector and writing it in a total of just under 21ms. Still not fast enough to use it as I would like, but still... that's fast I2C.

Here's the updated code: