TM4C1294NCPDT: UART speed and baud rates

Use of the RTCOSC (Real Time Clock) oscillator - usually operating around 32KHz - is not famed for use w/the UART. How did you come by that decision?

Would it not make sense to employ one of the simple, vendor provided code examples - found w/in the API? Even if not precisely to your objectives - such will prove a "start" - and enable you to confirm the UART settings w/in your PC.

Rarely do users describe their specific choice of UART (MCU has many) yet "only one" is USB compatible (UART_0) via vendor's ICDI - assuming you're using a factory provided board which includes that 2nd MCU.

Just to save energy. I'm trying to implement a command line on tiva EK-TM4C1294XL with the minimum clocks I can get. For now, I don't want anything specific, just get the clocks to work. And to know why UART doesn't seem to work on some clock speeds or baud rates.

UPDATE: Also I discovered that UART only works with PLL enabled, or with PIOSC as alternate source. With PLL I achieved a minimum of 5 MHz, but unfortunately using PLL the clock will not go down any further...

PS: I doubt that you will save energy running a CPU slower... There are a few systems that are continuously ON while the CPU is running, and other than that, power consumption on processing is dictated by the electric level shifts on each internal "magic thing" that holds the bits.
In other words, a CPU running at 60MHz does not consume just half the current of a similar one at 120MHz - but will take twice the time to process the same instructions, so your final energy spent is actually higher.

Hello Helder

Helder Sales said:

With PLL I achieved a minimum of 5 MHz

I would disagree with that statement. The UART on the TM4C129x examples are working at 115.2Kbps with 120MHz as the system clock.

So how is the UART being configured for 9600bps which makes it not possible to work with the PLL.

Also to use the RTCOSC or the LFIOSC as the clock for UART did you configure the ALTCLKCFG register? However a word of caution here is that when using the ALTCLKCFG to change the clock other peripherals using the alternate clock shall also be affected.

LFIOSC is not a good choice as it has a wide spec of variation, that can have a significant impact on the baud rate.

Amit Ashara said:

Also to use the RTCOSC or the LFIOSC as the clock for UART did you configure the ALTCLKCFG register? However a word of caution here is that when using the ALTCLKCFG to change the clock other peripherals using the alternate clock shall also be affected.

Hi,

Yes, I did configure the ALTCLKCFG register by using SysCtlAltClkConfig(), and saw the impact on the Timer module I was using. Is there a way to calculate the best baud rate for the UART? I suspect that the problem is with the baud rate, I'm not sure how to determine which baud rate is better for a given clock speed.

Helder Sales said:

Is there a way to calculate the best baud rate for the UART? I

Helder,

Again: don't take that route... You don't "choose" a baud rate, you configure your system to communicate to an existing device which already works at a certain rate. If YOU are in charge of determining the speed of the devices on both ends, then I guess you should choose the fastest possible "standard" rate that your hardware can deal with (and such includes transceiver speeds, cable lengths, and other details). Rule of thumb: you are usually safe to communicate to PC's at 115200 (most adapters and uart drivers go up to that), and if you are communicating between two boards of your own, will likely to go well up to 921600.

All these is simply achieved by one configuration line using TivaWare API. There's no need for crazy calculations and weird clock settings that impact everything else in your system!

UARTConfigSetExpClk(SERIAL_BASE, SYSTEM_CLOCK, 115200, (UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE |UART_CONFIG_PAR_NONE));

Still, if you insist in using slower clocks, there will be a lesser range of reliable speeds (a waste of time explaining it here, but refer to slower MSP430 clock and baud rate settings if you want to understand the impact of the dividing parameters). And as Amit said, LFIOSC is so fluctuating that it will be impossible to perform any asynchronous communication based on it.

Regards,

Bruno

Hi Bruno,

I understand now. Not sure if wise, I was able to use 921600 to comunicate to PC without problems.

Truth is, my only experience is with Arduino, which is completely different on many things. Now I'm having to deal with Tiva, and the first thing I saw is the difficulty to learn everything. I don't know where to look, even when I know is somewhat hard to understand...the only guide that helped me was the Workbook, but only for the basics.

For now I can do basic stuff like play with the ADCs, PWMs, Timers, UART...fortunately I found a example from a brazillian guy on how to make a command line program, using UARTstdio.

And I learned here that even when stated in the datasheet (or other sources) that exists an option for something, that option is not necessarily wise to employ (like clocking the UART with RTCOSC or the LFIOSC).

Also, using UARTConfigSetExpClk() leads to a system fault. However, using UARTStdioConfig() the code runs fine. Could be the UART stdio interrupt handler?

Hello Helder

There is no real co-relation that can be made between system clock and baud rate. What can be ascertained in the highest and lowest baud rate for system clock. Then the ascertain what baud rate the application requires. Once that is determined the clock rate for the application can be decided; and of course what other system activity that the CPU needs to perform also requires to be factored in. With a 16 bit integer divider for the system clock of 120MHz the lowest that is possible is ~114 bps and highest being 1/8th which leads to a value of 15 Mbps. However at higher baud rates the system clock itself must be very stable (MOSC+PLL) to avoid bit errors.

