Codes at home. The proto board is running at 16mhz and the final version will run at 20mhz.
I know what's slowing it down. In my rush to write the code (I wanted to see if this F-RAM really was a drop-in replacement for the 24C64's), I simply re-addressed the I2C for every write and this is sending way too many bits per write. It's kicking out 48 bits per byte write yet my I2C handler will send out 9 bits per byte (after a one-time command/address string) and at about twice the clocking speed. That will bring the data transfer rate up to about 10 times faster overall.
I was about to go ahead and write a variable string of say 16 bytes per I2C_WRITE to speed things up, but decided not to waste my time, knowing I'd sooner or later bit-bang the I2C for the fastest results. I'm writing the I2C handler to run at the 20mhz speeds, so what I get at 16mhz will be off of top possible speeds by 20%.
I should get the simple use of my I2C handler finished tonight. It would have been done last night, but I went to bed early. I've been puting in some long days the past few weeks thanks to this project. I'll see if I can remember to bring some code to work to post. I think it's about 500 lines now (text editor lines, not instruction lines) but should be easy to follow because I tab, space and sub block in logical places, except when I'm debugging fast. The code is still full of unnecessary debug lines.
This is an example of my code style. It's not from this project.
Code:'*************** MODE 4 **************** IF MODE = 4 THEN TIME = TIME - 5 IF TIME = 1005 THEN FOR T = 1 TO 50 GOSUB SENDOUT GOSUB DELAY NEXT T ENDIF IF TIME = 1995 THEN FOR T = 1 TO 50 GOSUB SENDOUT GOSUB DELAY NEXT T ENDIF IF TIME < 900 THEN TIME = 900 ENDIF RETURN ENDIF
Well, I half-ass got the I2C running last night. I knew I'd have to play with the NOP's to get the fastest speeds, but ran out of time. I spent over 2 hours debugging the I2C only to find that I was clocking out using:
SDA and SCL are port pins
SDA = 1
@ NOP
@ NOP
@ NOP
@ NOP
@ NOP
SCL = 0
@ NOP
etc..
I spent so much time coding SDA followed by SCL that I guess I couldn't stop! With that fixed I was out of time. I did run the Tcy for MMC to I2C transfers and I'm only saving about 1000 Tcy, far less than what I was hoping for. I know the issue is in the number and placement of @ NOP's. Something is eating tons of time with Tcy up over 54,000, but it's not all going to be in the I2C. The MMC runs without any delays in a serial read, so I'm not sure what's going on.
Skimask, PM me with an email address and I'll send you a copy of the code. It's just short of 900 text lines and won't fit in a post here. Note that for debug reasons, the I2C reading has been reverted back to the PBP I2CREAD handler.
Last edited by JD123; - 20th March 2008 at 15:35.
Okay, I didn't see the attachments in posting.
Keep in mind that this is still a FORWARD process and I've left a lot of trash in my wake. When it's working the way I want I'll go clean up the trash.
Also, if it will help stop comments like "well, that was stupid", this is only my 7th PIC program to write, though I bought my first PIC in 1993. No one has ever seen my code before, other than bits and pieces. This kind of feels like getting undressed in public... on stage... at the Opera!
What I've made:
An LED blink in asm
A/D > LCD in asm
AoA (Angle of Attack) controller for model airplanes in CCS-C
Automatic slip/skid (yaw) controller for model airplanes in PBP and asm
A servo driver in PBP and asm
A proof’er w/LCD for calibrating the servo drivers in PBP and asm
And now this MMC reader and soon to be data logger in PBP
This is really only my 4th PBP program, though I have a number of Quick Basic 4.5 PC oriented programs under my belt. Be kind.
1st thought right off the bat...
You're using an '876A. It's easy to replace that with an 18F2620.
Practically the same pinout, load more code space, lots more ram, more internal functions...
Having a look at the rest of the code right now...
Bookmarks