>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]> 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

_______________________________________________
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

Reply via email to