Where should I discuss SD/MMC FAT issues?


Closed Thread
Results 1 to 40 of 93

Hybrid View

  1. #1
    skimask's Avatar
    skimask Guest


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by JD123 View Post
    I'm still looking for a faster way to move the I2C data line, so I'm writing my own I2C handler routines. My whole program cycle has to fit into 16.67ms. It doesn't look like I'll be able to load the I2C with sample data then move it to the MMC in this window unless I can get the program cycle, minus the data captures, down to about 6ms.
    What speed is your osc running at?
    I know you can get 500-ish bytes inside of a few ms...
    Show some code!

  2. #2
    Join Date
    Mar 2008
    Location
    Texas, USA
    Posts
    114


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by skimask View Post
    What speed is your osc running at?
    I know you can get 500-ish bytes inside of a few ms...
    Show some code!
    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.

  3. #3
    Join Date
    Mar 2008
    Location
    Texas, USA
    Posts
    114


    Did you find this post helpful? Yes | No

    Default

    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

  4. #4
    Join Date
    Mar 2008
    Location
    Texas, USA
    Posts
    114


    Did you find this post helpful? Yes | No

    Default

    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.

  5. #5
    skimask's Avatar
    skimask Guest


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by JD123 View Post
    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.
    Just attach it here as a .txt file.

  6. #6
    Join Date
    Mar 2008
    Location
    Texas, USA
    Posts
    114


    Did you find this post helpful? Yes | No

    Default

    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.
    Attached Files Attached Files

  7. #7
    skimask's Avatar
    skimask Guest


    Did you find this post helpful? Yes | No

    Default

    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...

Similar Threads

  1. Reading and Writing from SD/MMC cards as FAT filesystem?
    By charliez in forum mel PIC BASIC Pro
    Replies: 3
    Last Post: - 22nd June 2006, 22:26

Members who have read this thread : 0

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts