Where should I discuss SD/MMC FAT issues?

[JD123]

Somewhere up towards the top, you've got a sector loop that runs 0-512 bytes. should be 0-511???

That's an error. I'll fix it.

Figure out which byte variables you use the most (not pins assigned to a variable, but a RAM variable), and assign those to BANK0.
A variable assigned to BANK0 only needs a single instruction to set the PICs page register to ZERO. A variable assigned to other banks usually needs 2 instructions to set the PICs page register.
For instance, you've got:
w_byte var byte
try:
w_byte var byte BANK0

That's good to know - I had no idea. I'll give this a try. Thanks!

(I could really go nuts with the colons here!)

You mean in the text format? I've been known to make the text file shorter doing this, but for 'me' it's easier read the logic without hunting down colons.

[skimask]

That's good to know - I had no idea. I'll give this a try. Thanks!

Somewhere on these forums is writeup talking all about moving variables around to save both code space and increase execution speed a bit...don't remember what it is though...

You mean in the text format?

It's all good...I've been known to take a perfectly readable file of source code, and knock it down to fit a very small space and make it perfectly unreadable to anyone but me by using loads of colons and removing extraneous spacing.
And I forgot to mention...
I just like piling as much information on the screen as possible, which is why I run 1600x1200, sometimes more...on more than one screen at a time...

[JD123]

Am I reading this right? The 18F2620 doesn't use banks in memory locations? If so, cool! Looks like I'll be moving to this chip soon, if for no other reason than the onboard SRAM. Anyone want to buy a 'gently' used F-RAM? (just kidding)

[JD123]

I've been known to take a perfectly readable file of source code, and knock it down to fit a very small space and make it perfectly unreadable to anyone but me

AKA Job Security!

I just like piling as much information on the screen as possible, which is why I run 1600x1200

See first quote.

[skimask]

AKA Job Security!
See first quote.

Yeah...but everybody else seems to hate it.
(Refer to this thread: http://www.picbasic.co.uk/forum/show...t=optimization )
Check the file attached to post #29...

And just for grins...if I'd rewrite that program it would look like this:

[JD123]

Yeah...but everybody else seems to hate it.
(Refer to this thread: http://www.picbasic.co.uk/forum/show...t=optimization )
Check the file attached to post #29...

And just for grins...if I'd rewrite that program it would look like this:

LOL! Yep, that would be like a Ford truck I once owned. It drove so bad (hard to keep it in a strait line) that when a friend of mine tried to drive it he said "this is a one person truck". That code would also be a one person truck!

[skimask]

Am I reading this right? The 18F2620 doesn't use banks in memory locations? If so, cool! Looks like I'll be moving to this chip soon, if for no other reason than the onboard SRAM. Anyone want to buy a 'gently' used F-RAM? (just kidding)

You got it... AND the 18Fxxx's run 40Mhz (although I think they should be rated at 55Mhz, 'cause every one of mine goes that fast, at least at 4.5-5v).

[JD123]

I've got to get away from this pooter and get some real work done. Since I found the attachments button (duoh) here a screen capture of the F_ind file option.

[skimask]

I've got to get away from this pooter and get some real work done. Since I found the attachments button (duoh) here a screen capture of the F_ind file option.

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.

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