Helder,

No problem communicating at 921600 with your PC. It might only be a problem if the cable gets too long, of if you later use a lesser quality PC UART adapter, but in theory this speed is fine. Is 115200 fast enough for your application? Then you may want to lower your throttle to that level...

I share your pain regarding the learning curve for Tivas. It took a while until I was properly directed to probably the most important document for Tiva development: the 4.6Gb SW-TM4C-DRL-UG inside the docs folder of your Tivaware installation. Once you get used to the document structure there, you will quickly implement "anything" that Tiva can do. And, be honest, TI's goal is to let you do "anything" the TM4C's can do by just using Tivaware... So life becomes quite easier.

(And yet, I did have some formal MSP430 training way back, by TI approved partners, so what can be said of those trying to fully learn alone?)

Then it took me some further time to realize there are ready to use additional utilities. Example? exactly one API for a command line implementation, documented in the UTILS file of the same folder. Such command line is used, as a reference (if I recall properly), on the simple RGB led controller of the TM4C123 launchpad board.

Anyway: Tiva/ARM is not AT ALL any more difficult than uinos. I just think TI hasn't still created a clear learning path - often sinning by excess of documents, instead of lack.

As for UARTConfigSetExpClk() causing a fault, it should not - you are missing something on your code, maybe calling it before enabling the uart peripheral, or something simple like that - double check it. The UARTStdioConfig() is an "auxiliar function", not really part of the Tivaware driverlib, and probably does what you forgot to do by using the former function... just take a look at the source code or the documentation. I don't use anything Stdio for uart related, for our projects "need to be in control" of all the bytes we send and receive on those ports...

Take triple care with those Brazilian guys... some of them are more confusing than others... and myself being one and having been part of the "TM4C society" in that country for almost 10 years, know most of those... :)

Cheers!

Bruno

Hi Bruno,

I'm also brazilian! I began to learn Tiva because of my college's extension project, UFPR Baja SAE. I study electrical engineering at UFPR. And I've learn to take care with the brazilian guys already haha.

As for the UARTConfigSetExpClk(), I tried some different ways to initialize the UART with no sucess. Given the fact that it works with UARTStdioConfig(), I'm not sure if worth trying to make it run the "normal" way, at least in the current program.

It was an adaptation of this one: solysion.com.br/.../
Went through hell to make it work with CCS and learned to use Eclipse, maybe I will switch Code::Blocks with Eclipse for C++ learning. 

Also thanks Amit, for enlightening me about UART speeds.

Best regards,
Helder

Helder Sales said:

I'm also brazilian

I kind of knew...

Helder Sales said:

I tried some different ways to initialize the UART with no sucess

Not sure what got you confused, but it doesn't get too much easier than this... Here's a "free snippet of code":

	// Congigurações da Porta Serial UART0
	MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);  // Pinos UART0 TX e RX
	MAP_GPIOPinConfigure(GPIO_PA0_U0RX);
	MAP_GPIOPinConfigure(GPIO_PA1_U0TX);
	MAP_GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1);
	UARTInt_InitUART(0,systemClock.mainClock,115200);

Go enjoy an excellent pint at Masmorra Cervejaria, at Alto da XV, and good luck with your studies.

Helder Sales said:

..., maybe I will switch Code::Blocks with Eclipse for C++ learning.

Just as a comment, Code::Blocks has nothing to do with Eclipse, nor uses Eclipse. It is build with and around "wxwidgets", another platform-independent GUI toolkit. View it as a "competitor" to QT.

I use CodeBlocks (and the GCC compiler coming with the default installation) for PC-based projects, and to verify certain MCU routines/algorithms on PC first. Plus, it is available on M$-Windows and Linux (I'm using the latter).

Hello Bruno

UARTInt_InitUART is not TivaWare API....

Amit Ashara said:

UARTInt_InitUART is not TivaWare API....

Oooops... it should!

Sorry, I've been so used to my own shortcut lib that I took it for granted.

FWIW, here's the relevant part inside that call:

	MAP_SysCtlPeripheralDisable(UART0_BASE);
	MAP_SysCtlPeripheralReset(UART0_BASE);
	MAP_SysCtlPeripheralEnable(UART0_BASE);
	while(!SysCtlPeripheralReady(UART0_BASE));

	MAP_UARTConfigSetExpClk(UART0_BASE, sysclock, baudrate,(UART_CONFIG_WLEN_8 | UART_CONFIG_STOP_ONE |UART_CONFIG_PAR_NONE));

	MAP_UARTFIFOLevelSet(UART0_BASE, UART_FIFO_TX6_8, UART_FIFO_RX2_8);			// Configure FIFO levels*
	MAP_UARTIntEnable(UART0_BASE, UART_INT_TX | UART_INT_RT | UART_INT_RX);		// Enables TX and RX interrupts

Uart base hard coded as 0 for ease of comprehension...