Where should I discuss SD/MMC FAT issues?

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

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