This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Bug in uartEcho.c?

Genius 5820 points

In UART-example "uartEcho.c" within ISR there is a strange statement for the receiving threshold reached interrupt:

        case UART_INTID_RX_THRES_REACH:
            rxByte = UARTCharGetNonBlocking(SOC_UART_0_REGS);
            UARTCharPutNonBlocking(SOC_UART_0_REGS, rxByte);
        break;

Is this really correct? Or shouldn't one read from the RX FIFO until no more data are available before leaving the ISR? When it is done this way it looks like the interrupt is fired for every new byte that arrives.

May be this implementation corresponds to the bug in UARTCharGetNonBlocking() so that it wasn't able to implement this example in a correct wy because for the wrong implemnetation of UARTCharGetNonBlocking()?

  • qxc,

    Looked into this and I don't think there is anything wrong with the way the ISR is being fired for uartEcho example implementation.

    Also don't think there is a link between this example, and your suggestion on improving the UARTCharGetNonBlocking() function. We appreciate the feedback you are giving to improve our code.

    Lali
  • There is no problem in the way the interrupt is fired, but in the way it is handled!

    UART_INTID_RX_THRES_REACH signals the RX buffer is full, correct? So from my understanding at this point the whole RX FIFO should be read. With the current implementation only one character is read and with the next character received the same interrupt is fired too. So you would get a burst of interrupts for every character - which then is in no way faster or more effective than some kind of stupid polling.