EK-TM4C1294XL: EK-TM4C1294XL

Hi Guys,

Thank you both for the reply.

I though so. It is good to know that. I am not familiar with CCS and this is my first serious application with CCS.

Do you know what the minimum rate I can achieve.

I am sorry I couldn't find way of attaching file so I  am pasting here. The bit which say 250ms is in bold.

Regards

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

//*****************************************************************************
//
// differential.c - Example demonstrating how to configure the ADC for
// differential operation.
//
// Copyright (c) 2010-2017 Texas Instruments Incorporated. All rights reserved.
// Software License Agreement
//
// Redistribution and use in source and binary forms, with or without
// modification, are permitted provided that the following conditions
// are met:
//
// Redistributions of source code must retain the above copyright
// notice, this list of conditions and the following disclaimer.
//
// Redistributions in binary form must reproduce the above copyright
// notice, this list of conditions and the following disclaimer in the
// documentation and/or other materials provided with the
// distribution.
//
// Neither the name of Texas Instruments Incorporated nor the names of
// its contributors may be used to endorse or promote products derived
// from this software without specific prior written permission.
//
// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
// "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
// LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
// A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
// OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
// SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
// LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
// DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
// THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
// (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
// OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
//
// This is part of revision 2.1.4.178 of the Tiva Firmware Development Package.
//
//*****************************************************************************

#include <stdbool.h>
#include <stdint.h>
#include "inc/hw_memmap.h"
#include "driverlib/adc.h"
#include "driverlib/gpio.h"
#include "driverlib/pin_map.h"
#include "driverlib/sysctl.h"
#include "driverlib/uart.h"
#include "utils/uartstdio.h"

//*****************************************************************************
//
//! \addtogroup adc_examples_list
//! <h1>Differential ADC (differential)</h1>
//!
//! This example shows how to setup ADC0 as a differential input and take a
//! single sample between AIN0 and AIN1. The value of the ADC is read and
//! printed to the serial port.
//!
//! This example uses the following peripherals and I/O signals. You must
//! review these and change as needed for your own board:
//! - ADC0 peripheral
//! - GPIO Port E peripheral (for ADC0 pins)
//! - AIN0 - PE3
//! - AIN1 - PE2
//!
//! The following UART signals are configured only for displaying console
//! messages for this example. These are not required for operation of the
//! ADC.
//! - UART0 peripheral
//! - GPIO Port A peripheral (for UART0 pins)
//! - UART0RX - PA0
//! - UART0TX - PA1
//!
//! This example uses the following interrupt handlers. To use this example
//! in your own application you must add these interrupt handlers to your
//! vector table.
//! - None.
//
//*****************************************************************************

//*****************************************************************************
//
// This function sets up UART0 to be used for a console to display information
// as the example is running.
//
//*****************************************************************************
void
InitConsole(void)
{
//
// Enable GPIO port A which is used for UART0 pins.
// TODO: change this to whichever GPIO port you are using.
//
SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);

//
// Configure the pin muxing for UART0 functions on port A0 and A1.
// This step is not necessary if your part does not support pin muxing.
// TODO: change this to select the port/pin you are using.
//
GPIOPinConfigure(GPIO_PA0_U0RX);
GPIOPinConfigure(GPIO_PA1_U0TX);

//
// Enable UART0 so that we can configure the clock.
//
SysCtlPeripheralEnable(SYSCTL_PERIPH_UART0);

//
// Use the internal 16MHz oscillator as the UART clock source.
//
UARTClockSourceSet(UART0_BASE, UART_CLOCK_PIOSC);

//
// Select the alternate (UART) function for these pins.
// TODO: change this to select the port/pin you are using.
//
GPIOPinTypeUART(GPIO_PORTA_BASE, GPIO_PIN_0 | GPIO_PIN_1);

//
// Initialize the UART for console I/O.
//
UARTStdioConfig(0, 115200, 16000000);
}

