Well, I'm using the UART component for serial
communication, and I say that this happen to me a lot
of times.
Take a look at the UARTM code:
----------------------------------------------
async event result_t HPLUART.putDone() {
bool oldState;
atomic {
dbg(DBG_UART, "intr: state %d\n", state);
oldState = state;
state = FALSE;
}
if (oldState) {
signal ByteComm.txDone();
signal ByteComm.txByteReady(TRUE);
}
return SUCCESS;
}
async command result_t ByteComm.txByte(uint8_t data)
{
bool oldState;
atomic {
oldState = state;
state = TRUE;
}
if (oldState)
return FAIL;
call HPLUART.put(data);
return SUCCESS;
}
--------------------------------------------------
My system has several timers, sends and receive radio
packets, sense temperature, and send data through an
UART connected to a mux. All the atomic blocks are
really short (one or two assigments max), events has
less than ten lines each, and almost all the data
(except some flags) are manipulated in tasks. I've
tested the system, and sooner or later (three, four
days, even a week) the global variable "state"
remains with the value "TRUE", and, for this reason,
even when the system continues his execution, no data
is transmitted through UART.
I assume that this happens because HPLUART.putDone()
is never signalled, and so "state" keeps the r-value
"TRUE" for ever (the only solution is reset).
I've rewrited the UARTM code, removing "state" flag,
and the system runs just fine, except for the
integrity of UART data. I don't like this unsafe
solution, and I want to know if there is a better one.
Thanks!
José
--- Philip Levis <[EMAIL PROTECTED]> escribió:
>
> On Jul 12, 2006, at 12:31 PM, Conor Todd wrote:
>
> > The documentation for TinyOS says that interrupts
> are DISABLED
> > within "atomic" sections of code, such that no
> asynchronous will
> > even occur, since asynchronous events are
> generated by interrupts.
> >
>
> This all depends on the hardware. "Disable
> interrupts" usually means
> "do not execute interrupts." However, if an
> interrupt goes off, the
> hardware sets a bit. If the bit is 1 when interrupts
> are re-enabled,
> then it clears the bit and signals the interrupt.
> This behavior leads
> to the basic problem of losing interrupts if they
> happen too fast;
> even if the interrupt occurs 5 times, there is only
> one bit so it
> will execute once. These timing constraints are one
> reason why atomic
> sections and interrupts should be short.
>
> A basic OS textbook is a good place to refer to for
> a discussion of
> these issues; I'd recommend the BSD book.
>
> Phil
>
>
_________________________________________________________
Horóscopos, Salud y belleza, Chistes, Consejos de amor:
el contenido más divertido para tu celular está en Yahoo! Móvil.
Obtenelo en http://movil.yahoo.com.ar
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
