[Tinyos Core WG] Boot Order

[David Moss]

Ah - SpiByte is indeed the piece I've been missing.  Drivers like the radios
and flash should provide a standalone initialization module which simply
shuts off the chip at init.  This chip initialization module could be
referenced by platform code so you don't have to think about it - similar to
the behavior now, but modularized.  This way, you won't need the full chip
driver to automatically put every chip to sleep at boot.

Thanks Phil,

-David



-----Original Message-----
From: Philip Levis [mailto:pal at cs.stanford.edu] 
Sent: Friday, May 23, 2008 7:27 PM
To: David Moss
Cc: 'TinyOS Core WG'
Subject: Re: [Tinyos Core WG] Boot Order


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