Where should I discuss SD/MMC FAT issues?

[skimask]

Interesting... I didn't think I called any routines that used the WDT. I'll check the .lst and see if there are any in there.

PBP inserts CLEARWDT instructions whenever it thinks there's a possibility of the WDT timing out during execution. But I don't know, and I've never bothered checking, if PBP even takes a look at the config fuses to see if the WDT is enabled and/or being used. I'm assuming that PBP ALWAYS inserts the instruction whether you are using the WDT or not. Better safe than sorry type thing. At any rate, I know from my experience that in projects where I'm not using the WDT timer at all, the DEFINE saves a load of program space...or at least a fair percentage.

On the outside, this looks to take about the same or more Tcy's to run as my 2 serial loops. I'll compile the two different ways and look at the .lst to count the Tcy's and see which is faster.

And they'll probably end up being close if not identical. About the only thing I know for sure, is the nested 'manual' for/next loop will save a few bytes of program space.

I've made sure that all variables used in this loop process are in bank0. Can variables not used in the loop slow the loop down?

I wouldn't think so, but...again, keeping everything you can in BANK0 can only speed things up a bit and save a few bytes here and there.

[mister_e]

But I don't know, and I've never bothered checking, if PBP even takes a look at the config fuses to see if the WDT is enabled and/or being used.

NOPE, unless they wouldn't add this DEFINE NO_CLRWDT 1 in their list.. and there's still 2 different way to set fuses... and not a lot of user seems to use 'em anyways...


Repeat-until will execute faster than a For-Next and need less codespace. This remind me the following thread...
http://www.picbasic.co.uk/forum/show...sharing&page=2

Post 8 and++

[JD123]

Repeat-until will execute faster than a For-Next and need less codespace. This remind me the following thread...
http://www.picbasic.co.uk/forum/show...sharing&page=2

Post 8 and++

Thanks. That a good read. I've written some short programs to do the same kind of benchmarking. I didn't consider the WHILE like loops, because though I know the loop functions are faster, adding back in a counter instruction seemed to offset any gains in total Tcy's per cycler. If checking for a match (end of loop condition) does not depend on a sequential counting, the WHILE type statments would be faster, for sure. Is my understanding about this correct?

[skimask]

Thanks. That a good read.

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.

[JD123]

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.

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.

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.

[mister_e]

Not a colonic master, but yeah, i believe you can't stack any ASM on the same line.

Note, a GOTO $+1 = 2 X NOP. For the 18F you have to use GOTO $+2

[skimask]

Not a colonic master, but yeah, i believe you can't stack any ASM on the same line.

Nope, you can't...and that really bummed me out...I could've saved close to 300 lines if I was able to stack 'em up....

[JD123]

Not a colonic master, but yeah, i believe you can't stack any ASM on the same line.

Note, a GOTO $+1 = 2 X NOP. For the 18F you have to use GOTO $+2

Is that GOTO literal or is there a value to "$"?

[skimask]

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.

I know there's an ABORT sequence of some sort in there somewhere. I'll do some digging and get back to you...

when I use your ":" colon text editing to condense my I2C routines I get an error surrounding the "@ NOP" lines?

Previous post... One @ per line, nothing else...

[JD123]

Thanks guys. This is what I thought too - only one "@" item per line. Maybe I'll just move the I2C files into a "Include I2C.bas". I'll just have to keep track of file locations as I progress from one folder (part of the project) to another.

If I include the full path name of the file, can I get PBP to find it, regardless of where the main program exists? Stupid question, I know it should be ok, just asking.