[Tinyos Core WG] Boot Order

[David Moss]

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.  

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();
  }

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.  

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.

It's much easier and cleaner to spin a task to delay lower priority boot
events than writing platform-dependent driver code.  Extending, not
changing, our current boot sequence would solve the problem.

-David





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


On May 22, 2008, at 7:04 AM, David Moss wrote:
> I understand the TEP, but if a driver is implemented with  
> interrupts, it
> would require modification to the driver or a custom driver to make  
> it work
> before the interrupts are enabled.
>
> It would be easier not to think about it by having the option to  
> access
> higher or lower priority Boot interfaces.
>
> It also sounds like other people have experienced this limitation  
> and fixed
> it with custom solutions.

I don't understand; most drivers will of course be implemented with  
interrupts. The point is that driver initialization (Init.init()) is  
the one place in TinyOS where you can block. Trying to handle  
interrupts in Booted() isn't possible, unless you manually string the  
continuations along. Or is the issue that drivers have already been  
implemented in this way and changing them is a pain? I'm leery of  
changing the boot sequence to support something which the boot  
sequence can already achieve.

Phil