On Sat, Feb 11, 2012 at 4:21 AM, Martin Cerveny <[email protected]> wrote:
> Hello.
>
> 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.
> command error_t SoftwareInit.init() {
> call SpiResource.request();
> }
>
> Resource.request() fails (EBUSY). I debug code and I found that
> internal data structure "resQ" FcfsResourceQueueC was not
> initialized (to NO_ENTRY (eg. 0xff)) FcfsResourceQueueC.Init.init() was
> not called for
> that resource.
>
> app.c (nesc translated output) contain this:
>
> static error_t RealMainP__SoftwareInit__init(void ){
> unsigned char __nesc_result;
> __nesc_result = RF230DriverLayerP__SoftwareInit__init(); //
> <========================
> __nesc_result = ecombine(__nesc_result, RandomMlcgC__Init__init());
> __nesc_result = ecombine(__nesc_result,
> /*RF230RadioC.MessageBufferLayerC.MessageBufferLayerP*/MessageBufferLayerP__0__SoftwareInit__init());
> __nesc_result = ecombine(__nesc_result, NeighborhoodP__Init__init());
> __nesc_result = ecombine(__nesc_result,
> /*RF230RadioC.UniqueLayerC.UniqueLayerP*/UniqueLayerP__0__Init__init());
> __nesc_result = ecombine(__nesc_result,
> /*RF230RadioC.SendResourceC.Queue*/FcfsResourceQueueC__3__Init__init());
> __nesc_result = ecombine(__nesc_result, PutcharP__Init__init());
> __nesc_result = ecombine(__nesc_result,
> /*Atm1281UsartShare1P.ArbiterC.Queue*/FcfsResourceQueueC__2__Init__init());
> __nesc_result = ecombine(__nesc_result, SerialPrintfP__Init__init());
> __nesc_result = ecombine(__nesc_result,
> WserialIeeeEui64P__SoftwareInit__init()); // <========================
> __nesc_result = ecombine(__nesc_result,
> /*At45dbC.Arbiter.Queue*/FcfsResourceQueueC__1__Init__init());
> __nesc_result = ecombine(__nesc_result,
> /*Atm128SpiC.Arbiter.Queue*/FcfsResourceQueueC__0__Init__init()); //
> <=========================
> __nesc_result = ecombine(__nesc_result, At45dbP__Init__init());
> __nesc_result = ecombine(__nesc_result,
> /*AlarmCounterMilliP.Atm128AlarmAsyncC.Atm1281AlarmAsyncP*/Atm1281AlarmAsyncP__0__Init__init());
> return __nesc_result;
> }
>
> My call is in "WserialIeeeEui64P__SoftwareInit__init" (or
> RF230DriverLayerP__SoftwareInit__init)
> but arbiter initialization is initializad after that in
> "FcfsResourceQueueC__0__Init__init".
> (RF230,eui serial eeprom,At45db,+3 more to spi are on same arbitrated spi
> bus).
>
> What is this (bug or feature) ?
>
> 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.
>
> Thanks, Martin Cerveny
> _______________________________________________
> 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
