Where should I discuss SD/MMC FAT issues?

[JD123]

Actually, you're one of only a couple of other people I've seen to get PBP to work with FAT on an MMC. I got a PIC/PBP to talk to an MMC, but not talking FAT.
I'm going to have a good hard look at your code and see what (if any) major changes would be needed for FAT32 compatibility.

Two things. First, I have a treat for you and anyone else who's trying to understand what I've done. It was a post I put together about how to simply find a file using a file's name and FAT. I wasn't happy with the limit of the scope, but now that I've put code out there, I think some people can benefit from what I've found.

Second, man you hit the nail on the head! I went from about 55,000 Tcy to 5098 Tcy by forcing the bank locations to 0 for the variables used in the read/write loops. I was so shocked, I thought that I didn't get the data, but with each read of the F-RAM to look at it's content, sure enough all my data is there. That's amazing how much difference that made. Do you think by pushing the loop subs up to the top of the program I could see even faster speeds?

(Oops... wrong file )

[skimask]

Second, man you hit the nail on the head! I went from about 55,000 Tcy to 5098 Tcy by forcing the bank locations to 0 for the variables used in the read/write loops

SWEET!

Do you think by pushing the loop subs up to the top of the program I could see even faster speeds?

Probably not...BUT...if you take all of the variables in that tight loop, and make them all BANK0, you might see an incremental speed increase. I can't remember if the compiler will complain once it's out of BANK0 space or not, or if you'll even know it. One thing to do would be to check the .lst file and see where they're being put.
(looking at the new doc file now)

[JD123]

SWEET!

Probably not...BUT...if you take all of the variables in that tight loop, and make them all BANK0, you might see an incremental speed increase. I can't remember if the compiler will complain once it's out of BANK0 space or not, or if you'll even know it. One thing to do would be to check the .lst file and see where they're being put.
(looking at the new doc file now)

That's what I did - ALL variables used in the loops.

I re-read the PBP manual this morning and it does say that it will issue a warning if a 'requested' bank assignment won't fix.

[skimask]

That's what I did - ALL variables used in the loops.
I re-read the PBP manual this morning and it does say that it will issue a warning if a 'requested' bank assignment won't fix.

Ok, then moving that loop to the beginning of the program might have a small-ish impact on speed for the same reason, keeping it in BANK0. And if the whole loop won't fit up there, just try to put the tightest, smallest chunk of it up there. As I found out when I built my MP3 player, one cycle inside of a tight 512 count loop, inside of a tight 32 count loop (16K counts total) makes a big difference...especially when that loop was only 12 cycles long in the first place.

[JD123]

Last night I tried coding for the READ_I2C function (my sub) and ran into a fair amount of trouble. I’m not sure, but I think it revolved around the repeated hits to the ACK sub, where I originally wrote it for writes only (see where I toggle the port looking for the ACK from the SDA on the I2C) and my not understanding (while I was head-banging the problem) that the PIC issues the ACK if it is the receiver (reading the I2C).

It was late and I didn't give it a fair chance. I'm sure I get it figured out. Still, I'm up for suggestions as to what 'should' be the I2C functions that I make. I think I've got things so fractured that it's both getting hard to follow the loops and I maybe re-writing code unnecessarily. I was thinking that I should write the functions (subs) like this:

OPEN_I2C with a R/W bit set for read/write keeping all aspects inside the sub, and I2C stays open after address until...

CLOSE_I2C will send a stop command to end single or serial byte reads and writes.

WRITE_I2C simply sends out a byte with ACK back from the I2C, I2C stays open for next WRIET_I2C.

READ_I2C simply reads in a byte with ACK from PIC, I2C stays open for next READ_I2C.

Does this sound like a logical way to breakup the I2C subs so that I can read/write both bytes and serial strings?

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?

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