This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SD card Serial Peripheral Interface with MSP430 launchPad

Other Parts Discussed in Thread: MSP430G2231, MSP430G2553

Hi

I'm somewhat new to the world of SPI and I was wondering if anyone had, or could point me in the direction of a good example of code that interfaces the MSP430 launchPad with anything (preferably a microSD card) via an SPI connection.  

I have already tried using the code that came with the following paper from ti

http://www.ti.com/lit/an/slaa281b/slaa281b.pdf

but the code was written for the  MSP430F161 package rather than the MSP430G2231 that comes with the launchPad.  The files that are on this paper use up too much FLASH and RAM than is available on the launchPad, so I was wondering if anybody knew of a code example that would be more compatible with the MSP430G2231.  

Thanks in advance;

Greg Wells

  • Check 43oh's SPI implementation using the USCI of the 2553. It uses Petite FatFs for a low footprint fat implementation.

    Also check out the SDCard boosterPack

  • Thanks queirarard but in this forum they use the MSP430g2553 which apparently still has more memory and USCI capabilities which (at least according to the header files) does not come with the MSP430g2231 package.  I appreciate the response but it doesn't seem like this approach is going to work for me.  

  • Gregory Wells said:
    they use the MSP430g2553 which apparently still has more memory and USCI capabilities which (at least according to the header files) does not come with the MSP430g2231 package

    For accessing an SD card (the <2GB types - larger ones require much more) you'll need at least one 512 byte buffer in addition to any variables and the stack. With <1kb ram, write access is impossible and read access is difficult to handle. If trying to implement/interpret a FAT file system, you'll need at least a lot of additional state variables, even if it might be possible (but clumsy and slow) to have only one buffer. More are more.

    About the USCI, well, yes, using USCI SPI hardware is much faster and convenient, but the SPI communication can as well be done with the simpler USI - or even in plain software.
    However, the USCI allows you to send a byte in an 8 clock cycles (with hand-crafted code to stuff it), while USI requires 16 for the transfer and additional cycles between two byte transfers, as it does not have double-buffering. With a 16MHz MSP, the peak throughput with USCI is 2MB/s, with USI I estimate you're limited to 512k/s and in plain software, well, it depends on your hacking skills, but it is much less. In the range of 100k/s I'd guess.

    So to make teh existing code work, provided you have the required ram, you only have to replace the SPI read/write function and it works without USCI.

**Attention** This is a public forum