Post by thread:[PIC] SD card & FAT

Hi all, I need to write some data to an SD card, so it can be retrieved on a PC. Been researching, but have some lingering questions... - SD cards can be accessed in SPI mode, but what are the limitations of that? Can I still write a files in PC-accessible format (FAT16, FAT32, etc). And what is the *full* SD-card mode anyway? - Why do I need FAT32? If I can live with the 2GB limit, any Windows OS can access FAT16 still, right? I ask because I understand that FAT16 is much easier to implement. - Anyone have a link to a free FAT16 library? This looks promising, but other recommendations appreciated... https://www.marcusbannerman.co.uk/index.php/research/electronicspics/40-pic-projects/76-fat32-library-for-pic18-devices.html - Anyone have a recommendation for a good book on the subject? I found this, but the reviews don't tell me that it will get me a good understanding on using SD cards with PICs... http://www.amazon.com/Card-Projects-Using-PIC-Microcontroller/dp/185617719X/ref=sr_1_1?s=books&ie=UTF8&qid=1339589318&sr=1-1 <http://www.amazon.com/Card-Projects-Using-PIC-Microcontroller/dp/185617719X/ref=sr_1_1?s=books&ie=UTF8&qid=1339589318&sr=1-1> Cheers, -Neil.

Does it *have* to be on a PIC? Because there's a library available for the Arduino platform (which can be flat out used in AVR-GCC) that just...works. Makes it incredibly easy. I suppose that may be reasonably easy to port over to C for a PIC. AFAIK, the main limit on the SPI mode of access is speed. Read/write via SPI is much much slower than other methods. For small amounts of data it probably won't matter. MikeH On Wed, Jun 13, 2012 at 4:02 PM, Neil <spam_OUTpicdude3TakeThisOuTnarwani.org> wrote: {Quote hidden}> Hi all, > > I need to write some data to an SD card, so it can be retrieved on a > PC. Been researching, but have some lingering questions... > > - SD cards can be accessed in SPI mode, but what are the limitations of > that? Can I still write a files in PC-accessible format (FAT16, FAT32, > etc). And what is the *full* SD-card mode anyway? > > - Why do I need FAT32? If I can live with the 2GB limit, any Windows OS > can access FAT16 still, right? I ask because I understand that FAT16 is > much easier to implement. > > - Anyone have a link to a free FAT16 library? This looks promising, but > other recommendations appreciated... > > https://www.marcusbannerman.co.uk/index.php/research/electronicspics/40-pic-projects/76-fat32-library-for-pic18-devices.html > > - Anyone have a recommendation for a good book on the subject? I found > this, but the reviews don't tell me that it will get me a good > understanding on using SD cards with PICs... > > www.amazon.com/Card-Projects-Using-PIC-Microcontroller/dp/185617719X/ref=sr_1_1?s=books&ie=UTF8&qid=1339589318&sr=1-1 > < > www.amazon.com/Card-Projects-Using-PIC-Microcontroller/dp/185617719X/ref=sr_1_1?s=books&ie=UTF8&qid=1339589318&sr=1-1 > > > > Cheers, > -Neil. > > > >

On 14 June 2012 08:02, Neil <.....picdude3KILLspam@spam@narwani.org> wrote: > - Anyone have a link to a free FAT16 library? This looks promising, but > other recommendations appreciated... > https://www.marcusbannerman.co.uk/index.php/research/electronicspics/40-pic-projects/76-fat32-library-for-pic18-devices.html I've used this one on dsPIC before. http://elm-chan.org/fsw/ff/00index_e.html There are example projects on the site for various uC including PIC24. You don't say what type of PIC you are using, but the code should be easy enough to port. (It's a C library BTW) Matt

