On Wed, Apr 27, 2011 at 1:20 PM, steve ayer <a...@handhelds.org> wrote:
> 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. > I've carefully looked at what Steve did. When he talked about common files being under shimmer/span I expected to see a lot more duplication then what I found. It looks really good. What that tells me is Janos did a really good job of getting the platform/hw interface right. And Steve did a good job of implementing another instance of it. This is good. I think this is a good modle for how to transition fairly complicated functionality over time. Eventually we will want to think about which implementation should be the default/primary. When cc2420x has been tested enough it might make sense to make it the primary/default. > (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 > > <m.konsta...@sownet.nl> 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 > >> <m.konsta...@sownet.nl> 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-msp430 mailing list > tinyos-msp...@millennium.berkeley.edu > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-msp430 > -- Eric B. Decker Senior (over 50 :-) Researcher
_______________________________________________ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
