The cc2420 and derived drivers (including the CC2520) have an outstanding bug.
I don't remember if I've fixed this in the downstream TinyProd code. I do know that its hasn't been fixed in the development tree yet. I don't know what the plans are for fixing it, but it would be good if it got fixed. The bug in question has been reported as: Issue 131<http://code.google.com/p/tinyos-main/issues/detail?id=131> On Wed, Jun 27, 2012 at 5:27 AM, "Erdélyi Ádám [Edöm]" < [email protected]> wrote: > Hi, > > I had the same problem while interfacing CC2520 radio with MSP430F5438A uc. > Martin's second solution eliminates the problem, but this way I cannot rely > on any TinyOS repository if I want to publish only my platform implementation. > Is there any other way to change the order of function calls during > initialization? > > Adam Erdelyi > > > Hello. > > On Sat, 11 Feb 2012, Eric Decker wrote: > >* I have problem with Resource.request() in SoftwareInit.init(), > >simple code*>* (the same code as in > >RF230DriverLayerP.SoftwareInit.init()):* > >* You can't do this in SoftwareInit.init.*>* Why? Because FcfsResource > >gets initialized via SoftwareInit.init and order of initialization is not > >stated nor can you count on it.*>* SoftwareInit does not guarantee any > >ordering.*>* ----> You can't call Resource.request for a Resource that uses > >Fcfs are the queuing mechanism.*>* Do it from Boot.booted.* > I read about this issue in "TOS programming book" in chapter "4.4. > Multiple wirings". (The order of the calls is not defined.) > > There are following issues: > > 1) The standard tinyos code uses this wrong mechanism. For example (at least): > ./platforms/mulle/fix/RF230DriverHwAckP.nc > ./platforms/mulle/fix/RF230DriverLayerP.nc > ./chips/rf230/RF230DriverLayerP.nc > ./chips/rf230/RF230DriverHwAckP.nc > ./chips/rf212/RF212DriverLayerP.nc > > 2) How to implement "LocalIeeeEui64C" on external shared bus that must be > available before the Boot.booted() event (TEP122). > > >* How to establish "specific initialization ordering" for > >MainC.SoftwareInit (tep107) ?*>**>* What are you referring to in TEP107. 107 > >doesn't say anything about specific ordering.* > Yes, TEP107. > Yes, TEP107 does not say anything _how_ to implement ordering. > But there is statement: > > ... "Components whose initialization does not directly depend on hardware > resources SHOULD wire to MainC.SoftwareInit. If a component requires a > specific initialization ordering, then it is responsible for establishing > that ordering. Due to the semantics of Init, this is usually quite rare; a > component SHOULD NOT introduce initialization dependencies unless they are > required." .... > > Is there some mechanism to establish call order ? > > I see two solution. > > 1) Add next initialization layer between PlatformInit and SoftwareInit. > > 2) Rebind "component's data initialization"/"software data init" from > SoftwareInit.init() to PlatformInit.init(). (and modify TEP107) > > For example: > > =================================================================== > --- tos/system/SimpleFcfsArbiterC.nc (revision 5889) > +++ tos/system/SimpleFcfsArbiterC.nc (working copy) > @@ -89,11 +89,11 @@ > uses interface ResourceConfigure[uint8_t id]; > } > implementation { > - components MainC; > + components RealMainP; > components new FcfsResourceQueueC(uniqueCount(resourceName)) as Queue; > components new SimpleArbiterP() as Arbiter; > > - MainC.SoftwareInit -> Queue; > + RealMainP.PlatformInit -> Queue; > > Resource = Arbiter; > ResourceRequested = Arbiter; > =================================================================== > --- tos/system/FcfsArbiterC.nc (revision 5889) > +++ tos/system/FcfsArbiterC.nc (working copy) > @@ -96,11 +96,11 @@ > uses interface ResourceConfigure[uint8_t id]; > } > implementation { > - components MainC; > + components RealMainP; > components new FcfsResourceQueueC(uniqueCount(resourceName)) as Queue; > components new ArbiterP(uniqueCount(resourceName)) as Arbiter; > > - MainC.SoftwareInit -> Queue; > + RealMainP.PlatformInit -> Queue; > > Resource = Arbiter; > ResourceRequested = Arbiter; > =================================================================== > > M.C> > > > > _______________________________________________ > Tinyos-help mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > -- Eric B. Decker Senior (over 50 :-) Researcher
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
