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)
|
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)
|
AKA Job Security!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
See first quote.I just like piling as much information on the screen as possible, which is why I run 1600x1200
|
Yeah...but everybody else seems to hate it.Originally Posted by JD123
(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:
Last edited by skimask; - 21st March 2008 at 01:25.
|
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!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:
|
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).
|
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.
|
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)
Last edited by JD123; - 21st March 2008 at 15:10.
|
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.Do you think by pushing the loop subs up to the top of the program I could see even faster speeds?
(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.
Members who have read this thread : 0You do not have permission to view the list of names.
Posting Permissions
Bookmarks