Hi Matthias, I've never had cause to use MMC cards, and only ever used
SD cards on one system, that might change sometime, but so far I either
have plenty of storage on board or run with a flash chip.

Al

On 2/06/2014 9:07 PM, Matthias Weingart g...@pentax.boerde.de [msp430]
wrote:
> "Onestone o...@bigpond.net.au [msp430]" :
>
>> Matthias I have documents from the SD card specification that show
>> different start up and initialisation procedures for <=2Gb cards and
>>> =2Gb cards. That is what I based the comment on. I have tried reading
>> 4G and 8G cards with code that works perfectly with 2G and lower cards
>> and it doesn't recognise the card.
> Ok. From the practice: I can say it is no rocket science, you just need to
> tweak the code a little bit, but this is not more difficult than the
> switching from MMC to SD-cards.... :-)
>
> M.
>
> Posted by: Matthias Weingart
>
>
>

Beginning Microcontrollers with the MSP430

"Onestone o...@bigpond.net.au [msp430]" :

> Matthias I have documents from the SD card specification that show
> different start up and initialisation procedures for <=2Gb cards and
> >=2Gb cards. That is what I based the comment on. I have tried reading
> 4G and 8G cards with code that works perfectly with 2G and lower cards
> and it doesn't recognise the card.

Ok. From the practice: I can say it is no rocket science, you just need to
tweak the code a little bit, but this is not more difficult than the
switching from MMC to SD-cards.... :-)

M.

Posted by: Matthias Weingart

Matthias I have documents from the SD card specification that show
different start up and initialisation procedures for <=2Gb cards and
>=2Gb cards. That is what I based the comment on. I have tried reading
4G and 8G cards with code that works perfectly with 2G and lower cards
and it doesn't recognise the card. Also I didn't say you couldn't go
faster, simply that the example code I was able to find was based around
a sample/store sequential process, and wouldn't run much faster with the
fixed delays they used. It was based around an App note from MSU,
because at the time although the *.pdf for SLAA281 was available I was
not able to find the zip file with the example code. Most
implementations I found at the time I was interested in SD cards was
based on this App note from F.FOUST

Al

On 2/06/2014 7:06 PM, Matthias Weingart g...@pentax.boerde.de [msp430]
wrote:
> "Onestone o...@bigpond.net.au [msp430]" :
>
>> The stuff I found on Ti and other sites relates back to the same MIT
>> paper and was a very slow sequential sample/store system, probably no
>> faster than 100 samples a second. Unlike FLASH memory, which completes
>> the write operation after /CS has been released an SD card requires CS
>> to be held when using SPI. There are newer parts in the 5xxx series and
>> 6xxx series that have integrated SD card hardware I believe, but I might
>> be getting mixed up with the 55xx series DSP.
>>
>> If there isn't integrated SD card hardware then you need a licence to
>> use the SD interface. I have only used the SPI interface, which isn't
>> strictly a conventional SPI interface as there is a 'handshake' token
>> after most communications which has unspecified timing. There are also
>> several different types of interface. The older 2GB limit format was
>> easier to deal with, but you can't find 2GB cards very easily now. The
>> interface for larger memory cards is slightly more complex, requiring
>> extra stages during the init/discovery cycle. I haven't got any tested
>> code for larger cards. It is sometimes difficult to put all the
>> documentation together, but I have packaged the basics for you and will
>> send them direct..
>>
>> Al
> Al,
> this is not true. SDHC (up to 32Gig) is very similar to SD (up to 2Gig),
> The differences are minor: other blocksize (before (SD and MMC) the address
> was in real bytes, with SD-HC the address is in "blocks") and a different
> type number..
> Write speed over SPI is quite slow, but not as slow as you wrote - i got
> some 100kbytes/s; it seems it is getting slower as bigger the cards get.
> There is a big delay after writing a 512bytes sector, until the SD is
> getting out of the busy state. I think the reason is because a Gig-SD is
> writing a much bigger page (even when you just write 512 bytes). The delay
> at 16MB-MMC cards is much lower. Maybe you can write faster in case you use
> the multi-block write mode (I have never tried that).
>
> You can start using the SD-card example from TI - it is only the low level
> driver (with no filesystem): slaa281b (search ti.com ; there is also a
> zip-file with source code)
>
> Google shows me this two sources for FAT32 implementation
> http://elm-chan.org/fsw/ff/00index_e.html
> http://www.dharmanitech.com/2009/01/sd-card-interfacing-with-atmega8-
> fat32.html
> and there are more...
>
> However, the new exFat (over 32Gig) is more complicated...
>
> M.
>
>
> Posted by: Matthias Weingart
>
>
>

