|
I remember looking at 18F datasheets and felt like I was in a different world. Since the 876 was at hand that seemed the PIC to use for now. The I2C and SPI connections are set on the correct pins and ports, so I can move to those functions later. For now, I just needed to take baby steps in learning how to run the SPI and I2C without adding learning the hardware too. When I (if I) move to those hardware functions I should have a better idea of what they expect and how to use them.
|
I do like one thing about that chip... enough SRAM to load the sectors directly on the PIC.
|
Ah...that's the beauty of it...they're practically identical as far as PBP goes...except for minor changes in registers and such. This type of program should almost port right over, as long as you compare any/all registers you mess with, with the ones on both datasheets to make sure they match well enough.Originally Posted by JD123
If you're looking for all out speed, you might want to take some of your CLOCK_OUT type subroutines (the ones where you only flip a bit back and forth) and put those inline.
For each Gosub and Return, especially in a PIC16Fxxx, you use at least 2 cycles to GOSUB, 2 cycles to RETURN, and a cycle here and there just to set the page of the bit you want to flip. So that 2 cycle operation, turns into 6 or 8 depending.
Somewhere up towards the top, you've got a sector loop that runs 0-512 bytes. should be 0-511???
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
If there is no difference in code space, then you didn't save anything because it was already set in BANK0. If there is a different, then you did save because it was originally in BANK1,2 or 3, depending on total ram usage...
(I could really go nuts with the colons here!)
|
That's an error. I'll fix it.Somewhere up towards the top, you've got a sector loop that runs 0-512 bytes. should be 0-511???
That's good to know - I had no idea. I'll give this a try. Thanks!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
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.(I could really go nuts with the colons here!)
Last edited by JD123; - 20th March 2008 at 19:47.
|
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...
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.You mean in the text format?
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...
Last edited by skimask; - 20th March 2008 at 20:24.
|
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.
(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 02: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.
Members who have read this thread : 0You do not have permission to view the list of names.
Posting Permissions
Bookmarks