On Wed, Jun 13, 2012 at 6:02 PM, Neil <picdude3KILLspamnarwani.org> wrote: > Hi all, > > I need to write some data to an SD card, so it can be retrieved on a > PC. Â Been researching, but have some lingering questions... > > - SD cards can be accessed in SPI mode, but what are the limitations of > that? Â Can I still write a files in PC-accessible format (FAT16, FAT32, > etc). Â And what is the *full* SD-card mode anyway? > Full SD mode is physically like SPI except there are a varying number of data lines that allow for parallel data transmission so it is much much faster than SPI mode. > - Why do I need FAT32? Â If I can live with the 2GB limit, any Windows OS > can access FAT16 still, right? Â I ask because I understand that FAT16 is > much easier to implement. FAT16 will be much easier to utilize, but FAT32 is (IIRC) somewhat backwards compatible. > > - Anyone have a link to a free FAT16 library? Â This looks promising, but > other recommendations appreciated... > https://www.marcusbannerman.co.uk/index.php/research/electronicspics/40-pic-projects/76-fat32-library-for-pic18-devices.html Well, the Microchip library is free, right? I've used it and it seemed to work fine. I've also written my own simple code that could create files on a preformatted SD card. > > - Anyone have a recommendation for a good book on the subject? Â I found > this, but the reviews don't tell me that it will get me a good > understanding on using SD cards with PICs... About two years ago I wrote code for writing to FAT16 on SD cards. I used several websites and example code as references (my code was in assembly I believe) Unfortunately I don't have those URLs right here but I may be able to find them later. -- Martin K.

> > - SD cards can be accessed in SPI mode, but what are the limitations > > of that? Â Can I still write a files in PC-accessible format (FAT16, > > FAT32, etc). Â And what is the *full* SD-card mode anyway? > > > > Full SD mode is physically like SPI except there are a varying number of data lines > that allow for parallel data transmission so it is much much faster than SPI mode. From peoples mumblings on this list, SPI mode is also significantly slower. {Quote hidden}> > > - Why do I need FAT32? Â If I can live with the 2GB limit, any Windows > > OS can access FAT16 still, right? Â I ask because I understand that > > FAT16 is much easier to implement. > > FAT16 will be much easier to utilize, but FAT32 is (IIRC) somewhat backwards > compatible. > > > > > - Anyone have a link to a free FAT16 library? Â This looks promising, > > but other recommendations appreciated... > > www.marcusbannerman.co.uk/index.php/research/electronicspics/4 > > 0-pic-projects/76-fat32-library-for-pic18-devices.html > > Well, the Microchip library is free, right? I've used it and it seemed to work fine. > I've also written my own simple code that could create files on a preformatted SD > card. Microchip Library is part of the MAL http://www.microchip.com/MAL It also has LFN support these days.

On Thu, Jun 14, 2012 at 9:03 AM, <.....alan.b.pearceKILLspam.....stfc.ac.uk> wrote: >> Full SD mode is physically like SPI except there are a varying number of data lines >> that allow for parallel data transmission so it is much much faster than SPI mode. > > From peoples mumblings on this list, SPI mode is also significantly slower. Most people would agree that if A is faster than B, then B is slower than A. Also, few people would disagree. -- Martin K

> From: Neil <EraseMEpicdude3spam_OUTTakeThisOuTnarwani.org> > Subject: [PIC] SD card & FAT > > - Why do I need FAT32? If I can live with the 2GB limit, any Windows OS > can access FAT16 still, right? I ask because I understand that FAT16 is > much easier to implement. > I have used Microchip's FAT16 library successfully. Their FAE explained to me that the FAT32 library was provided for reference only, using FAT32 requires a licence. I believe that the FAT16 library is actually called something else as FAT16 is copyright Microsoft. Regards James

You don't get a choice between FAT16 and FAT32 as it depends on the denisty of the card as to how it is formatted. According to our good friends at Microsoft: "The FAT typeâ€”one of FAT12, FAT16, or FAT32â€”is determined by the count of clusters on the volume and nothing else. " If(CountofClusters < 4085) { /* Volume is FAT12 */ } else if(CountofClusters < 65525) { /* Volume is FAT16 */ } else { /* Volume is FAT32 */ } RussellMc wrote: > >> ... using FAT32 requires a licence. > > I understand that that point is contestable, but you may need vastly > deep pockets to contest it. > > > > Russell > -

> > ... using FAT32 requires a licence. > > I understand that that point is contestable, but you may need vastly deep pockets to > contest it. I don't believe FAT32 requires a license, but many people confuse FAT32 with using Long File Names, which certainly does require a license from Microsoft, the last I heard. I don't know how Microchip get on supplying LFN support in their library, or if they rely on the end user (programmer, OEM) getting an appropriate license. I haven't gone looking at that part of the MAL license. -- Scanned by iCritical.

