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