//*****************************************************************************
//
// Configure ADC0 for a differential input and a single sample. Once the
// sample is ready, an interrupt flag will be set. Using a polling method,
// the data will be read then displayed on the console via UART0.
//
//*****************************************************************************
int
main(void)
{
#if defined(TARGET_IS_TM4C129_RA0) || \
defined(TARGET_IS_TM4C129_RA1) || \
defined(TARGET_IS_TM4C129_RA2)
uint32_t ui32SysClock;
#endif

//
// This array is used for storing the data read from the ADC FIFO. It
// must be as large as the FIFO for the sequencer in use. This example
// uses sequence 3 which has a FIFO depth of 1. If another sequence
// was used with a deeper FIFO, then the array size must be changed.
//
uint32_t pui32ADC0Value[1];

//
// Set the clocking to run at 20 MHz (200 MHz / 10) using the PLL. When
// using the ADC, you must either use the PLL or supply a 16 MHz clock
// source.
// TODO: The SYSCTL_XTAL_ value must be changed to match the value of the
// crystal on your board.
//
#if defined(TARGET_IS_TM4C129_RA0) || \
defined(TARGET_IS_TM4C129_RA1) || \
defined(TARGET_IS_TM4C129_RA2)
ui32SysClock = SysCtlClockFreqSet((SYSCTL_XTAL_25MHZ |
SYSCTL_OSC_MAIN |
SYSCTL_USE_PLL |
SYSCTL_CFG_VCO_480), 20000000);
#else
SysCtlClockSet(SYSCTL_SYSDIV_10 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN |
SYSCTL_XTAL_16MHZ);
#endif

//
// Set up the serial console to use for displaying messages. This is just
// for this example program and is not needed for ADC operation.
//
InitConsole();

//
// Display the setup on the console.
//
UARTprintf("ADC ->\n");
UARTprintf(" Type: differential\n");
UARTprintf(" Samples: One\n");
UARTprintf(" Update Rate: 250ms\n");
UARTprintf(" Input Pin: (AIN0/PE3 - AIN1/PE2)\n\n");

//
// The ADC0 peripheral must be enabled for use.
//
SysCtlPeripheralEnable(SYSCTL_PERIPH_ADC0);

//
// For this example ADC0 is used with AIN0/1 on port E7/E6.
// The actual port and pins used may be different on your part, consult
// the data sheet for more information. GPIO port E needs to be enabled
// so these pins can be used.
// TODO: change this to whichever GPIO port you are using.
//
SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOE);

//
// Select the analog ADC function for these pins.
// Consult the data sheet to see which functions are allocated per pin.
// TODO: change this to select the port/pin you are using.
//
GPIOPinTypeADC(GPIO_PORTE_BASE, GPIO_PIN_3 | GPIO_PIN_2);

//
// Enable sample sequence 3 with a processor signal trigger. Sequence 3
// will do a single sample when the processor sends a signal to start the
// conversion. Each ADC module has 4 programmable sequences, sequence 0
// to sequence 3. This example is arbitrarily using sequence 3.
//
ADCSequenceConfigure(ADC0_BASE, 3, ADC_TRIGGER_PROCESSOR, 0);

//
// Configure step 0 on sequence 3. Sample channel 0 (ADC_CTL_CH0) in
// differential mode (ADC_CTL_D) and configure the interrupt flag
// (ADC_CTL_IE) to be set when the sample is done. Tell the ADC logic
// that this is the last conversion on sequence 3 (ADC_CTL_END). Sequence
// 3 has only one programmable step. Sequence 1 and 2 have 4 steps, and
// sequence 0 has 8 programmable steps. Since we are only doing a single
// conversion using sequence 3 we will only configure step 0. For more
// information on the ADC sequences and steps, refer to the datasheet.
//
ADCSequenceStepConfigure(ADC0_BASE, 3, 0, ADC_CTL_D | ADC_CTL_CH0 |
ADC_CTL_IE | ADC_CTL_END);

//
// Since sample sequence 3 is now configured, it must be enabled.
//
ADCSequenceEnable(ADC0_BASE, 3);

//
// Clear the interrupt status flag. This is done to make sure the
// interrupt flag is cleared before we sample.
//
ADCIntClear(ADC0_BASE, 3);

