You're right about moving up in the PIC. I've started reading about the I2C port on the PIC I have. It's a bit daunting for the first-time user of this port function.Originally Posted by skimask
Just so I can remember where you're going with this...
You're getting some data, saving it in an FRAM, then dumping it out to an MMC, right?
But...you need it to dump inside of 16ms...
We could go on optimizing this all day (week? month?), saving a couple of cycles here and there, trying to shave off that last couple of uSec.
I think in the end, you'd be much better off switching over to an 18F4620 (or whatever suits you, 18Fxxxx), kick up the osc. speed a bit, and take advantage of the extra ram in the 18F. Just going to 40Mhz will get you an extra 2.5x theoretical improvement ('cause you'll probably have to add NOPs at various points to keep the timings in spec), no BANKing issues will save another bunch of cycles...and so on and so on... Jist of the story, that 20-ish ms could theoretically drop to a bit over 8ms per chunk.
So far as the function of the memory, up to this point, it's MMC to PIC to FRAM. If I could get it down to a few ms then I was considering using it as the write buffer for the collected data instead of directly dumping the collected data onto the MMC. I don't think this is going to work unless I use both the SPI and I2C ports on my PIC. Even still, I don't think I have the time in the data collection cycle to do this. The advantages of using the hardware ports is a near perfect 1mhz to the FRAM and max speed to the MMC (mmc takes up to 20mhz). I was reading that the ports clock out at Fosc/2 when it's all done and said, I think. Like I said, I'm still reading... and reading... and reading. In theory, I could move 512 bytes from the MMC in a touch over 2ms and the same data to the FRAM at 4ms, but this does not include any code overhead - it's just the bit rates.
Back to the MMC for a minute:
The only way I've found to stop a sector read that allows for the next command to be another sector read has been to either finish the original sector read or to initialize the MMC. Am I missing a command that allows aborting a sector read followed by another sector read command? I did find the STOP command, but found out that sending another sector read command following the STOP command fails to be accepted by the MMC. Seems that the STOP command would be better described as a "PAUSE" command. Even the datasheet's say it's to free up the SPI bus for other SPI functions. It doesn't say anything about aborting the read command. The only way to do all this has been by initializing the MMC, which can take quite some time to do.
One other thing skimask, I was going to post this question in the PBP forums, but since you brought it up here... How come when I use your ":" colon text editing to condense my I2C routines I get an error surrounding the "@ NOP" lines?
I'm using text lines that look like:
SDA=1:@ NOP:@ NOP:@ NOP:SCL=1:@ NOP:@ NOP:@ NOP:SCL=0:{...ect.}
The "warning" listed is #255 "Expected op code instead of 'NOP :@' ". at the end of many warnings it "fails" and aborts the assembly process.
It looks like you can not nest any lines using the colon after an ASM (@) insertion. I checked the edited text lines to make sure I didn't remove the needed space before the "NOP". Since the code is now stable, I'm just looking to compact it for ease of moving around in the program.
Bookmarks