My SD driver uses dma. And is fully event driven. I don't remember the performance numbers I got out of it. Haven't done a 2nd pass performance tweak yet.
On Wed, Jan 2, 2013 at 7:40 AM, mike healy <[email protected]> wrote: > I'm a bit rusty on the details, but my understanding is that the 512byte > sector size is set from the SD card side. I'm not sure if this can be > changed or not (take a look at the SD spec. if you can get your hands on a > copy). > > Only other suggestion I would have is see if you can write a DMA based SD > driver. I know this has been started in the past by other people, but I > don't think anybody had the time to produce a reliable and robust version > (or at least I haven't heard of or seen one). This might not help with your > overall throughput rate, but it will free up the processor to do other > things while writing to the SD card. > > Mike > > > > On Wed, Jan 2, 2013 at 3:06 PM, Avishay Meron < > [email protected]> wrote: > >> mike, >> I followed your suggestion (also suggested by other users, thank you >> all!) for up-clocking. Indeed, there seems to be an improvement though this >> is still not enough. >> Another acceptable solution for my problem would be the ability to write >> smaller portions of data. >> If I can assume that (in some optimal implementation of the SD driver) >> writing, for example, 16 Bytes would take 16/512 time than writing 512, I >> would be also happy. >> Currently, the SD driver uses hard-coded values of 512. Does that imply >> one cant set smaller sectors? (did a small test over 256, 128, 64 ... all >> failed). >> Furthermore, I don't mind wasting entire sector just for sake of fast >> writing of small chunks (up to 32). >> I'm no expert as regarding the msp, but I've also tried the following (If >> any of you experts see a basic flaw in this approach, feel free to shout): >> Small change to the SD interface, to support varying buff length. i.e. >> command error_t SD.writeBlock(const uint32_t sector, uint8_t * buffer*, >> uint16_t count*). >> and calling: >> write_block(sector * 512, count, buffer); >> instead of the original call: >> write_block(sector * 512, 512, buffer); >> Surprisingly, there was no change in performance, no matter what count >> was set too.. >> >> Once again, I don't mined being extremely 'space' inefficient just for >> the sake of a suitable 'time' solution. >> If i could write small chunks but still keep writing rate of ~30kB/s, I'd >> be happy... >> Any ideas? >> >> P.S >> I'm using a SanDisk SD card... >> >> >> On Wed, Jan 2, 2013 at 2:37 PM, mike healy <[email protected]> wrote: >> >>> Avishay, >>> >>> As other people have already mentioned the simplest, and probably most >>> dramatic (in terms of speedup), way to improve the performance of the SD >>> card on the shimmer is to play with the clock settings. >>> >>> By default in TinyOS the MSP430 on the shimmer runs at 4MHz (generated >>> by the internal DCO). There is also an 8MHz resonator on all shimmer >>> devices which can be used to clock the MSP430. The simplest way to enable >>> this is to wire the FastClockC module ( >>> http://code.google.com/p/tinyos-main/source/browse/trunk/tos/platforms/shimmer/chips/msp430/FastClockC.nc) >>> to MainC.SoftwareInit. This will set MCLK to 8MHz and SMCLK to 4MHz. See >>> JustFatLoggingC.nc for an example of doing this: >>> http://tinyos.cvs.sourceforge.net/viewvc/tinyos/tinyos-2.x-contrib/shimmer/apps/JustFATLogging/JustFATLoggingC.nc?content-type=text%2Fplain >>> >>> You will also need to inform the SD driver about the change in SMCLK. >>> The easiest way of doing this is by adding the following line to your >>> applications Makefile: >>> PFLAGS += -DSMCLK_4MHZ >>> Again, JustFATLogging is a place to see this in action: >>> http://tinyos.cvs.sourceforge.net/viewvc/tinyos/tinyos-2.x-contrib/shimmer/apps/JustFATLogging/Makefile >>> >>> As an aside, when testing SD cards in the past, I found that performance >>> can vary dramatically across different cards (even among different products >>> from the same manufacturer), so it might also be worth trying a few >>> different type of cards (but also note that SPI mode support is a bit flaky >>> on cards by lots of manufacturers. I've found that Sandisk are by far the >>> best on this front in general) >>> >>> Mike >>> >>> >>> On Wed, Jan 2, 2013 at 10:51 AM, Michiel Konstapel < >>> [email protected]> wrote: >>> >>>> The default configuration for the 1611 runs the MCU at 4 MHz (main >>>> clock, MCLK). The USART which does SPI runs off SMCLK (sub-main clock) >>>> which is set to MCLK/4. That’s on the telosb, I don’t know if the shimmer >>>> platform does the same. The default setup does about 30-40 KB/sec, if I >>>> remember correctly. Of course, the flash writes also take time.**** >>>> >>>> ** ** >>>> >>>> You can speed things up by increasing the clock frequencies. SMCLK can >>>> be run at the same speed as MCLK, but the USART clock generator has a >>>> miminum divider of 2. The 1xx series has a maximum clock speed of 8 MHz, >>>> which would give you a 4 MHz SPI clock. Theoretically that’d max out at 0.5 >>>> MB/sec if you had zero overhead. Note that you’ll need a 3.6 V supply if >>>> you want to run at 8 MHz. It may work at a lower voltage, but then you’re >>>> outside the specs.**** >>>> >>>> ** ** >>>> >>>> You’ll want to study chapter 14 of the x1xx series user >>>> guide<http://www.ti.com/lit/ug/slau049f/slau049f.pdf>. >>>> That has all the nitty gritty details on the USART’s SPI mode. Note that >>>> TimerA is also clocked from SMCLK, and that’s used to generate the >>>> microsecond timer in TinyOS. If you change SMCLK, you’ll probably want to >>>> adjust the divider for TimerA so that still runs at 1 MHz.**** >>>> >>>> ** ** >>>> >>>> If you want to go faster still, while still using an MSP430 based >>>> platform, you could consider using one of the newer models like the >>>> Zolertia >>>> Z1 <http://www.zolertia.com/ti> or our >>>> G-Node<https://www.sownet.nl/index.php/products/gnode>which both use a 2xx >>>> series microcontroller. Those will run at 16 MHz, but >>>> neither comes with an onboard SD card slot, but both have the necessary I/O >>>> connections to add one. I don’t know if there’s already off-the-shelf nodes >>>> that use the 5xx series microcontrollers, some of which will do 25 MHz. >>>> **** >>>> >>>> ** ** >>>> >>>> Hope this helps,**** >>>> >>>> Michiel**** >>>> >>>> ** ** >>>> >>>> *From:* [email protected] [mailto: >>>> [email protected]] *On Behalf Of *Avishay >>>> Meron >>>> *Sent:* Tuesday, January 01, 2013 09:52 >>>> *To:* Eric Decker >>>> *Cc:* [email protected] >>>> >>>> *Subject:* Re: [Tinyos-help] Shimmer SD write speed**** >>>> >>>> ** ** >>>> >>>> Hi Eric. >>>> >>>> Thank you very much for you quick response. >>>> I guess I need to dig up. I'm using defaults... >>>> Anyway, I assume the default configurations you refer to are not set to >>>> about 20 times lower than max possible. >>>> 20 is the factor of improvement I'm looking for (at least!). >>>> I hope I'm not chasing pavements here...**** >>>> >>>> On Tue, Jan 1, 2013 at 5:32 AM, Eric Decker <[email protected]> wrote: >>>> **** >>>> >>>> ** ** >>>> >>>> How fast are you clocking the 1611 cpu?**** >>>> >>>> ** ** >>>> >>>> How fast are you clocking the SPI feeding the SD card?**** >>>> >>>> ** ** >>>> >>>> That will tell you the max theoretical rate you can transfer data.**** >>>> >>>> ** ** >>>> >>>> The high data rates to the SD assume the parallel 4 bit wide SD >>>> protocol rather than the SPI single bit stream that is probably used on the >>>> Shimmer or on my cards.**** >>>> >>>> ** ** >>>> >>>> On Mon, Dec 31, 2012 at 2:55 PM, Avishay Meron < >>>> [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? >>>> >>>> Happy new year to you all... >>>> >>>> Here is my test code... >>>> >>>> -----------------TestSDP.nc------------------- >>>> #include "TestSD.h" >>>> >>>> module TestSDP{ >>>> uses{ >>>> interface Leds; >>>> interface Boot; >>>> interface SD; >>>> interface StdControl as SDStdControl; >>>> } >>>> } >>>> >>>> implementation{ >>>> >>>> uint8_t resetData[SECTOR_SIZE], dummyData[SECTOR_SIZE]; >>>> int8_t data=0xff; >>>> uint32_t beginSector=1000000, numOfIt=20000, currSector; >>>> >>>> //Using numOfIt=20000, it took the application 17 min and 47 sec to >>>> run, >>>> //from which 8 min and 51 sec to write dummyData. >>>> //The rest of the time the application Formated the sectors. >>>> //This means writing at about 20kB/s >>>> >>>> event void Boot.booted(){ >>>> call Leds.led2Toggle(); >>>> call SDStdControl.start(); >>>> memset(resetData, 0, SECTOR_SIZE); >>>> memset(dummyData, data, SECTOR_SIZE); >>>> call Leds.led2Toggle(); >>>> } >>>> >>>> void FormatSectors() >>>> { >>>> uint32_t i=0; >>>> currSector=beginSector; >>>> for (i=0; i<numOfIt; i++, currSector++) >>>> { >>>> call SD.writeBlock(currSector, resetData); >>>> } >>>> } >>>> >>>> void WriteDummyData() >>>> { >>>> uint32_t i=0; >>>> currSector=beginSector; >>>> for (i=0; i<numOfIt; i++, currSector++) >>>> { >>>> call SD.writeBlock(currSector, dummyData); >>>> } >>>> } >>>> >>>> async event void SD.available(){ >>>> call Leds.led0Toggle(); >>>> FormatSectors(); >>>> call Leds.led0Toggle(); >>>> call Leds.led1Toggle(); >>>> WriteDummyData(); >>>> call Leds.led1Toggle(); >>>> call Leds.led2Toggle(); >>>> } >>>> >>>> async event void SD.unavailable(){ >>>> } >>>> } >>>> >>>> -----------------TestSDC.nc------------------- >>>> >>>> configuration TestSDC{ >>>> } >>>> implementation{ >>>> components MainC, LedsC, SDC, TestSDP as app; >>>> app.Boot -> MainC.Boot; >>>> app.Leds -> LedsC; >>>> app.SD -> SDC; >>>> app.SDStdControl -> SDC; >>>> } >>>> >>>> -----------------TestSD.h------------------- >>>> #ifndef TEST_SD_H >>>> #define TEST_SD_H >>>> #define SECTOR_SIZE 512 >>>> #endif /* TEST_SD_H */ >>>> >>>> **** >>>> >>>> Best >>>> Avishay**** >>>> >>>> ** ** >>>> >>>> _______________________________________________ >>>> Tinyos-help mailing list >>>> [email protected] >>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >>>> **** >>>> >>>> >>>> >>>> **** >>>> >>>> ** ** >>>> >>>> -- >>>> Eric B. Decker >>>> Senior (over 50 :-) Researcher**** >>>> >>>> >>>> >>>> >>>> -- **** >>>> >>>> Best >>>> Avishay**** >>>> >>>> _______________________________________________ >>>> Tinyos-help mailing list >>>> [email protected] >>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >>>> >>> >>> >> >> >> -- >> Best >> Avishay >> > > -- Eric B. Decker Senior (over 50 :-) Researcher
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
