• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 78 subscribers
  • Views 3987 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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+MSP430+FAT

Varun Joshi
Prodigy 60 points
Other Parts Discussed in Thread: MSP430F2416

Hello, My project is a datalogger using the msp430f2416, the data is stored in a SD card. I know this topic must be an old one. But still I seriously need some help as I am new to this and any help will be deeply appreciated. I have read a number of articles on SD interfacing and FAT implementation, some of which are: The foust appnote, allan evans appnote, ti's-slaa281b, chan's FATfs. I am using a 2 gig card so FAT16 is definitely my pick. I have only tested the slaa281b by a simple led glowing program.

Some doubts that came to my mind were:

1. Can I use USCI B1 to communicate in SPI mode through DMA?

2. Can any of you give me an idea of how to store in csv format?

3. FAT implementation is greatly tormenting me and it would be really helpful if any of you who worked on something like this could give me some example?

4. Can I use bit banging(even when my requirement is storing in FAT and in csv format) or is too slow or impossible? 

Thank you in advance...

 

  • 0
    Guru 227245 points

    Varun Joshi said:
    Can I use USCI B1 to communicate in SPI mode through DMA

    No. According to the users guide, there ar eno DMA triggers for USCIB1, only for UCA/B0 and UCA1.

    Varun Joshi said:
    Can any of you give me an idea of how to store in csv format?

    Simple: It is a plain text file. The data is organized in rows and columns, where column data is separate by a ',' and rows by a line feed.
    If the data contains a comma itself, you should use double quotes around each column data.
    Some programs capable of reading CSV format interpret the first row as a 'header' row rather than a 'data row'.
    CSV simply means 'comma separated value'.

    Varun Joshi said:
    Can I use bit banging(even when my requirement is storing in FAT and in csv format) or is too slow or impossible

    One doesn't have to do anything with the other. The SD card doesn't care what you write, whether it is CSV, binary, all zeroes or sound samples and whether you write the data in a flat memory model or a FAT file system. The SD car dis just a block device - you write blocks of data (typically 512 bytes per block, but on SD cards >2GB the block size is larger). Whether you have a file system driver that gives certain blocks a certain meaning (FAt table, directory entry, whatever) or not is unimportant for the SD card and the SD write algorithm.
    And what you put into your files and in which granularity should be unimportant for the file system driver.

    However, the 4k ram on the 2416 will likely be not enough for both, the file system driver and your application, especially if you want to use SD cards >2GB. Even on an unoptimized system that constantly needs to read FAT data and directory sectors from the card, the minimum required internal buffer size for the file system is 1k. You should consider the 2417 instead, which has 8k ram.

  • 0 in reply to Jens-Michael Gross
    Prodigy 60 points

    Thank you..that opened my eyes in a lot of regards.

    Jens-Michael Gross said:

     Whether you have a file system driver that gives certain blocks a certain meaning (FAt table, directory entry, whatever) or not is unimportant for the SD card and the SD write algorithm.

    So please bear with me and correct me if I am wrong. I can write the chan's FATfs drivers(as an example) onto my device and write the low level disk io and I am good to go...no matter what i use in the low level disk io...bit banging or dma or any non dma approach if any.

     

    Jens-Michael Gross said:

    No. According to the users guide, there ar eno DMA triggers for USCIB1, only for UCA/B0 and UCA1.

    Is there any non DMA approach present which can communicate with SD card in SPI mode?..

     

    Jens-Michael Gross said:

    However, the 4k ram on the 2416 will likely be not enough for both, the file system driver and your application, especially if you want to use SD cards >2GB. Even on an unoptimized system that constantly needs to read FAT data and directory sectors from the card, the minimum required internal buffer size for the file system is 1k. You should consider the 2417 instead, which has 8k ram.

    I  have to use an SD card which is less than 2 gigs(preferrably 256/512mb) and I will be collecting data after every minute or half a minute. This data will be sent forward to SD using bit banging as I prefer a non-dma approach(it is imperative for me to use usci b1...courtsey the board I have been given to work with).

    Would it still be neccessary for me or better for me to shift to 2417...though it is not an issue as the pinout is the same...

    Correct me if I am wrong:

    But I am guessing it still will be better because the ram requirements for the FAT drivers will remain the same no matter what sd card i use...except if it goes above 2gb...then i will have to use fat 32 and will definitely have to shift to 2417...

  • 0 in reply to Varun Joshi
    Guru 227245 points

    Varun Joshi said:
    I can write the chan's FATfs drivers(as an example) onto my device and write the low level disk io and I am good to go...no matter what i use in the low level disk io...bit banging or dma or any non dma approach if any.

    So it should be. Besides plain I/O you will likely need to provide some means of device topography (at least total size, physical block size and similar infos), as the FS driver itself cannot know it.

    Varun Joshi said:
    I  have to use an SD card which is less than 2 gigs(preferrably 256/512mb) and I will be collecting data after every minute or half a minute.

    The problem is, that the FS driver needs to buffer the data internally, as it can only write complete clusters. And besides the plain data, there is also the directory and the FAT that must be accessed. 4kb will surely work for this, but it will leave a significantly reduced amount of ram for your application. And since you're collecting the data in some sort of buffer ...

    It might be better to jsut write the data to the file as soon as it comes in, and the FS driver writes it to the media as soon as a sector is full. Saves one buffering level.
    But that is something you'll have to check for yourself.

    Varun Joshi said:
    This data will be sent forward to SD using bit banging as I prefer a non-dma approach

    There is a huge difference between bit banging and using the USCI. Bit banging means that you use two plain GPIO pins and handle all the setting of clock and data lines yourself bit by bit.
    Using the USCI, you just write one byte at a time and the USCI hardware will shift the individual bits in and out for you. DMA is not really needed, except you want to squeeze the last bit of speed form the SPI interface.
    In theory, the USCI can send and receive in master mode with full system clock. This means 25MBit  = ~3MB/s. (or 160µs per 512 byte block). To get this, you'll need to use DMA. Without DMA, you'll end up with ~half of that when unsing hand-optimized assembly code. In plainC only ~1/3 or 1/4 of MCLK can be used as SPI clock or you'll have a 'stuttering' transfer (whcih doesn't hurt, but also brings no benefit over a slower clock). If you want to use IRQs for the transfer, things are even slower, but then you don't have to do busy-waiting loops. Anyway, if you use IRQs, another buffering stage might be necessary, as the FS will likely expect teh buffer written/filled when the write function returns. Which it isn't when you use an IRQ controlled transfer.

    Varun Joshi said:
    Would it still be neccessary for me or better for me to shift to 2417

    As I said - it depends on your application. The FS driver itself should be fine wiht 4kb and less (I think, 2k should be enough, but that's just a guess). Leaving only 2k for your application, including stack and data buffer. The FS driver should state what memory requirements it has.
    Sometimes more is simply more :)

    If the pinout is the same, you can try with the smaller one and switch to the bigger if you discover that you need more ram. That's the advantage of the MSP sub-families.

  • 0 in reply to Jens-Michael Gross
    Prodigy 60 points

    Thank you...those were some pretty basic errors of mine...and you cleared them big time...bbye

**Attention** This is a public forum