CCS/UCD3138A64OEVM-662: interfacing wifi via uart

Shoeb ahmed

Part Number: UCD3138A64OEVM-662
Other Parts Discussed in Thread: UCD3138A64, UCD3138128

Tool/software: Code Composer Studio

Hello Sir, Can you please give some detail about to interface wifi(esp8266) module via UART pin in UCD3138a64 or some program or little detail. Thank you.

over 5 years ago

0 Amiel Hussain over 5 years ago

TI__Expert 4040 points

Hello,

An engineer is looking into this and will respond.

0 Ian Bower over 5 years ago in reply to Amiel Hussain

TI__Genius 17090 points

If you look at most of our EVM codes, you should see a sample UART initialization code, and also code to use it. In our power supply code, generally we use 4800 baud for the UART that we recieve data on. This means that we can just poll for receive data in the 10 KHz interrupt. In fact, at least theoretically, you could poll at baud rates up to 100K baud, since the byte rate will be 1/10th of the bit rate because there are 8 bits of data, plus a stop bit and a start bit. We transmit data from the background loop, since we control our own transmit rate.

Keeping the power supply running safely is the number one priority, so you need to be careful not to let the serial interface eat up all the real time. I have no idea what the requirements are for a wifi interface via an esp8266. However, other than the aforementioned need to put the power supply control and monitoring first, the UART on the UCD is not different at all from generic simple UARTs. It tells you, with a bit set and an optional interrupt, that it has a byte. It also tells you when it is ready to accept a byte. Both are buffered, so you can put a byte into the buffer while a byte is being sent, and you can read a byte from the buffer while another byte is coming in. If you can find code written for that type of a UART - ie. one without DMA or a bigger buffer - you should be able to use it on the UCD.

0 Shoeb ahmed over 5 years ago in reply to Ian Bower

Intellectual 335 points

How can I put at command in UART just I have done before in another platform and please type one or two commands as syntax and I am using UART1

0 Ian Bower over 5 years ago in reply to Shoeb ahmed

TI__Genius 17090 points

The problem with what you show above is that it would tie up the background task for a long time whenever you sent out the string. I don't think that's a good idea for running a power supply, because there should really be other tasks in the background, like PMBus.

If you want to do it the way above, that's really C programming, not specifically associated with the UCD. I don't really want to set the precedent of giving basic C programming advice on this forum.

To send out a string with a UART0 puts , you would use the string pointer handed to you in the function call, and have a loop that would wait until the UART was ready to send another byte, write the byte to the UART hardware buffer register, and then point to the next byte in the string.
When the next byte in the string was an EOF, you would stop, because EOF marks the end of the string.

You can seem some examples in the string variable section of the C Programming manual.

To make it a background task, I would have function call - uart_tx_handler. I would have a flag that says uart tx busy, and a character pointer.

If you wanted to still have a uart0_puts, I would have it load the pointer to the desired string into the character pointer, and then set the uart_tx_busy flag.

I would have a call to uart_tx_handler in the background loop.

uart_tx_handler would first check to see if the uart_tx_busy flag is set. If it is, it will then check to see if the UART is ready to accept data. If it is, it will check the byte pointed to by the pointer. If the byte is EOF, it will clear the uart_tx_busy flag. if not, it will write the byte to the UART hardware register, and increment the pointer.

If you want to send a series of text messages, you will need a state machine that has a state for each message. It will start the message, and then wait for the uart_tx_busy flag to be cleared before it starts the next message. If you want delays between messages, you can put a firmware counter in the standard interrupt that is loaded by the state machine with the desired time, and then counted down to 0 by the interrupt. The state machine can wait for the timer to go to zero, and then go to the next state. It's a bit more work than having a multi-threaded operating system to do it this way, but it's a lot more time efficient. and once you get used to it, it can be written quickly.

0 Shoeb ahmed over 5 years ago in reply to Ian Bower

Intellectual 335 points

I have to set a baud rate for 115200 what will be the value . for eg 202 is for 9600. what will be for 115200

0 Ian Bower over 5 years ago in reply to Shoeb ahmed

TI__Genius 17090 points

You want to use a 16 (decimal)

The equation is (1953125/baud rate) -1

If you use 115200, it will be coming in pretty fast - you won't be able to poll with the normal standard interrupt.

0 Shoeb ahmed over 5 years ago in reply to Shoeb ahmed

Intellectual 335 points

Sir you have posted the UART program in uart community it was running well on UART 0 pin . the problem i was facing on UART1 in initialization

*******************************************************************************************************************************************************

this code below running proper on uart 0 but same applying for UART1 after editing it is not running properly