It seems petite FAT-FS for the Launchpad is all you need :-)
http://doc.43oh.com/The_Card_Reader_SDCard_BoosterPack

M.

Posted by: Matthias Weingart

"Onestone o...@bigpond.net.au [msp430]" :

> The stuff I found on Ti and other sites relates back to the same MIT
> paper and was a very slow sequential sample/store system, probably no
> faster than 100 samples a second. Unlike FLASH memory, which completes
> the write operation after /CS has been released an SD card requires CS
> to be held when using SPI. There are newer parts in the 5xxx series and
> 6xxx series that have integrated SD card hardware I believe, but I might
> be getting mixed up with the 55xx series DSP.
>
> If there isn't integrated SD card hardware then you need a licence to
> use the SD interface. I have only used the SPI interface, which isn't
> strictly a conventional SPI interface as there is a 'handshake' token
> after most communications which has unspecified timing. There are also
> several different types of interface. The older 2GB limit format was
> easier to deal with, but you can't find 2GB cards very easily now. The
> interface for larger memory cards is slightly more complex, requiring
> extra stages during the init/discovery cycle. I haven't got any tested
> code for larger cards. It is sometimes difficult to put all the
> documentation together, but I have packaged the basics for you and will
> send them direct..
>
> Al

Al,
this is not true. SDHC (up to 32Gig) is very similar to SD (up to 2Gig),
The differences are minor: other blocksize (before (SD and MMC) the address
was in real bytes, with SD-HC the address is in "blocks") and a different
type number..
Write speed over SPI is quite slow, but not as slow as you wrote - i got
some 100kbytes/s; it seems it is getting slower as bigger the cards get.
There is a big delay after writing a 512bytes sector, until the SD is
getting out of the busy state. I think the reason is because a Gig-SD is
writing a much bigger page (even when you just write 512 bytes). The delay
at 16MB-MMC cards is much lower. Maybe you can write faster in case you use
the multi-block write mode (I have never tried that).

You can start using the SD-card example from TI - it is only the low level
driver (with no filesystem): slaa281b (search ti.com ; there is also a
zip-file with source code)

Google shows me this two sources for FAT32 implementation
http://elm-chan.org/fsw/ff/00index_e.html
http://www.dharmanitech.com/2009/01/sd-card-interfacing-with-atmega8-
fat32.html
and there are more...

However, the new exFat (over 32Gig) is more complicated...

M.

Posted by: Matthias Weingart

Thanks Philip

Peter

From: m... [mailto:m...]
Sent: Monday, 2 June 2014 7:05 AM
To: m...
Subject: [msp430] Re: MicroSD data

I use SPI to talk to SDHC and you only need to hold CS low during the comms part of the write, and you can let the SD to the page commit while you go off and do something else. When you reselect the SD for another write you can read whether the commit has finished and decide what to do then.

I've found a great deal of difference in timings for committing by different brands, sizes, types etc when using the SPI method. Personally I prefer the Sandisk 16GB Mobile Ultra.

Good luck.

I use SPI to talk to SDHC and you only need to hold CS low during the comms part of the write, and you can let the SD to the page commit while you go off and do something else. When you reselect the SD for another write you can read whether the commit has finished and decide what to do then.

I've found a great deal of difference in timings for committing by different brands, sizes, types etc when using the SPI method. Personally I prefer the Sandisk 16GB Mobile Ultra.

Good luck.

The stuff I found on Ti and other sites relates back to the same MIT
paper and was a very slow sequential sample/store system, probably no
faster than 100 samples a second. Unlike FLASH memory, which completes
the write operation after /CS has been released an SD card requires CS
to be held when using SPI. There are newer parts in the 5xxx series and
6xxx series that have integrated SD card hardware I believe, but I might
be getting mixed up with the 55xx series DSP.

If there isn't integrated SD card hardware then you need a licence to
use the SD interface. I have only used the SPI interface, which isn't
strictly a conventional SPI interface as there is a 'handshake' token
after most communications which has unspecified timing. There are also
several different types of interface. The older 2GB limit format was
easier to deal with, but you can't find 2GB cards very easily now. The
interface for larger memory cards is slightly more complex, requiring
extra stages during the init/discovery cycle. I haven't got any tested
code for larger cards. It is sometimes difficult to put all the
documentation together, but I have packaged the basics for you and will
send them direct..

Al

On 1/06/2014 2:51 PM, 'Peter Grey' m...@ozemail.com.au [msp430] wrote:
> I am looking at interfacing to a MicroSD card and seem to remember
> that there was some discussion about this some months ago. Is there
> anything on Tis website about interfacing to a SD card?
>
> Thanks
>
> Peter