//
// Sample AIN0/1 forever. Display the value on the console.
//
while(1)
{
//
// Trigger the ADC conversion.
//
ADCProcessorTrigger(ADC0_BASE, 3);

//
// Wait for conversion to be completed.
//
while(!ADCIntStatus(ADC0_BASE, 3, false))
{
}

//
// Clear the ADC interrupt flag.
//
ADCIntClear(ADC0_BASE, 3);

//
// Read ADC Value.
//
ADCSequenceDataGet(ADC0_BASE, 3, pui32ADC0Value);

//
// Display the [AIN0(PE3) - AIN1(PE2] digital value on the console.
//
UARTprintf("AIN0 - AIN1 = %4d\r", pui32ADC0Value[0]);

//
// This function provides a means of generating a constant length
// delay. The function delay (in cycles) = 3 * parameter. Delay
// 250ms arbitrarily.
//
#if defined(TARGET_IS_TM4C129_RA0) || \
defined(TARGET_IS_TM4C129_RA1) || \
defined(TARGET_IS_TM4C129_RA2)
SysCtlDelay(ui32SysClock / 12);
#else
SysCtlDelay(SysCtlClockGet() / 12);
#endif
}
}

rab boud said:

UARTprintf(" Update Rate: 250ms\n");

The code you show - to me - if it is to yield a, '250mS Update Rate'  ... relies most heavily upon the 'Delay enforced by the UART - which outputs 16+ characters - on  each/every conversion!     That much data - sent via a 'relatively slow serial port' - surely 'Throttles Down' your ADC's Conversion Rate!      If you employ the  '"AIN0 - AIN1 '  only once (atop the terminal screen) - your update rate surely will rise.

rab boud said:

// Display the [AIN0(PE3) - AIN1(PE2] digital value on the console.
//
UARTprintf("AIN0 - AIN1 = %4d\r", pui32ADC0Value[0]);

