sending HEX value using UARTCharPut()

mohammad sadoun said:

 the RealTerm software the received value is wrong

The code configures the UART in the Tiva device and then enters a loop which transmits characters continuously as quickly as possible. You might be encountering the same problem as described in https://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/534352

mohammad sadoun said:

I want to send HEX value to an external module the poin

Do you want to receive '55 'on realTerm or do you want to receive a 'U'?

mohammad sadoun said:

Please some one help me I have get this right in 3 days 

You've given yourself a very large task to complete in three days.

Robert

Hi Chester thanks for your reply

I tried to the delay solution but it didn't work the data is still wrong and I changed the baud rate to 9600 and it's still wrong
I don't know what is the problem can you please help me again.

thanks in advance

Hi Robert thank you for your reply

I want to receive HEX value for example 0x55.

I talked to my supervisor, he understood my situation.

please help how can I receive right HEX value on the terminal

Thanks in advance

mohammad sadoun said:

The below is my code

The code shows the UART transmit interrupt being enabled, but UARTCharPut being called in the main loop without any sign of an interrupt handler.

Is there a UART Tx interrupt handler in your project, and if not does commenting out the UARTIntEnable(UART0_BASE, UART_INT_TX) call change the behavior?

Sorry Mohammad, still not clear. To confirm, you want to receive the string '0x55' on the terminal?

Robert

Hi robert
No I want the value of 0x55 not the string "0x55"

mohammad sadoun said:

Hi I am using stellaris lm3s3748 EVP

I am not sure what the "lm3s3748 EVP" is, but can you check what frequency crystal is connected to the LM3S3748?

Some of the LM3S3748 development kits had a 8MHz crystal fitted, but the code is selecting a 16MHz:

mohammad sadoun said:

SysCtlClockSet(SYSCTL_SYSDIV_1 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN | SYSCTL_XTAL_16MHZ);

If the SYSCTL_XTAL_ value passed in the SysCtlClockSet() call doesn't match the actual crystal frequency then the calculated baud rate will be incorrect, which could explain why the incorrect character is received.

commenting out the UARTIntEnable(UART0_BASE, UART_INT_TX) doesn't change the behavior and what do you mean by interrupt handler, Because I saw it in the uart_echo.c example the function is declared but never used as shown below

//*****************************************************************************
//
// uart_echo.c - Example for reading data from and writing data to the UART in
//               an interrupt driven fashion.
//
// Copyright (c) 2009-2013 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 10636 of the EK-LM3S9D90 Firmware Package.
//
//*****************************************************************************

#include "inc/hw_ints.h"
#include "inc/hw_memmap.h"
#include "inc/hw_types.h"
#include "driverlib/debug.h"
#include "driverlib/gpio.h"
#include "driverlib/interrupt.h"
#include "driverlib/pin_map.h"
#include "driverlib/rom.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 FTDI 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.
//
//*****************************************************************************

//*****************************************************************************
//
// The error routine that is called if the driver library encounters an error.
//
//*****************************************************************************
#ifdef DEBUG
void
__error__(char *pcFilename, unsigned long ulLine)
{
}
#endif

//*****************************************************************************
//
// The UART interrupt handler.
//
//*****************************************************************************
void
UARTIntHandler(void)
{
    unsigned long ulStatus;

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

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

    //
    // 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));
    }
}

//*****************************************************************************
//
// Send a string to the UART.
//
//*****************************************************************************
void
UARTSend(const unsigned char *pucBuffer, unsigned long ulCount)
{
    //
    // Loop while there are more characters to send.
    //
    while(ulCount--)
    {
        //
        // Write the next character to the UART.
        //
        ROM_UARTCharPutNonBlocking(UART0_BASE, *pucBuffer++);
    }
}

//*****************************************************************************
//
// 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.
    //
    ROM_SysCtlClockSet(SYSCTL_SYSDIV_1 | SYSCTL_USE_OSC | SYSCTL_OSC_MAIN |
                       SYSCTL_XTAL_16MHZ);

    //
    // Enable the peripherals used by this example.
    //
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_UART0);
    ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);

    //
    // Enable processor interrupts.
    //
    ROM_IntMasterEnable();

    //
    // Set GPIO A0 and A1 as UART pins.
    //
    GPIOPinConfigure(GPIO_PA0_U0RX);
    GPIOPinConfigure(GPIO_PA1_U0TX);
    ROM_GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1);

    //
    // Configure the UART for 115,200, 8-N-1 operation.
    //
    ROM_UARTConfigSetExpClk(UART0_BASE, ROM_SysCtlClockGet(), 115200,
                            (UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE |
                             UART_CONFIG_PAR_NONE));

    //
    // 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((unsigned char *)"\033[2JEnter text: ", 16);

    //
    // Loop forever echoing data through the UART.
    //
    while(1)
    {
    }
}

OK, then you should get a 'U' in realterm when you have everything set up correctly (Get yourself an ASCII table if you don't have one already). Realterm can also be set to display the hex equivalent of each character received.

Also follow Chester's suggestion and check your crystal frequency. You should also measure the actual baud rate you are getting with an oscilloscope (or logic analyser).

Robert

Would it not be faster/easier for poster to FIRST send "Simple ASCII" such as: A B C - and note the results?

I've missed - or the results of such BASIC, Verifying Test - are hidden/awol...

Simplicity - always...

Actually 0x55 is a pretty good character to send, the alternating 1 and 0's make measuring actual baud rate very easy.

Not so good for terminal viewing I agree but one of realterm's strengths is the ability to set it to hex mode where it displays the hex for each incoming character so maybe still reasonable for this particular terminal emulator. A lot more reasonable if you have experience with realterm which I expect our time-starved poster does not.

Robert

Indeed Robert - 0x55 and its "partner in crime" 0xAA both provide that alternating 1/0 pattern.

That said - successfully viewing "normal" ASCII will build the poster's confidence - confirm the basic UART operation (or not) and provide a springboard for complexity - which I (always) believe should come later...

While we "feel" for this rush/pressured poster - none here caused his plight.   Sometimes - the PAIN from, "over-committing" must be FELT - so that its less likely to become a pattern.   Poster has not touched upon "How" he made such commitment (what was his calculus) and "Expecting/Hoping" for the best - proves not always foolproof - especially when inexperience and new learning are, "gorillas in the (mist) room..."

To add a comment here - the 0x55 and 0xAA patterns are most favourable when using a scope. To "just view received characters at the other side", any easily recognized ASCII sequence will do...

Indeed - and that was past suggested by this reporter... KISS lives - although in highly suppressed form - this space...