[Tinyos-devel] Issue: SoftwareInit, rf230, Resource, and LocalIeeeEui64C

Miklos Maroti mmaroti at math.u-szeged.hu
Tue Feb 14 07:32:30 PST 2012


Hi Phil,

On Tue, Feb 14, 2012 at 1:07 AM, Philip Levis <pal at cs.stanford.edu> wrote:
>
> On Feb 12, 2012, at 3:27 AM, Eric Decker wrote:
>
>>
>> Martin Cerveny has run into a problem and has discovered some issues with SoftwareInit, Resource.request, and radio stacks that need to discussed here because they are structural in nature.
>>
>> He has been looking at how to implement IeeeEui64 that requires access to an arbitrated bus (which requires a Resource).  In the process, of looking he discovered that mulle/rf230 and the main rf230 driver both call Resource.request from SoftwareInit.init.   Which has at least potential problems.
>>
>> The initial thread can be viewed easily at http://www.mail-archive.com/tinyos-help@millennium.berkeley.edu/msg40407.html
>>
>>
>> This raises two issues:
>>
>> 1) The rf230 initialization calls Resource.request from SoftwareInit.   Typically, a Resource implements its queuing discipline using some underlying queuing mechanism, like Fcfs.  However, the queue mechanism will also initilize its structure using SoftwareInit.
>
> It should not do this. It should do it in Boot.

Are you saying that Atm128SpiC (or whatever it is called) should do
its initialization in Boot? Or that the Arbiter should do its
initialization in Boot? Or that RF230 should do its chip
initialization in Boot? If the latter, then are you saying that NO
code can access any chip connected to the SPI or I2C or whatever bus
during the HardwareInit and SoftwareInit?

Miklos

>
>>
>> But there is no underlying ordering mechanism for SoftwareInit, so the queue initilization can occur after rf230 SoftwareInit uses the queue for its Resource.request.  Using Resources that get initilized by SoftwareInit from SoftwareInit presents an ordering problem.
>>
>>
>> 2) The second problem involves IeeeEui64 and mechanisms used to obtain this identifier.   TEP122 states that the id must be available prior to Boot.booted being called.
>>
>> Current implementations of IeeeEui64 are simple and do not need access to an arbitrated bus.  They basically are either hard code using the Berkeley Local modification or using busy waits and direct access to hardware.   Martin has been looking at how to obtain the Eui64 that resides out on a shared bus and hence needs to be Arbitrated.
>
> It does not need to be arbitrated in SoftwareInit, because there is exclusive execution. Just tap to the HAL or HPL.
>
> Phil
>
>



More information about the Tinyos-devel mailing list