Where should I discuss SD/MMC FAT issues?

[skimask]

This would be easier if PBP had an open-ended I2C function (like CCS's C does) for long reads and writes. Not all EEPROMS have page write buffers and all EEPROMS have unlimited serial reads (less you roll it over). Think I should put a note in the suggestion box?

Quite frankly, I've never tried making my own I2C subroutines.
And besides, I believe PBP's I2C routines let you write multiple bytes just by the fact that you have multiple bytes in a statement (see the str modifier in the manual, Page 85 of the PBP2.50a manual, 2nd paragraph from the bottom). That should cover reading and/or writing pages at a time.
PBP is pretty tight as it is and you might not be gaining a whole heck of a lot by rolling your own subs...just banging your head....or is that 'bit-banging' your head
The suggestion might not be needed...

[JD123]

I'm trying to avoid this huge 512 byte array, which won't fit on this PIC anyway.

Speaking of the PIC, I was at the store today and picked up an 18F2050. It's not a 2025, but it should do. I loose one CCP but gain a USB. Past that I can't tell them apart.

[skimask]

I'm trying to avoid this huge 512 byte array, which won't fit on this PIC anyway.

Speaking of the PIC, I was at the store today and picked up an 18F2050. It's not a 2025, but it should do. I loose one CCP but gain a USB. Past that I can't tell them apart.

2050? Maybe a 2550...
Should do just fine. Combine that PIC with the examples from Mr.E's USB demo in another thread (or the config bit hassle that WILL follow...just seems to happen that way), and you'll be in great shape.

And the 512 byte array won't fit, but the 32 byte or 64 byte array of the EEPROM page will...

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