There IS an (additional/programmable) delay - (buried) at the program's bottom - yet that's 'µS' (or less) in duration - thus inconsequential.     The HELL it is - firm/I (always) 'hard code' that value - that 12 is 'ALL I saw!'     In our defense - executing the 'SysCtlClockGet' IS wasteful ... AND may be 'over-looked!'    (and that's - just been proven - right here!)     The delay imposed is 1/12 Second (83mS).    And that DOMINATES thus nearly entirely explains - the 'Slowed ADC Conversion!'

At 9600 baud  - vendor's Ralph & I have noted that each UART bit has a ~104µS bit duration.     Your program's 115Kb - reduces that by the factor  '9.6/115 (0.083)' yielding a serial bit time of, '8.63µS.'    With 8 data bits - plus 2 (Start/Stop) - a minimum UART Transaction requires 86.3µS per UART character.    

Multiplying that '86.3 by the 16 char (example code's UART minimum message size) yields: 1.38mS.    Rounding that up to 1.5mS - the MAX ADC Conversion Rate (via program's UART coding) is: '~666 ADC Conversions/Second.'     Thus the UART has inflicted a 'Serious Delay' ... upon the ADC's Conversion Rate.

We must ADD that final  83mS delay - introduced as the end of the program.     And INDEED  - the VERY MAJOR - ADC Conversion RATE Throttling - is imposed by that (programmable) delay!    My newest (after 'sanity' (somewhat) returned ... calculation reveals just under 12 ADC Conversions/second - and that 'REDUCED NUMBER' - ALMOST ENTIRELY - IMPOSED BY THAT  FINAL 1/12th Second Delay!

Hi Ralph,

Re: poster's code ... 'Straight out of single_ended.c'

I don't doubt you - but for the clear mention of,  'ADC_CTL_D' - unlikely to have appeared w/in 'single_ended.c!

'ADCSequenceStepConfigure(ADC0_BASE, 3, 0, ADC_CTL_D | ADC_CTL_CH0 | ADC_CTL_IE | ADC_CTL_END);

One wonders why the effort was made to add a delay of  (just) 12?    ***   Temporary Insanity here!    That's  (really) 83mS of imposed delay.

Hi Ralph,

Re: my (potential 'great summary' - I completely BLEW THAT!)    Indeed the UART (any MCU vendor's UART) EATS execution TIME!     But NOWHERE NEAR to the value imposed by the program's 'DELAY' - which I 'MISREAD' as 12!      (we always 'hard code' - and I've proven - once more - that I am NO Multi-Tasker.    'Multi-Compromiser' - proves more MY skill level/pay grade reality!

The UART (just about any serial port) does impose a time delay - but in this program's implementation - the final DELAY is the BIG DEAL - and it IS the overwhelming source of the ADC's being SO THROTTLED!

Somehow I sense that 'filet mignon & Pouilly Fuisse'  (may)  NOT make - tonight's menu...

You was right. I meant max; I was trying to amend it when I was going home on the train but I couldn't get a good reception while the train was moving.

I am going to buy the development board and get familiar with it.

For the Code Composer Studio; is it 100% free or there is a limit on the size of the hex file or the size of the application?

Should 'highest ADC capture rates be the goal' - any/all (other) processes must be held until a 'suitable number' of ADC measurements have been achieved.     You thus must 'decouple' your 'extra operations' - (meaning: Prevent them from 'intruding upon' - thus delaying - the ADC's 'unfettered operation.')

Any serial communication mode (SPI, I2C, CAN, UART, USB) will introduce (often unwanted) delays - if allowed to 'infiltrate' - the ADC's central conversion process.    (thus UART alone - is not the 'sole' culprit...)

The combination of this vendor's ADC - and their µDMA - usually provides the fastest (and most elegant) 'Capture & Store of ADC data!'    (Yet will 'try your soul' - in mastering its implementation...)

As stated earlier - by (both) Vendor's Ralph - and myself - this MCU is able to perform (very) high rates of ADC Conversions.    You've used the term, 'signal Frequency at/around 200Hz' several times.     Do note that the 'input signal's frequency' - is separate from - the MCU's ADC Conversion Rate.

When the ADC Conversion is:

• timer triggered
• and serviced via the ADC's interrupt handler (meaning that the ADC's Data is placed into 'fast storage'    (i.e. SRAM - on-chip) 

then that process is greatly 'MCU Freeing' - and (almost) automatic.    (the addition of the MCU's  'µDMA'  - and its efficient coordination w/the  ADC - does 'much'  to speed & automate this data 'fetch & store!' 

Your DSP query - not (too)  focused - appears 'premature' - and 'could' yield - many pages of response.    ARM Cortex M4 - which enjoys, 'certain aspects of DSP' - appears for now - your (far) superior choice...

Thank you Ralph for the ralph!

rab boud said:

Thank you Ralph for the ralph!

What ... no thanks to cb1 - for the cb1?      (blinks away  tear)  

rab boud said:

My voltage range will be 320V (peak to peak) or + - 160V DC.

Your very first posting (this thread) noted your intention to  measure, 'Differential Signals' - did it not?        Thus - is it likely - that your (newly) introduced 320V (p-p) - is indeed, 'differential?'     (there are circuit methods which enable the conversion of 'single-ended' to 'differential' - yet  'very few'  (to my knowledge) will accept so high a voltage.     You must first attenuate that  high-voltage - to a level (which includes a safety guard-band) acceptable to (all) of your 's.e. to diff.' conversion circuitry components.)

Your MCU's ADC may effectively measure AC signals - with the proviso that  'at all times' - the signal is constrained w/in the MCU's '0V - Vdd'  voltage range.      (should you have elected a 'different voltage' - for application to the MCU's VDDA (reference) pin - then the input signal should not exceed that VDDA level.     (I believe that 'no harm' will occur should VDDA be 'exceeded' - provided that  VDD 'escapes' such excess.) 

Vendor has a rather excellent/informing 'treatment of 'Optimizing MCU-based, ADC results.'      I'd link to it - if it was (reasonably) 'findable' - it is NOT!      You should note that the ALWAYS SOUGHT - uber CRITICAL 'Forums, Blogs, Groups, Training'   are  instantly & easily located  (as they reside upon 'prime, beach-front property'  (i.e. Forum's UNAVOIDABLE - Red-Saturated Bar - placed (SO notably) atop the forum page!)    (clearly for 'Ease of Finding!')    (known as  'Style Guide'  by vendor insiders) 

Should you 'attempt to locate' the well suppressed  'ADC treatment guide' ... do step carefully over/around the (many) 'lifeless bodies!'    (earlier arriving -  VITAL MCU DATA  'seekers/explorers!')  

Hello Ralph,

I'm unsure - would not a 'reasonably COMPLETE LISTING' - of any/all such 'MCU related guides'  - enable a superior determination?      

You've had 'no part' in such, 'Key Data Suppression' - yet is not the link you've (just) supplied ... SO VERY FLEETING?      And will quickly, 'Slide-OFF into Forum oblivion' as newer posts arrive/advance?

And - btw - you KNEW where to go to 'Find that link' - yet clearly that info (appears) to have been hoarded - and not made 'quickly and/or easily' - available to the MASSES!     Are not 'THEY' - the ones who have the greatest need?

I've been here beyond 10 years - am (sometimes) of 'reasonably sound mind' - and (far too often) 'Must resort to 'Google' - to  (only sometimes find)  Vital MCU Related Tech Docs!'     Dare you address that?   (pardon - but you have NOT!)    That's the REAL ISSUE - is it not?

What do you suggest that forum users do - when 'Ralph (or vendor others) do not arrive for their rescue?    (i.e. weekends - especially weekends...)

Yes, I understand that. For +-160V (V peak) or 320v Vpp, it will be attenuated by a factor of 100 which will give a maximum voltage of 3.2V at the input of the ADC. I will add a DC voltage of (Vdd/2) at the input of the ADC. This will allow the input to swing between -160V and +160V.
If the ADC reference voltage is set to 3.56V, the ADC resolution will be 1.73mV ( at ADC level) or 173mV at the voltage logger input which is very good.

To calculate the RMS, I need to acquire at least twice the period of the signal. As an example I need to acquire 1024 samples from each ADC channel and calculate the RMS value. This mean 4096 samples for 4 channels each time the RMS values are logged to a file. The time between two consecutive logged RMS values has to be very small ( I am wondering what is the smallest value I can achieve) as these logged data will be used to investigate system failure. It is like a playback to see what happened where there will be a failure where the logger was connected.

I am glad to finally have the development board. I am installing the related software such as CSS studio. I am excited to start playing with it. 

If successful, I will use it as it is with a custom addon ( signal conditioning...). Is it EMC tested as my final product  has to pass EMC tests?

If I decide to build my logger from scratch by incorporating EK-M4C1294XL schematic in my design in one board; how I can program the MCU using JTAG?

This bit here about the future; what is the Texas Instrument future plans for the digital section such as microcontroller in general and this product in particular.  Is Texas Instrument will be dropping the digital part all together? I hope not as TI have a marvellous products with highly skilled support engineers which helped lot in the past.

Setting the ADC's Ref. voltage IN EXCESS of VDD' - is 'Safe & Proper

Of course not. According to the datasheet the 2.97v< Vref < 3.63V with a nominal value of 3.3V. I also bear in mind that ADC reference voltage has to be smaller than the MCU Vdd.


'this Resolved'

Even the picture is lot more clearer when I started this thread, there is few un-answered question such as EMC. If the board as it is will fail the EMC test, the board will be useless unless I think schematics will be used in building a new PCB where  EMC is kept in mind. At the end of the day my voltage logger has to pass the EMC test.

I just saw a document of conformity on TI website which mentioned EN61326-1:2013 which seems the answer to this question. I don't know the details of this standard such as  radiated emission  and so on.

One wishes - such "high detail" was announced previously.     Pay is 'scant' for we (few) outsiders - thus our Google Ratings (and captive clients here) drive our time & effort.

There IS a 'method of compromise' - which meets (both) YOUR - and my/my firm's needs.       Your post's subject - btw - is less than 'well chosen' - a "headline" IS important - and 'draws eyes.'    (and the repetition of MCU's part number - proves less than inspiring.)

You are FREE to award "This Resolved" - to both Ralph - and to me - and to then ...  Launch a whole NEW POST - this time w/your EMC Issues - clearly placed w/in the Subject Line!    Such is SURE to FAR BETTER - capture the attention of the (likely) EMC Mavens - who 'prowl this landscape.'

A 'reasonable' Problem Solver - presents alternative ways/means to accomplish objectives.     That has been done (for you) here - has it not?   There is "little" (i.e. NO chance) that any EMC Maven - will descend this far into this thread - and (only then) discover your "unannounced" EMC desires...    

Fresh - New posting - properly (and illustratively) Subject NOTING (EMC) - is by far - a most valid (even RESOLVING) suggestion!