EK-TM4C1294XL: UARTs in TM4C1294XL

Thank you for quick reply.

Of course I tested this example, but I got the impression that the interrupt was generated after 16 characters were received. If there was more data, I lost it. I always turned the light on when I entered the interrupt and turned it off before exiting. The lamp did not blink after each received character, and I think it should in this mode. Of course, I tested the state of the lamp with a logic analyzer, because I probably wouldn't do it by my own eyes :-)

OK, I need to run this example again.

I experimented a bit with this example and may have accidentally changed something.

Johnny D said:

but I got the impression that the interrupt was generated after 16 characters were received.

This is an echo example. If you type just one character on the terminal, it will echo back that character, right? This means it is not waiting for 16 characters to receive before echoing back but rather one character will generate an interrupt. 

Well, yes, but I'm not interested in what function the sample program performs. Echo not echo. I expect an interrupt after each character, and I don't see them being generated that way in this example.
I have to analyze the data stream character by character, because what characters are sent depends on my other actions. Suppose I need to detect the sequence for example 0x01, 0x02, 0x03, 0x04, 0x05, 0x06 transmitted in a much longer packet. It makes no sense to buffering data, because it may turn out that most of it will not interest me at all.

Hi,

  Why don't just place a breakpoint in UARTIntHandler? I just tried it and the processor immediately stops at the ISR after one character is entered in the terminal window. This means the interrupt is generated after one character is received. 

Hi,

It happens as you write if single characters are sent. That is: character, gap, character, gap, etc. Then, indeed, there is an interrupt after each character. However, if the characters are sent one after the other without pauses, an interrupt is reported after 8 characters (half FIFO - default parameter). But I seem to have FIFO turned off.
I would like an interrupt to be reported after every character in the stream where there are no gaps between the characters.

My UART is initialized like this:

g_ui32SysClock = MAP_SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ |
                                             SYSCTL_OSC_MAIN |
                                             SYSCTL_USE_PLL |
                                             SYSCTL_CFG_VCO_480), 120000000);

ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_UART0); 
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
ROM_IntMasterEnable();
GPIOPinConfigure(GPIO_PA0_U0RX);

GPIOPinConfigure(GPIO_PA1_U0TX);
ROM_GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1);
ROM_UARTConfigSetExpClk(UART0_BASE, g_ui32SysClock, 115200,
                            (UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE |
                             UART_CONFIG_PAR_NONE));
UARTTxIntModeSet(UART0_BASE, UART_TXINT_MODE_EOT);
ROM_IntEnable(INT_UART0);
ROM_UARTIntEnable(UART0_BASE, UART_INT_RT | UART_INT_RX);

Johnny D said:

However, if the characters are sent one after the other without pauses, an interrupt is reported after 8 characters (half FIFO - default parameter). But I seem to have FIFO turned off.
I would like an interrupt to be reported after every character in the stream where there are no gaps between the characters.

Hi,

  I think the reason is that in the example for UARTIntHandler, a non-blocking call is used to read the input. In addition, the ISR is always checking for available characters in the FIFO. While you are processing incoming data in the ISR, there is a new character waiting already. Therefore, ISR is not exited as more data is available. If you look at my below modified code, I change to using blocking call and don't check for available characters in the RXFIFO. I also added a variable 'count' that indicates the number of times the ISR is entered. In Tera terminal, I input a 16-character string. If you look at the count in the expression window at upper right, the count shows 16. This means the ISR is entered 16 times.  

void
UARTIntHandler(void)
{
    uint32_t ui32Status;

    count++;

    //
    // Get the interrrupt status.
    //
    ui32Status = ROM_UARTIntStatus(UART0_BASE, true);

    //
    // Clear the asserted interrupts.
    //
    ROM_UARTIntClear(UART0_BASE, ui32Status);

    //
    // Read the next character from the UART and write it back to the UART.
    //
    ROM_UARTCharPut(UART0_BASE,
    		ROM_UARTCharGet(UART0_BASE));

Hi Charles,
It's starting to work for me. I have yet to investigate exactly what happens when using buffered and unbuffered instructions. I must exactly check what is the difference between them.
And the fact that only one interrupt was generated was caused by the "while" instruction from the example, which I used thoughtlessly in my program.
We are getting close to solving the problem, but I have one more doubt, which I will try to solve myself, and if not, I will bother you a bit more ;-)