SDHC (FAT32 for SD cards)


Closed Thread
Results 1 to 23 of 23

Hybrid View

  1. #1
    Join Date
    Oct 2004
    Posts
    440


    Did you find this post helpful? Yes | No

    Default

    IF (Your PIC is running at 40Mhz) AND (You are using the DEFINE FS_SPEED) AND (Maybe your PCB and/or wiring isn't quite 'up-to-snuff') THEN
    You may have initialization/writing problems which WILL corrupt your SD card
    ENDIF
    It is recommended to initialize at slower speed and switch to faster for read/writes.
    Also the clock pin sucks power especially with the larger size cards.
    If you are using a resistor voltage divider to convert to 3 volts use lower values to maintain signal strength.

    Is code SPI(one bit at a time) or SD Bus(4 bits at a time) mode?
    CRC(required for SD bus mode)?
    Multiblock read and write for speed?

    Norm
    Last edited by Normnet; - 30th August 2009 at 15:45.

  2. #2
    Join Date
    Nov 2003
    Location
    Wellton, U.S.A.
    Posts
    5,924


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by Normnet View Post
    It is recommended to initialize at slower speed and switch to faster for read/writes.
    Also the clock pin sucks power especially with the larger size cards.
    If you are using a resistor voltage divider to convert to 3 volts use lower values to maintain signal strength.
    I did not know that about the larger cards.
    Is code SPI(one bit at a time) or SD Bus(4 bits at a time) mode?
    CRC(required for SD bus mode)?
    Multiblock read and write for speed?

    Norm
    I can not exactly answer your questions. My role in this with the original SDFS and this one has been trying to break it.
    This is from the SDFS readme. Might help.
    The PICBASIC PRO programs included in this zip allow reading and writing to
    SD (Secure Digital) and MMC (Multi Media) cards using the FAT16 file system.
    The code was written based on information from the Microchip USB framework
    and Jan Axelson's book, USB Mass Storage. Details on SD and MMC cards and
    the FAT file system can be found there.

    The included code does not actually use the security features of SD cards.
    It reads and writes to the cards using SPI in MMC mode. While the code can
    certainly be modified to take advantage of the secure digital features, a
    license to the SD consortium would need to be paid. Information about this
    can be found online.

    Speaking of licenses, the FAT file system is owned by Microsoft and must be
    licensed from them if you intend to sell a product that uses it. The license
    fee looks to be fairly nominal. More information can be found on Microsoft's
    web site.
    Dave
    Always wear safety glasses while programming.

  3. #3
    Join Date
    Oct 2004
    Posts
    440


    Did you find this post helpful? Yes | No

    Default

    Also the clock pin sucks power especially with the larger size cards.
    I did not know that about the larger cards.
    At least a 2 gig card compared to a 512 mb.

    Norm

  4. #4
    Join Date
    Nov 2003
    Location
    Wellton, U.S.A.
    Posts
    5,924


    Did you find this post helpful? Yes | No

    Default

    From Jeremy
    The code does initialize at slow speed, roughly 50Khz. Then switches to whatever mode you set up after that, could be shiftin/shiftout (77Khz+ or so), bit-banged SPI (about 150khz @ 40Mhz) up 10Mhz using hardware SPI.

    Good info with the resistor voltage divider with larger cards. Noted. I'll try out a few cards, throw a meter on them, and see what I come up with for comparison.

    One-bit/SPI mode only. 4-bit mode/SD bus mode, takes a lot more programming than I want to deal with! Not to mention the processing time it would take to calculate CRC's 'on-the-fly'. Gotta draw the line somewhere.

    No CRC's used except during initialization, then only pre-calculated CRC's are used. You can disable CRC's in SPI mode.

    Single block commands, one sector at a time. Any more an you'd run out of ram on the PIC rather quickly. Eventually, I'll get my hands on a static ram I2C chip from Microchip and integrate that into SDFSHC32 somehow to make multi-block reads/write possible. Even then, you'd be limited to the maximum block size set by the card itself.

    All of this info will be fed back into the NOTES file.
    Dave
    Always wear safety glasses while programming.

  5. #5
    Join Date
    Oct 2004
    Posts
    440


    Did you find this post helpful? Yes | No

    Default

    See PIC iPod wav player for my FAT16 SD card reader.
    Reads and plays mono CD quality (16bit 44k) or stereo 8bit 44k from SD cards.
    Utilizes multiblock for fast sequential read and play of wav data.
    Also data for Nokia GLCD pictures or scrolling menu.

    The code was written based on information from the Microchip USB framework
    and Jan Axelson's book, USB Mass Storage. Details on SD and MMC cards and
    the FAT file system can be found there.
    Does Jan's book have any insight on 4 bit Bus mode?
    I have the CRC routine worked out but haven't had success with Bus mode yet.

    Norm

  6. #6
    Join Date
    Nov 2003
    Location
    Wellton, U.S.A.
    Posts
    5,924


    Did you find this post helpful? Yes | No

    Default

    More from Jeremy:::
    See PIC iPod wav player for my FAT16 SD card reader.
    Reads and plays mono CD quality (16bit 44k) or stereo 8bit 44k from SD cards.
    Utilizes multiblock for fast sequential read and play of wav data.
    Also data for Nokia GLCD pictures or scrolling menu.
    Does Jan's book have any insight on 4 bit Bus mode?
    I have the CRC routine worked out but haven't had success with Bus mode yet.
    Agreed...Multi-block transfers aren't hard to program at all, and a heck of a lot faster than the single block mode used right now.
    Problem is the PIC doesn't have the room to store much of it! Therefore, at present, it wasn't worth the time to write that code.
    When I get my hands on one of those I2C SRAM chips, I'll get on it.
    Same thing for the GLCD/menu type stuff, and decoding BMPs (easy), JPEGs (hard), etc. Not enough room to store everything.

    Don't know about Jan's book and the SD bus mode. Haven't played with that, but I've got datasheets on it, and I think I've got decent CRC5/CRC16 (?) routines laying around somewhere.
    I'm concentrating on keeping the hardware to a bare minimum for now (5 pins vs 9 pins).
    Again, when I get that I2C SRAM chip, I'll expand out the code to handle multi-block read/write/storage, SD-bus, and whatever else I can think of.

    Found the fix for the failures relating to FS_SPEED:

    In the SectorWrite subroutine (the fix is in bold 9 lines down):
    Code:
    @ ifdef FS_SPEED
                ' Write a sector's worth of data. (optimized for speed)
                if (!FAT_FSfast) then
                    For SDC_index = 0 To (MEDIA_SECTOR_SIZE - 1)
                        SDC_data_out = SDC_buffer[SDC_index] : gosub writespim    ' Write Byte SDC_data_out.
                    next SDC_index
                else    'fast clock toggler. may have to add extra SCL = 1 : SCL = 0 if running into R/M/W issues
                    for SDC_index = 0 to (MEDIA_SECTOR_SIZE - 1)
                        FAT_sdbyteout = SDC_buffer[SDC_index] : sdo = FAT_sdbyteout.7 : scl = 1 : scl = 0 : sdo = FAT_sdbyteout.6 : scl = 1
                        scl = 0 : sdo = FAT_sdbyteout.5 : scl = 1 : scl = 0 : sdo = FAT_sdbyteout.4 : scl = 1 : scl = 0
                        sdo = FAT_sdbyteout.3 : scl = 1 : scl = 0 : sdo = FAT_sdbyteout.2 : scl = 1 : scl = 0 : sdo = FAT_sdbyteout.1
                        scl = 1 : scl = 0 : sdo = FAT_sdbyteout.0 : scl = 1 : scl = 0
                    Next SDC_index
                endif
    @ endif
    Dave
    Always wear safety glasses while programming.

Members who have read this thread : 2

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