Awesome... This (including other replies on this subject) clarifies a lot. I do want to keep this PIC-based, as it makes more sense for me. And I will be doing this in C. PIC 18 would be nice, but I'm also considering PIC32. Was not aware that mchp had FAT libraries, but thing I'll go their route first (and hopefully only). Don't need to have LFN -- 8.3 is fine for now. My quick ballpark calcs tell me that I will need to save ~1k bits per second. That's my content, and at this point I'm not sure how much overhead data will be added to this, but this page ( http://en.wikipedia.org/wiki/Secure_Digital ) tells me that I can do 50Mbits/sec in SPI mode, which seems like it would be much more than I need, so I can stick with SPI mode for now. Thanks for the info, -Neil. On 6/15/2012 4:39 AM, alan.b.pearcespam_OUTstfc.ac.uk wrote: >>> ... using FAT32 requires a licence. >> I understand that that point is contestable, but you may need vastly deep pockets to >> contest it. > I don't believe FAT32 requires a license, but many people confuse FAT32 with using Long File Names, which certainly does require a license from Microsoft, the last I heard. > > I don't know how Microchip get on supplying LFN support in their library, or if they rely on the end user (programmer, OEM) getting an appropriate license. I haven't gone looking at that part of the MAL license.

On Sun, Jun 17, 2012 at 3:58 PM, Neil <@spam@picdude3KILLspamnarwani.org> wrote: > 50Mbits/sec in SPI mode, which seems like it would be much more than I > need, so I can stick with SPI mode for now. I don't think that's correct. I, IIRC, have seen about 400 kbytes/sec and others have verified this number. Still, it's much above your 1 kbit/sec figure. -- Martin K

I am trying to follow the thread and am wondering for everyone's clarity: Can we clarify the mode of Reading and/or Writing modes for the claims of SD Card access via SPI (and which PIC at what FOSC)? I would like to help and compare notes to the access times but want to make sure that I am up to "speed"...... Thanks, David {Original Message removed}

On Sun, Jun 17, 2012 at 8:32 PM, <KILLspamdavidcouKILLspamaol.com> wrote: > I am trying to follow the thread and am wondering for everyone's clarity: > > Can we clarify the mode of Reading and/or Writing modes for the claims of SD Card access via SPI (and which PIC at what FOSC)? > > I would like to help and compare notes to the access times but want to make sure that I am up to "speed"...... > > Thanks, > David The number I quoted was a limitation based on the SPI requirements of the SD card, not the PIC limitation. -- Martin K

> I, IIRC, have seen about 400 kbytes/sec and others have verified > this number. Still, it's much above your 1 kbit/sec figure I use SD cards for dsPIC .wav storage and find even retrieval with SPI has a disappointingly low ceiling Reading one file of 44100Hz, 16-bit stereo (176.4 kbytes/sec) is OK but when trying to read much faster reliably you run into latency problems in the card controller, as Martin says. SPI is not the native comms for an SD card and presumably the card controller just can't keep up translating SPI to its 4-bit parallel O/S. In bursts you can read up to 350-400 kbytes/sec but it's not sustainable, unlike the transfers seen between say PC and card via a proper reader/writer which uses 4-bit paralle

I am currently evaluating the following library for my own use. http://elm-chan.org/fsw/ff/00index_e.html Looks good so far..... Reading each line of the library. John ________________________________ From: Neil <RemoveMEpicdude3TakeThisOuTnarwani.org> To: Microcontroller discussion list - Public. <spamBeGonepiclistspamBeGonemit.edu> Sent: Thursday, June 14, 2012 6:02 AM Subject: [PIC] SD card & FAT Hi all, I need to write some data to an SD card, so it can be retrieved on a PC. Been researching, but have some lingering questions... - SD cards can be accessed in SPI mode, but what are the limitations of that? Can I still write a files in PC-accessible format (FAT16, FAT32, etc). And what is the *full* SD-card mode anyway? - Why do I need FAT32? If I can live with the 2GB limit, any Windows OS can access FAT16 still, right? I ask because I understand that FAT16 is much easier to implement. - Anyone have a link to a free FAT16 library? This looks promising, but other recommendations appreciated... https://www.marcusbannerman.co.uk/index.php/research/electronicspics/40-pic-projects/76-fat32-library-for-pic18-devices.html - Anyone have a recommendation for a good book on the subject? I found this, but the reviews don't tell me that it will get me a good understanding on using SD cards with PICs... http://www.amazon.com/Card-Projects-Using-PIC-Microcontroller/dp/185617719X/ref=sr_1_1?s=books&ie=UTF8&qid=1339589318&sr=1-1 <http://www.amazon.com/Card-Projects-Using-PIC-Microcontroller/dp/185617719X/ref=sr_1_1?s=books&ie=UTF8&qid=1339589318&sr=1-1> Cheers, -Neil.

