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.
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.
> 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.
>
>
>
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)
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.
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.
> > - 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.
>
> > - 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.
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.
> 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.
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.
> 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 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.
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.
>> 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
> 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
>
> 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?
>>
>> 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
> 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
narwani.org> wrote:
