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