Curious, when discussing SD here, are we including SDHC? And would an SDHC card always be able to operate in a device setup for a regular SD card? I would think so, but found references that suggest otherwise based on differences between the SD 1.0/1.1 spec and SD 2.0 spec. Cheers, -Neil. On 6/17/2012 9:12 PM, IVP wrote: {Quote hidden}>> I, IIRC, have seen about 400 kbytes/sec and others have verified >> this number. Still, it's much above your 1 kbit/sec figure > I use SD cards for dsPIC .wav storage and find even retrieval with > SPI has a disappointingly low ceiling > > Reading one file of 44100Hz, 16-bit stereo (176.4 kbytes/sec) is > OK but when trying to read much faster reliably you run into latency > problems in the card controller, as Martin says. SPI is not the native > comms for an SD card and presumably the card controller just can't > keep up translating SPI to its 4-bit parallel O/S. In bursts you can > read up to 350-400 kbytes/sec but it's not sustainable, unlike the > transfers seen between say PC and card via a proper reader/writer > which uses 4-bit parallel

> Curious, when discussing SD here, are we including SDHC? Yes. I don't think the basic ability to deal with SPI was improved, and why would they, in the evolution from SD to SDHC I've used most cards from 2GB SD to 32GB SDHC Micro and not noticed any that perform significantly better than others in SPI mode. And I tried, because I hoped one would As I understand it, the inclusion of a useable SPI mode is just "throwing the amateurs a bone", as you pay for access to 4-bit parallel spec Jo

> > As I understand it, the inclusion of a useable SPI mode is just > "throwing the amateurs a bone", as you pay for access to 4-bit > parallel spec > Has anyone reverse engineered the 4 bit SD/SDHC communications protocol and published it? One would assume that it uses the same command set as the SPI mode, but in Nybble mode (Like LCD's can do 4 bit or 8 bit). Presumably R/E is allowed so does one also have to buy a license in order to use 4 bit mode? Of for that matter SPI mode?

I have seen code posted for XMOS processors. Warnings regarding copyrights and permissions are at the top of the code. http://github.xcore.com/repo_index/sc_sdcard_readme.html I'm just beginning to explore these XMOS chips, interesting architecture. LyleHaze On 6/21/12, Robert Rolf <TakeThisOuTRobert.RolfEraseMEspam_OUTualberta.ca> wrote: {Quote hidden}>> >> As I understand it, the inclusion of a useable SPI mode is just >> "throwing the amateurs a bone", as you pay for access to 4-bit >> parallel spec >> > > Has anyone reverse engineered the 4 bit SD/SDHC communications protocol and > published it? > One would assume that it uses the same command set as the SPI mode, but in > Nybble > mode (Like LCD's can do 4 bit or 8 bit). > > Presumably R/E is allowed so does one also have to buy a license in order > to use 4 bit mode? > Of for that matter SPI mode? > > R >

On 6/21/2012 6:00 PM, Lyle Hazelwood wrote: >> ... >> >> Presumably R/E is allowed so does one also have to buy a license in order >> to use 4 bit mode? >> Of for that matter SPI mode? >> >> R From what I've seen in recent research, it's apparently more than just paying to get the standard, but also royalties for making/selling any device that interfaces to SD cards using anything other than the SPI interface. See also http://en.wikipedia.org/wiki/SD_card#Openness_of_the_standar

Oh, also see this... http://electronics.stackexchange.com/questions/5628/do-i-need-to-pay-royalties-to-the-sd-card-people-if-my-device-just-happens-to On 6/21/2012 11:10 PM, Neil wrote: {Quote hidden}> On 6/21/2012 6:00 PM, Lyle Hazelwood wrote: >>> ... >>> >>> Presumably R/E is allowed so does one also have to buy a license in order >>> to use 4 bit mode? >>> Of for that matter SPI mode? >>> >>> R > > From what I've seen in recent research, it's apparently more than just > paying to get the standard, but also royalties for making/selling any > device that interfaces to SD cards using anything other than the SPI > interface. See also > http://en.wikipedia.org/wiki/SD_card#Openness_of_the_standard