"...execute one more instruction before any pending interrupt is served."
Good manual reading catch!
I wonder if there are any nested int handlers in TOS?
MS
Conor Todd wrote:
>From pages 13 & 14 of the ATMega128 manual, there are two types of
interrupts: ones which are triggered and remain triggered until they are
enabled and handled, and ones which only remain triggered as long as the
trigger signal is present (and which may not actually have interrupt
flags). I am doubtful that the second type would have been chosen for
such a core functionality as UART.
Another interesting thing to note is that "When the AVR exits from an
interrupt, it will always return to the main program and execute one
more instruction before any pending interrupt is served." So maybe that
one more instruction clears any pending interrupts before they can be
served?
- Conor
On 7/14/06, *jose m* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hello,
Recently, I've made lots and lots of questions about
transmitting data by UART port, because I have this
bug and cannot solve it (a little more, and I'll be a
lunatic). My problem is this: if my system runs
several days, one of these days (any one, any time),
no more UART transmission is done. The funny thing:
the system is still working normally, send and receive
radio packets, update internal data, etc, etc.
Debugging and testing during hours allows me to
conclude this: for some reason (hiding to me), in
component UARTM, the variable "state" remains TRUE,
and calls to UARTM's txByte(<data>) FAILs.
What can be the misterious reason of this problem? I
suspect that the tx interrupt never executes, but this
has low probability. If the ATMega128's interrupts are
disabled and enabled again, what happens with the
interrups signalled when they were disabled?
José
-------------------------------------------------------
async event result_t HPLUART.putDone() {
bool oldState;
atomic {
dbg(DBG_UART, "intr: state %d\n", state);
oldState = state;
state = FALSE;
}
/* Note that the state transition/event signalling
is not atomic.
It is possible, after state has been set to
FALSE, that
someone calls txByte before txDone is
signalled. The event
handler therefore may not be able to transmit.
Sharing
the byte level can be very tricky, unless we
assure non-preemptiveness
or have client ids. The UART implementation is
non-preemptive,
but is not assuredly so. -pal*/
if (oldState) {
signal ByteComm.txDone();
signal ByteComm.txByteReady(TRUE);
}
return SUCCESS;
}
-------------------------------------------------------
___________________________________________________________
1GB gratis, Antivirus y Antispam
Correo Yahoo!, el mejor correo web del mundo
http://correo.yahoo.com.ar <http://correo.yahoo.com.ar>
_______________________________________________
Tinyos-help mailing list
[email protected]
<mailto:[email protected]>
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
------------------------------------------------------------------------
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
