RF2xx: Resource.requested called from SoftwareInit. Needs to be fixed.

[GoogleCodeExporter]

The following files call Resource.requested from SoftwareInit which is broken.

The Arbiter being used is Fcfs and requires the queue to be initialized.  This 
occurs via a wiring in SoftwareInit.   These wirings are unordered and thus the 
queue may or may not be initialized when Resource.requested is called from 
SoftwareInit.

These should probably be replaced by calls to Resource.immediateRequest.  This 
will change the execution path (previous event driven, changed to non-event).   
So careful evaluation should be done.

However, the current implementation is incorrect and an error waiting to happen.

tos/chips/rf230/RF230DriverHwAckP.nc
tos/chips/rf230/RF230DriverLayerP.nc
tos/chips/rf212/RF212DriverLayerP.nc

Original issue reported on code.google.com by cire...@gmail.com on 6 Apr 2012 at 6:14

[GoogleCodeExporter]

Original comment by philip.l...@gmail.com on 30 May 2012 at 4:37

[GoogleCodeExporter]

cc2420x and cc2520 drivers do the same thing as they all come from the same 
ancestry.

Original comment by thomas.s...@gmail.com on 27 Jun 2012 at 8:39

[GoogleCodeExporter]

The other option is to not use the pre-canned Fcfs in the driver, but wire one 
up "by hand" in a way that guarantees it to be initialized before use.

I'd consider using immediateRequest() to still be incorrect, as it's called on 
an uninitialized component. The code path turns out to be safe(?), but it's not 
the proper thing to do. Just my $.02 :)

Original comment by jmatts...@dius.com.au on 2 Jul 2012 at 1:14

[GoogleCodeExporter]

I agree that immediateRequest is a kludge (an thus somewhere on the incorrect 
side of things).   It was suggested only as an immediate temporary workaround 
while a more correct fix is done and brought in to the code base.

I am surprised that this is taking so long to fix.   The current code is 
clearly broken.

If it effected me directly or if it effects someone else who is using the 
TinyProd code base, I'd fix it there.   But I'm not currently using any of the 
radio stacks effected.    Sooo....    I am purposedly minimizing how much 
divergence between the main TinyOS development tree and TinyProd because then 
it is easier to track.

I'm hoping this will get fixed after 2.1.2 is released.   Although, I would 
think this is something that should be fixed for 2.1.2.

Original comment by cire...@gmail.com on 2 Jul 2012 at 3:15