Re: [Tinyos-help] Shimmer SD write speed
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:cire...@gmail.com> > *To:* Avishay Meron <mailto:avishay.me...@mail.huji.ac.il> > *Cc:* steve ayer <mailto:a...@handhelds.org> ; > tinyos-help@millennium.berkeley.edu > <mailto:tinyos-help@millennium.berkeley.edu> > *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 > <mailto:avishay.me...@mail.huji.ac.il>> 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 al
Re: [Tinyos-help] [tinyos-msp430] rfxlink for Telos
all, i'd like to thank janos for doing this work, because it enabled me to port this stack over to the shimmer platforms, which i just checked in. both time resolutions compile/install/run, but i have not tested timestamping yet (i do have a volunteer already). apologies to janos, but i pre-emptively updated the make extras so that these platforms are included... so, support lives in support/make, and in cc2420x under tos/platforms/shimmer/chips, tos/platforms/shimmer2/chips, tos/platforms/shimmer2r/chips, and tos/platforms/span/chips. i did not duplicate the entire platform support, just placed the common files under shimmer and placed pin/bus support specifics in the other individual platforms. (novice users: cd to each directory and run svn update there.) all comments/tests/bug reports welcome. best, steve On 04/22/2011 03:37 PM, Janos Sallai wrote: > OK, I checked in the code. It can be enabled using the cc2420x extra > on the make command line (e.g. make telosb cc2420x). The > cc2420x.extra adds the cc2420x specific directories to the search > path, preceding everything else that's in there. That is, it shadows > the default clock/timer settings, the default cc2420 stack, serial > configuration, etc. Obviously, nothing gets shadowed when the cc2420x > extra is not supplied. That is, this change is absolutely > non-intrusive. > > The cc2420x extra can be used with the micaz, as well (make micaz > cc2420x). In fact, I removed the cc2420x specific search paths from > platforms/micaz/.platform, since they are now added to the include > path in cc2420x.extra. > > I also added support for 32khz timestamping on the telos, which can be > enabled using the cc2420x_32khz extra on the make command line (e.g. > make telosb cc2420x). Since 32khz timestamping does not require > changing how TimerA and TimerB are configured on the telos by default, > this setup does not impose any extra limitations on the number of > hardware alarms. > > Janos > > On Thu, Apr 21, 2011 at 8:59 AM, Michiel Konstapel > wrote: >> That depends - if the change is backwards compatible, then it should be fine >> to change the existing platform, but I got the impression that since there >> is such a large body of code out there for the telosb, that significant >> changes cannot be made without the risk of breaking a lot of existing >> applications: >> Certainly so for new platforms, but not for the telos. There's just too many applications that depend on the current cc2420 stack. So choosing the cc2420x stack must be a compile time option. >> >> Of course, you can always #ifdef the change and maintain the old code, but >> that only scales up to a certain point, and without knowing the "magic" >> #defines to invoke, people would still get the old, presumably worse, >> behaviour/performance. >> Michiel >> >> -Original Message- >> From: mmar...@gmail.com on behalf of Miklos Maroti >> Sent: Thu 21/04/2011 10:50 >> To: Michiel Konstapel >> Cc: Janos Sallai; Eric Decker; Markus Becker; Peter A. Bigot; TinyOS Msp430; >> tinyos-help@millennium.berkeley.edu >> Subject: Re: [tinyos-msp430] [Tinyos-help] rfxlink for Telos >> >> Hi Michiel, >> >> I think creating another platform is a very bad idea. I would like to >> use the fast SPI interface on both the shimmer2 and shimmer2r >> platforms, and possibly get the cc2420x driver working to improve the >> throughput. Do you think one needs to have a new platform for those as >> well? >> >> Miklos >> >> On Wed, Apr 20, 2011 at 6:32 PM, Michiel Konstapel >> wrote: >> I will put together a telos-specific code that allows for choosing >> compile time whether a) SMCLK should be DCO or DCO/4 (default), and b) >> selecting the timer configurations (timerB->32khz timerA->micro being >> the default). > > Why compile time? I would think given a platform configuration it should > just always be that way for the given platform. Certainly so for new platforms, but not for the telos. There's just too many applications that depend on the current cc2420 stack. So choosing the cc2420x stack must be a compile time option. >>> >>> If we assume a "platform" is hardware plus software (including >>> configuration of said hardware), couldn't you just define a new platform >>> (say, telosx) which has telosb (or similar) hardware, but the cc2420x radio >>> stack, faster default DCO, etc.? That way, you don't break any old code and >>> you're free to implement improvements on top of the old hardware. If people >>> want the new features, they'd have to explicitly port over their app to the >>> new platform, or at least check that their assumptions still hold when they >>> type "make telosx" instead of "make telosb". >>> Michiel >>> >> >> > > ___ > tinyos-msp430 mailing list > tinyos-msp...@millennium.berkeley.edu > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-
Re: [Tinyos-help] [tinyos-msp430] rfxlink for Telos
hi miklos, in the meantime, on shimmers you can certainly wire in FastClockC, which uses the platform's 8mhz xt2 and runs smclk at 4mhz, which will divert data bottlenecks away from the spi bus... $0.02, steve On 04/21/2011 04:50 AM, Miklos Maroti wrote: > Hi Michiel, > > I think creating another platform is a very bad idea. I would like to > use the fast SPI interface on both the shimmer2 and shimmer2r > platforms, and possibly get the cc2420x driver working to improve the > throughput. Do you think one needs to have a new platform for those as > well? > > Miklos > > On Wed, Apr 20, 2011 at 6:32 PM, Michiel Konstapel > wrote: > I will put together a telos-specific code that allows for choosing > compile time whether a) SMCLK should be DCO or DCO/4 (default), and >>> b) > selecting the timer configurations (timerB->32khz timerA->micro >>> being > the default). Why compile time? I would think given a platform configuration it >>> should just always be that way for the given platform. >>> Certainly so for new platforms, but not for the telos. There's just >>> too many applications that depend on the current cc2420 stack. So >>> choosing the cc2420x stack must be a compile time option. >> >> If we assume a "platform" is hardware plus software (including configuration >> of said hardware), couldn't you just define a new platform (say, telosx) >> which has telosb (or similar) hardware, but the cc2420x radio stack, faster >> default DCO, etc.? That way, you don't break any old code and you're free to >> implement improvements on top of the old hardware. If people want the new >> features, they'd have to explicitly port over their app to the new platform, >> or at least check that their assumptions still hold when they type "make >> telosx" instead of "make telosb". >> Michiel >> > > ___ > tinyos-msp430 mailing list > tinyos-msp...@millennium.berkeley.edu > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-msp430 ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] [Tinyos-devel] multiple copies of msp430hardware.h
hi janos,
i validated this code, which came from an old (OLD) mspgcc post, on a
scope, toggling a pin and measuring the duration.
doing it again now, with the stock 4mhz clock, a nominal 100us wait
takes 100.7us. pretty reasonable. at 8mhz, i see 105.1us.
with your code, we have a delay of 97.5us at 4mhz, and 50.85us at 8mhz
because it doesn't know the clock has sped up!
point is, it's a wash, but i have two clocks to support, so the current
plan must stay in place.
-steve
On 03/08/2011 03:03 PM, Janos Sallai wrote:
> Steve:
>
> I'm not sure that the two pieces of code are equivalent. In my case,
> there's also a nop within the loop. Without that, I the delay I got
> were less than a microsecond (on the telos, at least). Have you
> verified the timing of your code against a counter driven by the
> SMCLK?
>
> Janos
>
>
>
> On Tue, Mar 8, 2011 at 12:42 PM, steve ayer wrote:
>> hi steve,
>>
>> it's telling that your replacement is essentially what we've been using
>> for years:
>>
>> void brief_pause(register unsigned int n)
>> {
>>asm volatile("1: \n\t"
>> "dec%0 \n\t"
>> "jne1b\n\t"
>> : "+r" (n));
>> }
>>
>> #define TOSH_uwait(n) brief_pauseunsigned long long)n) *
>> TARGET_DCO_KHZ * 1024 / 100 - 2) / 3)
>>
>> again, note the dependence on TARGET_DCO_KHZ, but that's not the only
>> thing in the tree.
>>
>> anyone else have any suggestions?
>>
>> thanks,
>>
>> steve
>>
>> On 03/08/2011 01:23 PM, Stephen Dawson-Haggerty wrote:
>>> We (Janos and I) also noticed that BusyWaitMicro isn't great -- it
>>> came up when I was trying to figure out why the ds2401 driver isn't
>>> very reliable/portable, since a different version with hand-coded busy
>>> loops works fine.
>>>
>>> Janos wrote this replacement that fixes the ds2401 driver, but we
>>> haven't committed it because of the potential to break things. It
>>> appears the at45db is the only other code in the tree using
>>> BusyWaitMicro and that still works for me with this version.
>>>
>>> No option on the other points; seems like the right thing to do about
>>> #1 though is to fix busywait.
>>>
>>> Steve
>>>
>>> On Tue, Mar 8, 2011 at 5:18 AM, steve ayerwrote:
>>>> hello!
>>>>
>>>> i am the "offender" of public record.
>>>>
>>>> 1) our migration to tos-2.x initially used busywait until we noticed
>>>> some weird behavior. putting it on the scope, we observed that it was
>>>> inaccurate, iirc as much as 50% (slow) in some cases. as the tep
>>>> states: "BusyWait blocks for no less than the specified amount of time.
>>>>No explicit upper bound is imposed on the enacted delay, though it is
>>>> expected that the underlying implementation spins in a busy loop until
>>>> the specified amount of time has elapsed."
>>>>
>>>> shucks. especially when balancing the necessities of hardware specs and
>>>> application demands on the scheduler, close only counts in horseshoes.
>>>> so for pragmatic reasons, we're sticking with tosh_uwait, because it
>>>> works exactly as expected.
>>>>
>>>> 2) some of our platforms use an 8mhz crystal; applications that use it
>>>> and fail to set TARGET_DCO_KHZ to 8192 will be broken.
>>>>
>>>> 3) the separate copy for span was an oversight, and mike healy just
>>>> discovered it last week. i immediately changed it to point to the
>>>> single copy in shimmer/chips/msp430. oops.
>>>>
>>>> 4) our intention to not stay with a single variant of the msp430 will
>>>> track in architecture of upcoming platforms' code. it is our full
>>>> intention to align with and use as much mainline tos code as possible,
>>>> but not to sacrifice platform capabilities in the process (e.g., i
>>>> cannot for the life of me make the tos-2.x msp430 i2c code work properly).
>>>>
>>>> 5) the notion of shimmer* having a separate version of msp430hardware.h
>>>> is sub-optimal for who? if anything, it places a burden on me alone.
>>>> want me to change the name?
>>>>
>>>> -steve
>>>>
>>>> On 03/07/2011 08:57 PM, Eric Decker wrote:
>>>>>
Re: [Tinyos-help] [Shimmer-users] Software auto acknowledgements break packet timestamps in the C2420 driver
aha! why didn't you say so? i'll make the change now. thanks for pointing this out; please tell me when i miss details like that when you discover them, it helps me a great deal to have others my bugs. i committed the fix. thanks again. silvan, please let me know if this solves your problem (if you're using shimmer2, that is). -steve On 11/22/2010 08:48 AM, Miklos Maroti wrote: > Hi Steve, > > On Mon, Nov 22, 2010 at 2:35 PM, steve ayer wrote: >> hi. >> >> miklos, you may be confusing the configurations among the various shimmer >> revs, which have different pin layouts relative to the cc2420. on shimmer, >> the sfd signal is routed to a capture-capable pin on the msp430; on >> shimmer2, due to an oversight it was not, so a capture was manually >> implemented using an interrupt. this oversight was corrected for span and >> shimmer2r. > > I am using shimmer2. I know that shimmer2 does not have the hardware > capture feature and it is implemented in software. However, your > implementation uses TMilli as a time source and the time > synchronization on the CC2420 assumes that it has 32khz timers, > otherwise the TimeSyncPacket interfaces always returns FALSE in > isValid. > >> the code that you sent will break shimmer and shimmer2r, and the fix for >> shimmer2 was committed in january. > > The code I have attached should be applied to shimmer2 only, since it > does software time capture but uses the 32khz timer to do that! > >> silvan, how old is your tinyos-2.x codebase? is it from the current svn >> repository at googlecode? >> >> i'll be happy to help untangle this problem if it stems from up to date >> platform code. > > We use the latest SVN from google code. > > Best, > Miklos > >> >> -steve >> >> On 11/22/2010 03:14 AM, Miklos Maroti wrote: >>> >>> Hi Silvan, >>> >>> I think the problem is with the configuration of CC2420 on Shimmer. We >>> have run into this as well. Can you please two files in your >>> platforms/shimmer/chips/cc2420 with the ones I have attached and check >>> if this fixes your problem? >>> >>> Miklos >>> >>> On Mon, Nov 22, 2010 at 1:57 AM, Omprakash Gnawali >>> wrote: >>>> >>>> -- Forwarded message -- >>>> From: Silvan Nellen >>>> Date: Mon, Nov 8, 2010 at 7:36 AM >>>> Subject: [Tinyos-help] Software auto acknowledgements break packet >>>> timestamps in the C2420 driver >>>> To: >>>> "tinyos-help@millennium.berkeley.edu" >>>> >>>> >>>> Hello, >>>> >>>> >>>> >>>> I’m trying to run the FTSP test application (revision 5215 of >>>> http://tinyos-main.googlecode.com/svn/trunk) as described in >>>> tinyos-2.x/apps/tests/TestFTSP/Ftsp/README.txt on Shimmer. At first >>>> the nodes running TestFtspAppC didn’t seem to respond to the messages >>>> sent out by the beacon mote (java FtspDataLogger reported nothing). >>>> Using a packet sniffer I discovered that the FTSP motes send ACK >>>> packets for each beacon message but they don’t send report messages >>>> (which would then be picked up by the base station and ultimately be >>>> displayed by the FtspDataLogger). >>>> >>>> >>>> >>>> I looked at the CC2420 driver source code in >>>> tos/chips/cc2420/receive/CC2420ReceiveP.nc and used printf to see >>>> what’s going on, and I think I found the problem: the outgoing ACK >>>> messages trigger the SFD interrupt and cause a timestamp to be put in >>>> to the timestamp queue (line 190). If this happens BEFORE the >>>> timestamp of the incoming packet is read, the packet timestamp is >>>> cleared and the timestamp queue gets flushed (lines 633-635). >>>> Consequently all packets received by the FTSP test application contain >>>> invalid timestamps and are thus ignored (line 67 in TestFtsp.nc). >>>> >>>> >>>> >>>> Does that make sense? Is this a known problem? Has FTSP ever been >>>> tested with CC2420? >>>> >>>> >>>> >>>> As a temporary fix I added PFLAGS += -DCC2420_NO_ACKNOWLEDGEMENTS to >>>> the Makefile and I get messages from the FTSP motes now, however this >>>> fix doesn’t really address the cause of the problem… >>>> >>>> >>>> >>>> Silvan >>>> >>>> >>>> >>>> ___ >>>> Tinyos-help mailing list >>>> Tinyos-help@millennium.berkeley.edu >>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >>>> >>>> >>>> >>>> ___ >>>> Shimmer-users mailing list >>>> shimmer-us...@eecs.harvard.edu >>>> https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users >> >> ___ >> Shimmer-users mailing list >> shimmer-us...@eecs.harvard.edu >> https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users >> ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
Re: [Tinyos-help] [Shimmer-users] Software auto acknowledgements break packet timestamps in the C2420 driver
hi. miklos, you may be confusing the configurations among the various shimmer revs, which have different pin layouts relative to the cc2420. on shimmer, the sfd signal is routed to a capture-capable pin on the msp430; on shimmer2, due to an oversight it was not, so a capture was manually implemented using an interrupt. this oversight was corrected for span and shimmer2r. the code that you sent will break shimmer and shimmer2r, and the fix for shimmer2 was committed in january. silvan, how old is your tinyos-2.x codebase? is it from the current svn repository at googlecode? i'll be happy to help untangle this problem if it stems from up to date platform code. -steve On 11/22/2010 03:14 AM, Miklos Maroti wrote: > Hi Silvan, > > I think the problem is with the configuration of CC2420 on Shimmer. We > have run into this as well. Can you please two files in your > platforms/shimmer/chips/cc2420 with the ones I have attached and check > if this fixes your problem? > > Miklos > > On Mon, Nov 22, 2010 at 1:57 AM, Omprakash Gnawali > wrote: >> -- Forwarded message -- >> From: Silvan Nellen >> Date: Mon, Nov 8, 2010 at 7:36 AM >> Subject: [Tinyos-help] Software auto acknowledgements break packet >> timestamps in the C2420 driver >> To: >> "tinyos-help@millennium.berkeley.edu" >> >> >> Hello, >> >> >> >> I’m trying to run the FTSP test application (revision 5215 of >> http://tinyos-main.googlecode.com/svn/trunk) as described in >> tinyos-2.x/apps/tests/TestFTSP/Ftsp/README.txt on Shimmer. At first >> the nodes running TestFtspAppC didn’t seem to respond to the messages >> sent out by the beacon mote (java FtspDataLogger reported nothing). >> Using a packet sniffer I discovered that the FTSP motes send ACK >> packets for each beacon message but they don’t send report messages >> (which would then be picked up by the base station and ultimately be >> displayed by the FtspDataLogger). >> >> >> >> I looked at the CC2420 driver source code in >> tos/chips/cc2420/receive/CC2420ReceiveP.nc and used printf to see >> what’s going on, and I think I found the problem: the outgoing ACK >> messages trigger the SFD interrupt and cause a timestamp to be put in >> to the timestamp queue (line 190). If this happens BEFORE the >> timestamp of the incoming packet is read, the packet timestamp is >> cleared and the timestamp queue gets flushed (lines 633-635). >> Consequently all packets received by the FTSP test application contain >> invalid timestamps and are thus ignored (line 67 in TestFtsp.nc). >> >> >> >> Does that make sense? Is this a known problem? Has FTSP ever been >> tested with CC2420? >> >> >> >> As a temporary fix I added PFLAGS += -DCC2420_NO_ACKNOWLEDGEMENTS to >> the Makefile and I get messages from the FTSP motes now, however this >> fix doesn’t really address the cause of the problem… >> >> >> >> Silvan >> >> >> >> ___ >> Tinyos-help mailing list >> Tinyos-help@millennium.berkeley.edu >> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >> >> >> >> ___ >> Shimmer-users mailing list >> shimmer-us...@eecs.harvard.edu >> https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users ___ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
