[Tinyos Core WG] SchedulerBasic

[Philip Levis]

On Feb 5, 2007, at 4:47 PM, Martin Leopold wrote:

> Hi All.
> I seem to be having a problem with a simple test program (for my  
> cc2430
> platform). I don't have any tasks and I echo a char back over the UART
> in interrupt context. If I loop forever in say in Boot.booted all is
> dandy, but if I let the system boot all the way, I don't seem to  
> get to
> my interrupt handler.
>
> If I'm not mistaken, what happens after the system boots is, that it
> ends up in the taskLoop (below). If I'm reading this correctly then my
> system will loop here forever with no help of recovery since  
> interrupts
> are off.
>
> Am I missing something obvious here or what? To me this doesn't seem
> right - sleep is called with interrupts off and there is no way to  
> post
> a new task from an interrupt.
>

Please read TEP 112:


``McuSleep.sleep()`` puts the microcontroller into a low power sleep
state, to be woken by an interrupt. This command deprecates the
``__nesc_atomic_sleep()`` call of TinyOS 1.x. Note that, as the 1.x
call suggests, putting the microcontroller to sleep MUST have certain
atomicity properties. The command is called from within an atomic
section, and MUST atomically re-enable interrupts and go to sleep. An
issue arises if the system handles an interrupt after it re-enables
interrupts but before it sleeps: the interrupt may post a task, but
the task will not be run until the microcontroller wakes up from sleep.

Microcontrollers generally have hardware mechanisms to support this
requirement. For example, on the Atmega128, the ``sei`` instruction
does not re-enable interrupts until two cycles after it is issued (so
the sequence ``sei sleep`` runs atomically).


Phil