- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Original question:
TM4C1294NCPDT: Looking for config.cgi file for enet_s2e project
Our product is using the TM4C1294NCPDT and software based on the enet_s2e reference example.
I have found that the data coming into our UART and then out the telnet port is bursty which has confused the desk top application connecting to our product by telnet. Our desk top poles several times a second with a protocol command ">04<CR>" That is a greater than sign, a zero a four and a carriage return which I will abbreviate as ">04". This is a request to our product for measurement information. Our product is to return a string.
The developer of the desk top application discovered that the response to the ">04" was what he called buffered up. Some times no response but after a subsequent ">04" was sent the instrument sent multiple responses.
I believe I have found the root cause in the enet_s2e reference design which displays such buffering and bursting of data through the telnet to UART connection.
With the reference enet_s2e project I wired PC6 to PN4 and PC7 to PN5 to connect the UARTs. Then I used RealTerminal to send repeatedly a text file containing only ">04" into one telnet port. RealTerm allows me to set inter-character delays and delays at end of line and delays before the tile to be sent is sent.
I captured and time stamped the data out the other telnet port with a Processing program I wrote which time stamps to milliseconds (since program started) . I see the ">04" command is passed through the two telnet pipes in bursts. In the screen shot I will provide there is a burst where the delay was 217 milliseconds and three ">04" commands were sent. See time stamp 2019 3 14 17 12 187874.
I would like to reduce or eliminate this burstyness.
I have begun to examine the enet_s2e code and see what I think as a 40 mS HOST_TMR_INTERVAL managing the telnet UART buffers and so I would have thought that the burstyness would be on the order of 40 mS not 200 mS.
Any improved insight would be appreciated.
I would like to understand the code enough to possibly flush the buffer when a <CR> or <LF> occures for example but am not sure that might violate the design in ways I can not anticipate.
I will add screen shots separate to this first post.
Here is a screen shot of RealTerm and my Processing Sketch with time stamped data.
Hello Charles,
Regarding, "I still think that somehow the peripheral is not enabled. I tried the UARTFIFODisable() in one of the TivaWare example and I don't see an issue."
Which example and which file and where did you make your experiment? I would like to become compitent with the TiviWare API to do this.
FYI, I continued reading the code in serial.c and found a place where the comments indicated the FIFO was set up. See below.
I commented out the line and tested and did not find the burstyness I had found before. So I think I found a fix.
I wanted to experiment with setting the FIFO size to 1/8 but since I cannot figure out the syntax and where to DisableFIFO I can not guess where to modify the code to change the FIFO size.
Any pointers would be appreciated.
Thank you,
Forrest Erickson
HI Forrest,
Glad that it is the UART FIFO that I was suspecting.
It is the uart_echo example I modified. The example can be found in <TivaWare_Installation>/examples/boards/EK-TM4C1294XL/uart_echo. Look for the UARTFIFODisable I inserted below. I ran the example I don't have any fault.
//*****************************************************************************
//
// uart_echo.c - Example for reading data from and writing data to the UART in
// an interrupt driven fashion.
//
// Copyright (c) 2013-2017 Texas Instruments Incorporated. All rights reserved.
// Software License Agreement
//
// Texas Instruments (TI) is supplying this software for use solely and
// exclusively on TI's microcontroller products. The software is owned by
// TI and/or its suppliers, and is protected under applicable copyright
// laws. You may not combine this software with "viral" open-source
// software in order to form a larger program.
//
// THIS SOFTWARE IS PROVIDED "AS IS" AND WITH ALL FAULTS.
// NO WARRANTIES, WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING, BUT
// NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
// A PARTICULAR PURPOSE APPLY TO THIS SOFTWARE. TI SHALL NOT, UNDER ANY
// CIRCUMSTANCES, BE LIABLE FOR SPECIAL, INCIDENTAL, OR CONSEQUENTIAL
// DAMAGES, FOR ANY REASON WHATSOEVER.
//
// This is part of revision 2.1.4.178 of the EK-TM4C1294XL Firmware Package.
//
//*****************************************************************************
#include <stdint.h>
#include <stdbool.h>
#include "inc/hw_ints.h"
#include "inc/hw_memmap.h"
#include "driverlib/debug.h"
#include "driverlib/gpio.h"
#include "driverlib/interrupt.h"
#include "driverlib/pin_map.h"
#include "driverlib/rom.h"
#include "driverlib/rom_map.h"
#include "driverlib/sysctl.h"
#include "driverlib/uart.h"
//*****************************************************************************
//
//! \addtogroup example_list
//! <h1>UART Echo (uart_echo)</h1>
//!
//! This example application utilizes the UART to echo text. The first UART
//! (connected to the USB debug virtual serial port on the evaluation board)
//! will be configured in 115,200 baud, 8-n-1 mode. All characters received on
//! the UART are transmitted back to the UART.
//
//*****************************************************************************
//****************************************************************************
//
// System clock rate in Hz.
//
//****************************************************************************
uint32_t g_ui32SysClock;
//*****************************************************************************
//
// The error routine that is called if the driver library encounters an error.
//
//*****************************************************************************
#ifdef DEBUG
void
__error__(char *pcFilename, uint32_t ui32Line)
{
}
#endif
//*****************************************************************************
//
// The UART interrupt handler.
//
//*****************************************************************************
void
UARTIntHandler(void)
{
uint32_t ui32Status;
//
// Get the interrrupt status.
//
ui32Status = ROM_UARTIntStatus(UART0_BASE, true);
//
// Clear the asserted interrupts.
//
ROM_UARTIntClear(UART0_BASE, ui32Status);
//
// Loop while there are characters in the receive FIFO.
//
while(ROM_UARTCharsAvail(UART0_BASE))
{
//
// Read the next character from the UART and write it back to the UART.
//
ROM_UARTCharPutNonBlocking(UART0_BASE,
ROM_UARTCharGetNonBlocking(UART0_BASE));
//
// Blink the LED to show a character transfer is occuring.
//
GPIOPinWrite(GPIO_PORTN_BASE, GPIO_PIN_0, GPIO_PIN_0);
//
// Delay for 1 millisecond. Each SysCtlDelay is about 3 clocks.
//
SysCtlDelay(g_ui32SysClock / (1000 * 3));
//
// Turn off the LED
//
GPIOPinWrite(GPIO_PORTN_BASE, GPIO_PIN_0, 0);
}
}
//*****************************************************************************
//
// Send a string to the UART.
//
//*****************************************************************************
void
UARTSend(const uint8_t *pui8Buffer, uint32_t ui32Count)
{
//
// Loop while there are more characters to send.
//
while(ui32Count--)
{
//
// Write the next character to the UART.
//
ROM_UARTCharPut(UART0_BASE, *pui8Buffer++);
}
}
//*****************************************************************************
//
// This example demonstrates how to send a string of data to the UART.
//
//*****************************************************************************
int
main(void)
{
//
// Set the clocking to run directly from the crystal at 120MHz.
//
g_ui32SysClock = MAP_SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ |
SYSCTL_OSC_MAIN |
SYSCTL_USE_PLL |
SYSCTL_CFG_VCO_480), 120000000);
//
// Enable the GPIO port that is used for the on-board LED.
//
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPION);
//
// Enable the GPIO pins for the LED (PN0).
//
ROM_GPIOPinTypeGPIOOutput(GPIO_PORTN_BASE, GPIO_PIN_0);
//
// Enable the peripherals used by this example.
//
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_UART0);
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);
//
// Enable processor interrupts.
//
ROM_IntMasterEnable();
//
// Set GPIO A0 and A1 as UART pins.
//
GPIOPinConfigure(GPIO_PA0_U0RX);
GPIOPinConfigure(GPIO_PA1_U0TX);
GPIOPinConfigure(GPIO_PB4_U0CTS);
GPIOPinConfigure(GPIO_PB5_U0RTS);
ROM_GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1);
ROM_GPIOPinTypeUART(GPIO_PORTB_BASE, GPIO_PIN_4 | GPIO_PIN_5);
//
// Configure the UART for 115,200, 8-N-1 operation.
//
ROM_UARTConfigSetExpClk(UART0_BASE, g_ui32SysClock, 115200,
(UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE |
UART_CONFIG_PAR_NONE));
UARTFlowControlSet(UART0_BASE, UART_FLOWCONTROL_TX|UART_FLOWCONTROL_RX);
// Disable FIFO
UARTFIFODisable(UART0_BASE);
//
// Enable the UART interrupt.
//
ROM_IntEnable(INT_UART0);
ROM_UARTIntEnable(UART0_BASE, UART_INT_RX | UART_INT_RT);
//
// Prompt for text to be entered.
//
UARTSend((uint8_t *)"\033[2JEnter text: ", 16);
//
// Loop forever echoing data through the UART.
//
while(1)
{
}
}
To change the FIFO level, see below API.
Charles,
Thanks for getting back with ideas.
Regarding, "...SysCtlPeripheralEnable..."
The UARTs are still being enabled with this function using the original code.
Screen shot below.
