all, default clock timings in tinyos for the msp430f1611 are 4mhz/1mhz for the mclk and smclk, respectively; that makes the spi bus run at 512khz (smallest divisor is 2).
regarding the shimmer family, all of the apps that i released that use the sd card switch to the xt2 running at 8mhz and uprate the smclk to mclk/2. this gets the spi bus going at 2mhz. if you do this, use the fastclock interface, and as eric pointed out, don't forget to include an app-local msp430dcospec.h (see -contrib/shimmer/apps/justfatlogging for an example) and a flag in your makefile. as for write speed: in practice, after resetting the clocks to run faster, measuring with a scope it takes the sd driver about 15ms to write one 512-byte block (about 34kbytes/s). the driver has a fair amount of overhead; i did get the bulk of this code from t.i., cleaned it up, tested and then released it. it's not pretty or terribly efficient, but it has been rock solid. back to timing: the time that it takes if you clocked 8 * 512 bits -- without interruption -- across a 2mhz bus is 2.05ms. yes, spi is a one-byte-at-a-time bus protocol, so additional byte-writes must be held until the tx buffer is empty, but this doesn't account for much. that leaves the sd setup time as the main culprit. as for adding more latency when using fatfs, gosh, is anyone really surprised by this? best to buffer data and write in size increments close to (but not more than) one block. but it's unrealistic to expect that the least efficient filesystem in the galaxy doesn't waste a bunch of time trying to account for everything when it's used with any kind of rigour. frankly, i've found chan's implementation to be remarkably good and quite reliable. lastly, if anyone wants to fix any obvious oversights or upgrade the driver, please do! send me the code and i'll consider it for release. bear in mind that a shimmer has limited computing resources, so if you're looking for high performance as opposed to economical operation, then you may be asking it to do things that are not part of its design... $0.02, steve On 01/02/2013 05:45 AM, André Rodrigues wrote: > Hi > Eric is right with the comments on the SD performance. > Just to add that I think the problem is not on FatFS but on the SD > driver that does not support > multiples writes; please see the last diagram in > http://elm-chan.org/docs/mmc/mmc_e.html. > At the time we made the measurements I did not know how to modify thar > part of the driver. > Regards, > André > > ----- Original Message ----- > *From:* Eric Decker <mailto:[email protected]> > *To:* Avishay Meron <mailto:[email protected]> > *Cc:* steve ayer <mailto:[email protected]> ; > [email protected] > <mailto:[email protected]> > *Sent:* Wednesday, January 02, 2013 9:54 AM > *Subject:* Re: [Tinyos-help] Shimmer SD write speed > > > > On Mon, Dec 31, 2012 at 2:55 PM, Avishay Meron > <[email protected] > <mailto:[email protected]>> wrote: > > Hi all. > Searching google and the mailing list, I haven't found an > explicit answer to my problem. Here goes: > I'm trying to test SD logging max write speed on a shimmer2r. > I've tried using the FatFS but got unsatisfying results. > So, I decided to write directly to the SD. Using a simple > application (see code below), I found that the max rate of SD > writing is about 20kB/s. Is that it? is this the maximum rate > possible? I was hoping to get at least 0.5 or 1 MB/s. Any > suggestions? > > > It looks like the Shimmer uses the default x1 DCOSpec settings which > is main cpu clock at 4MiHz and SMCLK MCLK/4 -> 1MiHz. Steve can > you verify that? > > I looked at the paper Andre sent. That CPU is being clocked at > 16MHz, and the SPI clocked at 4 MHz and they are seeing about 120 > KB/s. The Shimmer is clocking the SD at 1/4 that speed .... > 30KB/s. So the 20KB/s isn't unreasonable. > > Okay. Why?... > > SPI is a serial bus and it is being clocked at 1 MiHZ. 8 bits > takes 1 MiHZ/8 Bytes/s so this yeilds a theoretical max of 131,072 > B/s (about 128KiB/s). But that is if one is running the bus full > time. Which isn't going to happen. > > Now you've eliminated the overhead of the FatFS and are writing > directly to the card. I'm at a loss why you are losing about a > factor of 6. I wouldn't have guessed it was that bad. The SD > protocol running in SPI mode does have a bunch of overhead, so it > most likely the culpirit. I also don't know if the Shimmer folks > have done a tuning pass. Performance tuning requires a fair amount > of skill. > > > Now one quick test you can do is change the clock relationship. In > the current tinyos-main (as of 4449bba, master), MCLK (DCO) is 4 > MiHz, SMCLK divisor is /4, and the TA divisor (usec ticker) is /1. > If you change these to SMCLK divisor /1 and TA divisor to /4 the SPI > will now get clocked at 4 MiHZ and TA will still be at 1 uis (1 > binary micro second). > > You should see the raw SD performance go from 20KiB/s to around > 80KiB/s. It should be linear. > > > Now doing this experiment on the current tip of the trunk is rather > painful because the knobs are spread around all over the place. > > One of the things I did when I cleaned the core up was I fixed this. > I would recommend you shift over to using my new msp430 core. > It lives at https://github.com/tp-freeforall/prod(tp-master) > <https://github.com/tp-freeforall/prod>. There is a simple spec > file (DcoSpec.h) that specifies all the relationships. > > You would have to override the default file that comes from > tos/chips/msp430 with a platform specific one. > > > > Happy new year to you all... > > > -- > Eric B. Decker > Senior (over 50 :-) Researcher > > ------------------------------------------------------------------------ > > _______________________________________________ > Tinyos-help mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
