[Tinyos-devel] Issue: SoftwareInit, rf230, Resource, and LocalIeeeEui64C
cire831 at gmail.com
Wed Feb 15 13:35:16 PST 2012
The primary problem is the rf230 initilization code needs access to an
arbritrated bus so it calls Resource.request from SoftwareInit.init. In
other words it needs to invoke resources whose data structures are also
initilized during SoftwareInit.init calls. Which is bad because there is
One suggestion is to move the initilization code off SoftwareInit and put
it in with the routines kicked off by Boot. I strongly suspect that has
other sequencing problems. There are certain things needing to be done to
the h/w prior to letting everyone have at it.
Another suggestion is to make the rf230 initilization code hit the hardware
directly and not go through the resource contention arbiter. Normally the
arbiter code automatically calls configuration code when the device is
granted to a requester. This code still needs to be there for when the
device is used "normally" (when the system is fully up). But essentailly
duplicate code needs to be written if the device is used directly for
initilization purposes during SoftwareInit. This isn't desireable in a
resource constrained system. It would be better to use the same
initilization code if a simple mechanism can be found for using it.
In other words we would be accessing the device using two different access
methods, one during SoftwareInit and the other after the system is up.
This is sub-optimal.
I would suggest that we would want a system state used during boot where
core functions of tinyos are provided, such as arbitration but restricted
in that only system tasks would be running. This is what would get used
by the rf230 code when arbitrating during initilization. It would also be
used to provide a sequenced boot initilization such as used by the mm4 mote
(my beast) when bringing up its different subsystems.
In other words there would be a SystemInitBoot that gets signalled from the
current RealMain. By default this SystemInitBoot would signal the current
MainC.Boot. But this gives a well defined place to wire in other
bootstrap provisions if needed.
Something along this line can be seen at:
On Mon, Feb 13, 2012 at 11:07 PM, Miklos Maroti <mmaroti at math.u-szeged.hu>wrote:
> Hi Guys,
> I agree that there is a problem with initialization. Just for the
> background: the RF230 needs to get the SPI bus to initialize the chip
> (bring it into low power). This should be called before Boot.booted,
> because otherwise the initialization code could be mixed with
> StdControl.start. I could redesign it, but still the initialization is
> hard inTinyOS.
> If I remember, the Init function could be called multiple times, and
> if a component needs to initialize other components, then it could
> call them directly. I think this does not work in practice. The
> platform and software init is not a solution. We could design
> components that do the waiting and scheduling, but it would require
> more wiring and larger executables.
> On Sun, Feb 12, 2012 at 12:27 PM, Eric Decker <cire831 at gmail.com> wrote:
> > Martin Cerveny has run into a problem and has discovered some issues with
> > SoftwareInit, Resource.request, and radio stacks that need to discussed
> > 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
> > 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
> > 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
> > also initilize its structure using SoftwareInit.
> > But there is no underlying ordering mechanism for SoftwareInit, so the
> > initilization can occur after rf230 SoftwareInit uses the queue for its
> > Resource.request. Using Resources that get initilized by SoftwareInit
> > SoftwareInit presents an ordering problem.
> > 2) The second problem involves IeeeEui64 and mechanisms used to obtain
> > 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.
> > But this raises the problem raised in item 1 above.
> > I have a solution for this but it would violate the letter of TEP22. It
> > uses a sequence boot that starts when Boot.booted is signalled. It is
> > I bring up my mm5 mote.
> > --
> > Eric B. Decker
> > Senior (over 50 :-) Researcher
Eric B. Decker
Senior (over 50 :-) Researcher
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tinyos-devel