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
_______________________________________________
Shimmer-users mailing list
[email protected]
https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users
