[Tinyos Core WG] Boot Order

[Vlado Handziski]

I agree with Phil. The telos initialization code is a leftover from
tinyos-1.x since the boot sequence has been standardized after the initial
port. There is nothing in the current architecture that prevents this to be
rewritten using proper commands from the GeneralIO and SpiByte interfaces.

Vlado

On Sat, May 24, 2008 at 4:26 AM, Philip Levis <pal at cs.stanford.edu> wrote:

>
> On May 23, 2008, at 10:53 AM, David Moss wrote:
> > An Init interface will complete when the Task queue is empty.
> > Waiting for an
> > interrupt breaks that model, which is the reason why interrupts are
> > disabled
> > during Init.
>
> No -- you can wait for an interrupt with a self-posting task. Or,
> just spin on the interrupt pending flag (no need to enable).
>
> >
> > That, in the past, has lead to platform-specific driver
> > initialization code
> > like this (MotePlatformC.nc):
> >
> >   void TOSH_FLASH_M25P_DP() {
> >     //  SIMO0, UCLK0
> >     TOSH_MAKE_SIMO0_OUTPUT();
> >     TOSH_MAKE_UCLK0_OUTPUT();
> >     TOSH_MAKE_FLASH_HOLD_OUTPUT();
> >     TOSH_MAKE_FLASH_CS_OUTPUT();
> >     TOSH_SET_FLASH_HOLD_PIN();
> >     TOSH_SET_FLASH_CS_PIN();
> >
> >     TOSH_wait();
> >
> >     // initiate sequence;
> >     TOSH_CLR_FLASH_CS_PIN();
> >     TOSH_CLR_UCLK0_PIN();
> >
> >     TOSH_FLASH_M25P_DP_bit(TRUE);   // 0
> >     TOSH_FLASH_M25P_DP_bit(FALSE);  // 1
> >     TOSH_FLASH_M25P_DP_bit(TRUE);   // 2
> >     TOSH_FLASH_M25P_DP_bit(TRUE);   // 3
> >     TOSH_FLASH_M25P_DP_bit(TRUE);   // 4
> >     TOSH_FLASH_M25P_DP_bit(FALSE);  // 5
> >     TOSH_FLASH_M25P_DP_bit(FALSE);  // 6
> >     TOSH_FLASH_M25P_DP_bit(TRUE);   // 7
> >
> >     TOSH_SET_FLASH_CS_PIN();
> >
> >     TOSH_SET_SIMO0_PIN();
> >     TOSH_MAKE_SIMO0_INPUT();
> >     TOSH_MAKE_UCLK0_INPUT();
> >     TOSH_CLR_FLASH_HOLD_PIN();
> >   }
> >
>
> Not really; this code is for the most part just hacked (still
> bleeding) from 1.x; no-one bothered to make it cleam.
>
> > This is bad. Architecturally, the flash driver itself should be
> > responsible
> > for putting the flash chip into deep sleep using the SPI bus... not
> > some
> > platform-specific code in a platform directory.
>
> Agreed. But I don't think this is because of the architecture, rather
> just a 1.x holdover.
>
> >
> > TEP 107 does allow you to enable interrupts during Init, as long as
> > you turn
> > them back off and don't let any other component capture an
> > interrupt (other
> > components should enable their own interrupts when they're ready to
> > handle
> > them anyway).  Would you say that the code above could be rewritten
> > into the
> > flash driver in SoftwareInit by enabling interrupts, accessing the
> > SPI bus,
> > and spinning a task until the SPI bus commands are complete?  Doing
> > so would
> > still require platform-dependent code to enable/disable the correct
> > SPI
> > interrupts if you don't want to turn all of them on.
>
> Actually, what I'd do is use SpiByte to send the commands. Since it
> blocks, interrupts being disabled is not a problem.
>
> Phil
> _______________________________________________
> Tinyos-2.0wg mailing list
> Tinyos-2.0wg at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-2.0wg/attachments/20080524/6537b4a1/attachment.htm