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 > <[email protected]> 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: [email protected] 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; >> [email protected] >> 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 >> <[email protected]> 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 > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-msp430 _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