void init_uart0(void)
{
volatile unsigned char rx_byte;

Uart0Regs.UARTCTRL3.bit.SW_RESET = 0; //software reset while initializing UART

Uart0Regs.UARTCTRL0.bit.DATA_SIZE = 7; //8 bits
Uart0Regs.UARTCTRL0.bit.STOP = 1; //2 stop bits
Uart0Regs.UARTCTRL0.bit.SYNC_MODE = 1; //asynchronous mode

Uart0Regs.UARTHBAUD.bit.BAUD_DIV_H = 0;
Uart0Regs.UARTMBAUD.bit.BAUD_DIV_M = 0;
Uart0Regs.UARTLBAUD.bit.BAUD_DIV_L = 49; //for 38400 //47 for control board, 44 for open loop

Uart0Regs.UARTRXST.bit.RX_ENA = 1 ;//enable RX

Uart0Regs.UARTTXST.bit.TX_ENA = 1;//enable TX

Uart0Regs.UARTINTST.all = 0xff; //these two statements are supposed to clear the status bits
Uart0Regs.UARTINTST.all = 0;

rx_byte = Uart1Regs.UARTRXBUF.bit.RXDAT; //clear RXRDY flag

Uart0Regs.UARTIOCTRLTX.bit.IO_FUNC = 1; //enable transmit pin
Uart0Regs.UARTIOCTRLRX.bit.IO_FUNC = 1; //enable receive pin

Uart0Regs.UARTCTRL3.bit.CLOCK = 1; //internal clock select;
Uart0Regs.UARTCTRL3.bit.SW_RESET = 1; //software reset released UART init done?

Uart0Regs.UARTIOCTRLSCLK.bit.IO_FUNC = 0; //disable external clock for UART.

Uart0Regs.UARTTXBUF.all = ' '; //put out a byte to get things started.
}

void char_out_0(char data)
{
volatile char rx_byte;

while(Uart0Regs.UARTTXST.bit.TX_RDY == 0)
{
if(Uart0Regs.UARTRXST.bit.RX_RDY == 1)
{
rx_byte = Uart0Regs.UARTRXBUF.bit.RXDAT; //clear RXRDY flag
}
pmbus_handler();
}
Uart0Regs.UARTTXBUF.all = data; //put out a byte
}

****************

can you please send for UART1 so that i can send my at command to wifi.

0 Shoeb ahmed over 5 years ago in reply to Shoeb ahmed

Intellectual 335 points

sir, please reply to this above post

0 Ian Bower over 5 years ago in reply to Shoeb ahmed

TI__Genius 17090 points

There should be no difference between UART 0 and UART 1. When you say it doesn't work, what do you mean? For example, what happens if you try to continuously output a byte on the transmit pin? Do you see it coming out on the scope? Is the baud rate correct? If you get that working, what happens if you put that byte into the receive side? Does that work?

0 Shoeb ahmed over 5 years ago in reply to Ian Bower

Intellectual 335 points

No, Sir, it is not happening after anything for UART1. But for UART0 working properly. We just have to send the Character serially from Uart.

0 Ian Bower over 5 years ago in reply to Shoeb ahmed

TI__Genius 17090 points

Just to make sure, I tried out UART1 on the UCD3138128, which is the same as the A64 except for memory size. It worked fine, at least as far as transmitting went. I didn't test the receive side.

Here's the initialization code:

void init_uart1(void)

{

volatile Uint32 rx_byte1; //volatile to make warning go away about set but not read

Uart1Regs.UARTCTRL3.bit.SW_RESET = 0; //software reset while initializing UART

Uart1Regs.UARTCTRL0.bit.DATA_SIZE = 7; //8 bits

Uart1Regs.UARTCTRL0.bit.STOP = 1; //2 stop bits

Uart1Regs.UARTCTRL0.bit.SYNC_MODE = 1; //asynchronous mode

Uart1Regs.UARTHBAUD.all = 0;

Uart1Regs.UARTMBAUD.all = BAUD_RATE_VALUE_M;

Uart1Regs.UARTLBAUD.all = BAUD_RATE_VALUE_L; //for 38400 //47 for control board, 44 for open loop

Uart1Regs.UARTRXST.bit.RX_ENA = 1 ;//enable RX

Uart1Regs.UARTTXST.bit.TX_ENA = 1;//enable TX

Uart1Regs.UARTINTST.all = 0xff; //these two statements are supposed to clear the status bits

Uart1Regs.UARTINTST.all = 0;

rx_byte1 = Uart1Regs.UARTRXBUF.all; //clear RXRDY flag

Uart1Regs.UARTIOCTRLTX.bit.IO_FUNC = 1; //enable transmit pin

Uart1Regs.UARTIOCTRLRX.bit.IO_FUNC = 1; //enable receive pin

Uart1Regs.UARTCTRL3.bit.CLOCK = 1; //internal clock select;

Uart1Regs.UARTCTRL3.bit.SW_RESET = 1; //software reset released UART init done?

Uart1Regs.UARTIOCTRLSCLK.bit.IO_FUNC = 0; //disable external clock for UART.

Uart1Regs.UARTTXBUF.all = '\n'; //put out a byte to get things started.

}

To test it I downloaded the LLC code from .

I shrank the main function down so that all it did was initialize the PMBus and UART1, and just put out a character:

void main()

{

init_uart1();

init_pmbus(88);

for(;;)

{

char_out(0xaa);

}

I changed char_out to switch to uart1, and to include a call to pmbus_handler:

void char_out(char data)

{

while(Uart1Regs.UARTTXST.bit.TX_RDY == 0)

{

pmbus_handler();

}

Uart1Regs.UARTTXBUF.all = data; //put out a byte

}

I also had to put a:

#include "pmbus_common.h"

at the end of the includes in uart.c to avoid the warning message.

I'd suggest you try the same thing, and see if it works for you. That way, there's no other code that can mess things up.

I have been trying to think of things that could prevent it from working, and it occurs to me that maybe the bits in the GLBIOEN register are getting set? This takes control of those bits away from the UART, and gives it to the global io logic.

If it was me, I would say I might be looking at the wrong pin entirely, but presumably no one else makes that mistake. Or there might be some hardware on the outside that is messing things up - like you have TX from one device connected to TX on the other device, and RX connected to RX.

Power management

Power management forum

CCS/UCD3138A64OEVM-662: interfacing wifi via uart