24 BIT ADC INTERFACE WITH SSI OF TM4C123GH6PZ

Hello Rashmi,

You can use two methods

1. Use the Mode as 1 or 3 and fill it up for the transaction to get a continuous burst with 8-bit or 16-bit mode.

2. Instead of FSS being controlled by the SSI, convert it to a GPIO and make it low before you begin SSI read operation. Even in this case you can keep data length as 16 bits and do 2 reads to get the data. After doing the read make the GPIO high.

Please note that when reading data from an external device you need to do

SSIDataPut

SSIDataGet

as a pair. Option-2 has examples in the E2E forum.

Regards

Amit

k thank you for your reply..one thing i need to ask.mode 1 or 3 means what??your talking about clock polarity n phase???

Hello Rashmi

Yes, I am talking about Polarity and Sampling Phase

Regards

Amit

Thank you...i'l  try do like this..

Hello Rashmi,

Please do make sure that LTC supports this mode. If not the option-2 is the way to go

Regards,

Amit

Hi thanks for your reply..LTC supports the mode 0.so i will go for option 2..

hardware connection between LTC  and controller i have done like this bec i need  to make sure whether  the hardware connection is proper or not

LTC2440  -------------------------------->CONTROLLER

BUSY ----------------------------------------PF5(GPIO-PIN-5)

SCLK--------------------------------------PK0(SSI3CLK)

SD0------------------------------------------PK2(SSI3RX)

CS------------------------------------------PK1(SSI3CS)

MY doubt ,now i'm using  gpio for FSS, Instead of FSS being controlled by the SSI..can i use same pk1 in  for fss to make low n high my example.???

Hello Rashmi,

Yes you can us PK1 as FSS in GPIO Output Mode.

Regards

Amit

hi..i'm checking all signal in oscilloscope.i'm getting all signal properly but when i have checked in watch window i'm not getting any value...please once can you check my code..pls

#include <string.h>
#include "inc/lm4f232h5qc.h"

#include "inc/hw_memmap.h"
#include "driverlib/pin_map.h"
#include "inc/hw_types.h"
#include "driverlib/gpio.h"
#include "driverlib/sysctl.h"
#include "driverlib/systick.h"
#include "utils/softssi.h"
#include "utils/uartstdio.h"
#include "driverlib/rom.h"
#include "driverlib/ssi.h"
#include "inc/hw_gpio.h"
#define GPIO_PK0_SSI3CLK 0x00090002

#define GPIO_PK1_SSI3FSS 0x00090402

#define GPIO_PK2_SSI3RX 0x00090802

#define GPIO_PK3_SSI3TX 0x00090C02

long int clk;
void Setup_SSI();

#define NUM_SSI_DATA 2

unsigned long ulDataTx[NUM_SSI_DATA]; // An array of 4 data bytes to be Tx
unsigned long ulDataRx[NUM_SSI_DATA]; // An array of 4 data bytes to be Rx
unsigned long ulindex;
int main()
{

Setup_SSI();


while(1)
{

ulDataTx[0] = 0xa1;
SSIDataPut(SSI3_BASE, ulDataTx[0]);

while(GPIOPinRead(GPIO_PORTF_BASE,GPIO_PIN_5));
GPIOPinWrite(GPIO_PORTK_BASE, GPIO_PIN_1, 0x00);

for(ulindex = 0; ulindex < NUM_SSI_DATA; ulindex++)
{
// Receive the data using the "blocking" get function.
SSIDataGet(SSI3_BASE, &ulDataRx[ulindex]);

while(SSIBusy(SSI3_BASE)){}
}
GPIOPinWrite(GPIO_PORTK_BASE, GPIO_PIN_1, 0x02);

}

}

void Setup_SSI()
{
// Configures the system clock, the LM3S6965 has a 8MHz crystal onboard
SysCtlClockSet(SYSCTL_SYSDIV_1 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN |
SYSCTL_XTAL_8MHZ);
SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF);


GPIOPinTypeGPIOInput(GPIO_PORTF_BASE,GPIO_PIN_5);
// Enable the SSI0 peripheral
SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI3);

// The SSI0 peripheral is on Port A and pins 2,3,4 and 5.
// Enable GPIO port A
SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOK);

// This function/s configures the pin muxing on port A pins 2,3,4 and 5
// It uses the values DEFINED at the top of the program and takes 1 parameter
GPIOPinConfigure(GPIO_PK0_SSI3CLK);
GPIOPinConfigure(GPIO_PK1_SSI3FSS);
GPIOPinConfigure(GPIO_PK2_SSI3RX);
GPIOPinConfigure(GPIO_PK3_SSI3TX);

// Configures the pins for use by the SSI, takes 2 parameters
GPIOPinTypeSSI(GPIO_PORTK_BASE, GPIO_PIN_0|GPIO_PIN_2 |GPIO_PIN_3);
GPIOPinTypeGPIOOutput(GPIO_PORTK_BASE, GPIO_PIN_1);



// Configures the SSI port for SPI master mode, it takes 6 parameters
SSIConfigSetExpClk(SSI3_BASE, SysCtlClockGet(), SSI_FRF_MOTO_MODE_0,
SSI_MODE_MASTER, SysCtlClockGet()/8, 16);



// Enables the SSI0 module
//GPIOPinWrite(GPIO_PORTK_BASE, GPIO_PIN_1, 0x02);

SSIEnable(SSI3_BASE);
}

Hello Rashmi

When using the SSI, to receive a unit of data you need to push in a unit of data. So for one SSIDataGet you would need on SSIDataPut

The for loop should be more like

SSIDataPut(SSI3_BASE,ulDataTx[ulIndex]);

while(SSIBusy(SSI3_BASE));

SSIDataGet(SSI3_BASE,ulDataRx[ulIndex])

Regards

Amit

k...can we use nop() instruction for creating delay in tm4c123???i suppose to create 1micro second delay..i'm using 8 mhz crystal frequency and also as system clock..

Hello Rashmi

Yes, you can use nop to create a delay. But how many nop's would you put for 1us, 1ms or 100ms. You may want to use a for loop. If that is the case then SysCtlDelay is equally effective.

On the other hand if you need accurate delays which are not affected by processor going for an interrupt and then coming back, disturbing the delay count, then a timer/wdt can be used.

Regards

Amit

k...actually i suppose create  1usec  then how many nop() should be used in for loop???is their any header files to be added to use nop instruction??

Hello Rashmi,

You can use SysCtlDelay(ui32LoopCount); to introduce a delay.

The ui32LoopCount is the software counter that the CPU will count at System Clock. Each ui32LoopCount will introduce 3 System Clocks of delay. As an example for the 1us delay at 80MHz System Clock

ui32LoopCount = (80MHz * 1 us)/3 = 26.67 = 27

This will give a delay of 1.0125us

Regards

Amit

Thank you so much..

Hi...i suppose create 1nsec..i'm calculating for 1nsec...

ui32LoopCount = (80MHz * 1 ns)/3 = 0.0266

so how can i fix ui32LoopCount???

Hello Rashmi

That is not possible. Please note that the System Clock which in the example is 80MHz (that is the maximu for TM4C123) is 12.5ns. How can you count 1 ns with a 12.5ns clock?

Regards

Amit

k..but LTC needs the delay between (0 to 25 nsec)  when i'l pull down the cs to low..

Eighteen exchanges deep - 24 bit ADC and (likely) misunderstanding of signal rise/fall time vs. set-up/hold.

This is unlikely to end well. 

Is a 24 bit ADC likely to be properly cared for/layed out correctly - by one obviously very new to this task?  How did 24 bits get specified?  This is a "big-league" ADC - not for the faint of heart - certainly not for a novice.

Might the MCU's internal 12bit ADC serve?  Are 24 bits really needed?  (really?)  We note that zero justification for so demanding an ADC has been presented...  Both the interface design/management and the ADC's placement - avoidance of any possible (confounding) noise source - and both power distribution/filtering and disciplined signal routing all "lie in wating" - ready to attack/devour the reliability/consistency of those lower order 24 bits...

Hand holding on this one will fill many pages - and I'd wager neat/tall stack of chips that few of those low order 24bits will arrive safely/correctly...

Sometimes it may be appropriate to (somewhat) match skill level/experience to the "real needs" of the application...

Hello Rashmi

The time specified for the CS to go low to SCK rising edge is minimum of 25ns. Anything more than that is OK. So the delay loop can be few 100's of ns and it will not be a problem.

Also you may want to take cb1's post into account. We do not know what application you are targeting for and why a 24-bit ADC is required. I have myself used a 16-bit external ADC over I2C (reasons of specialized computation) and it took time to build a SW stack to handle the same.

Regards

Amit

@ Amit,

Thanks for your vote of confidence - we outsiders escape (some) of the "PC" (likely) enforced upon your group.  And - when "provoked beyond all reason" sometimes - someone - must "rise up" - state the obvious.

We note that most of these posts have moved far from your Tiva MCU.  That may or may not be by poster's design - and while it raises forum scores - the time/effort dilutes your MCU focus - I think that fact should rise in your consideration.

The "back-forth" - revealed thus far - suggests that many "basics" have escaped their full/proper, analysis/consideration - the cart thus finds itself very much afront the horse...  Again - this ain't ending well...

cb1_mobile said:

The "back-forth" - revealed thus far - suggests that many "basics" have escaped their full/proper, analysis/consideration - the cart thus finds itself very much afront the horse...  Again - this ain't ending well...

 The knife to cut one hair in 4 part is at your hand ;) I am in rest and I just got an eye at what is the ltc part

http://www.linear.com/product/LTC2440

 NOt really fast but a very low noise.. so I just agree both too many details are missing from poster to understand what adc is and why use so is probably missing knowledge to deal a so low noise floor...

 @Amit please talk your colleague to do some filter on entering people to forums otherwise we raise level of noise and signals get worst ...

 We are experiencing practical Shannon theory of how to get a channel unusable by entropy, post everything true then false, repeat with a non predictive pattern, none can  select the right answer!

@ Roberto,

Suspect Nyquist-Shannon theorem requires some slight extension (i.e. likelihood of iceberg in No. Atlantic being "masked" by high noise floor.)  As you/I sense - some "moderation" of forum posts should enforce (some) reality...

cb1_mobile said:

@ Roberto,

Suspect Nyquist-Shannon theorem requires some slight extension (i.e. likelihood of iceberg in No. Atlantic being "masked" by high noise floor.)  As you/I sense - some "moderation" of forum posts should enforce (some) reality...

 It is a pleasure to do some out of topic conversation between us to try get alive, I am not sure how much is out compared to pseudo on topic so:

 Iceberg area are too dangerous, is not better move themselves away from than try move or split (also terrifying) iceberg to more enemy? All around nature tech us energy saving and optimal make.. This other than human society current mad market model! Waste of EVERY resource is current horsepower.

HI....i didn't switched on the LTC device..still also i'm recieving  full scale value..can you please check it out below of my code  if i have done any mistake in ssi communiation???

#include <string.h>
#include "inc/lm4f232h5qc.h"

#include "inc/hw_memmap.h"
#include "driverlib/pin_map.h"
#include "inc/hw_types.h"
#include "driverlib/gpio.h"
#include "driverlib/sysctl.h"
#include "driverlib/systick.h"
#include "utils/softssi.h"
#include "utils/uartstdio.h"
#include "driverlib/rom.h"
#include "driverlib/ssi.h"
#include "inc/hw_gpio.h"
#define GPIO_PK0_SSI3CLK 0x00090002

#define GPIO_PK1_SSI3FSS 0x00090402

#define GPIO_PK2_SSI3RX 0x00090802

#define GPIO_PK3_SSI3TX 0x00090C02

long int clk;
void Setup_SSI();

#define NUM_SSI_DATA 2

unsigned long ulDataTx[NUM_SSI_DATA]; // An array of 4 data bytes to be Tx
unsigned long ulDataRx[NUM_SSI_DATA]; // An array of 4 data bytes to be Rx
unsigned long ulindex;

unsigned int Raw_Value1 ;
unsigned int Raw_Value2;
unsigned long temp,temp1,volts;
float ADC_Conv = 0.2980232594;//in microvolt

int main()
{

Setup_SSI();


while(1)
{
ulDataTx[0] = 0x11;
ulDataTx[1] = 0x12;




while(GPIOPinRead(GPIO_PORTF_BASE,GPIO_PIN_5) == 1);


GPIOPinWrite(GPIO_PORTK_BASE, GPIO_PIN_1, 0x00);


for(ulindex = 0; ulindex < NUM_SSI_DATA; ulindex++)
{
SSIDataPut(SSI3_BASE, ulDataTx[ulindex]);
while(SSIBusy(SSI3_BASE)){}
// Receive the data using the "blocking" get function.
SSIDataGet(SSI3_BASE, &ulDataRx[ulindex]);

//while(SSIBusy(SSI3_BASE)){}
}
GPIOPinWrite(GPIO_PORTK_BASE, GPIO_PIN_1, 0x02);


Raw_Value1 = ulDataRx[0];
Raw_Value2 = ulDataRx[1];
temp = Raw_Value1 << 16;

temp1 = temp | ulDataRx[1] ;
temp1 &= 0x1FFFFFFF; // force high three bits to zero
temp1 = temp1>>5; // truncate lowest 5 bits
volts = temp1 * ADC_Conv; // microvolts
}

}

void Setup_SSI()
{
// Configures the system clock, the LM3S6965 has a 8MHz crystal onboard
SysCtlClockSet(SYSCTL_SYSDIV_1 | SYSCTL_USE_PLL | SYSCTL_OSC_MAIN |
SYSCTL_XTAL_8MHZ);
SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF);


GPIOPinTypeGPIOInput(GPIO_PORTF_BASE,GPIO_PIN_5);
// Enable the SSI0 peripheral
SysCtlPeripheralEnable(SYSCTL_PERIPH_SSI3);

// The SSI0 peripheral is on Port A and pins 2,3,4 and 5.
// Enable GPIO port A
SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOK);

// This function/s configures the pin muxing on port A pins 2,3,4 and 5
// It uses the values DEFINED at the top of the program and takes 1 parameter
GPIOPinConfigure(GPIO_PK0_SSI3CLK);
GPIOPinConfigure(GPIO_PK1_SSI3FSS);
GPIOPinConfigure(GPIO_PK2_SSI3RX);
GPIOPinConfigure(GPIO_PK3_SSI3TX);

// Configures the pins for use by the SSI, takes 2 parameters
GPIOPinTypeSSI(GPIO_PORTK_BASE, GPIO_PIN_0|GPIO_PIN_2 |GPIO_PIN_3);
GPIOPinTypeGPIOOutput(GPIO_PORTK_BASE, GPIO_PIN_1);



// Configures the SSI port for SPI master mode, it takes 6 parameters
SSIConfigSetExpClk(SSI3_BASE, SysCtlClockGet(), SSI_FRF_MOTO_MODE_0,
SSI_MODE_MASTER, SysCtlClockGet()/8, 16);



// Enables the SSI0 module
//GPIOPinWrite(GPIO_PORTK_BASE, GPIO_PIN_1, 0x02);

SSIEnable(SSI3_BASE);
}

i'm getting ulDataRx[0] = 0x0000ffff;
 ulDataRx[1] = 0x0000ffff;

Thanks in advance

@ Amit,

Someone here encouraged this!  (even in the face of "helpful/interested" others - providing cover...)

Poster, "i didn't switched on the LTC device!"   Appears we are now attempting to transact w/a device which has not received the benefit of power!  Oy my head, that device, that MCU - the (likely) continued misuse of resources...

No surprise - the repeated (first moi - then you) request for, "Why a 24 bit ADC" remains avoided/unanswered - most surely unjustified.

cb1 cocks, blows upon, silently raises pistol to head...   (perhaps not the best way, "to run a railroad"...)

Hello cb1

That would be me :-(.

Hello Rashmi,

As pointed put by others, the forum is meant to support TIVA Issues and not the lack of external devices not being connected or not powered and then the TIVA processor giving a junk data. Also, when interfacing external devices, a read of data sheets is considered a must.

With LTC not connected, I would consider a read of 0xFFFF not surprising. I would strongly urge to make your application clear along with schematics/documents (as others do), wire your system correctly (after going through electrical aspect of data sheet), doing a bit of debug of SW and HW (as we do not have your end application).

Regards

Amit

cb1_mobile said:

cb1 cocks, blows upon, silently raises pistol to head...   (perhaps not the best way, "to run a railroad"...)

 Hey friend nor you nor Amit, please don't do that... Shoot out what is wrong.. Old member  too if insist leave forum unsplitted/uncontrolled...

 Also remember the one with sharp antialias filter and loose notch one reversing the purpose of...

Antialias filters - and loose notch ones - all will be confounded when, "UNPOWERED!"  (poster's preferred "method!")

My prayer - that, "Sandra & George" re-unite - and "launch this undeserving post" far from their Gravity orbit...

Enough - I've applied all reason & logic as taught @ multiple, professional schools.  Not that it will help...but...

Enforcement - enforcement - enforcement!

Helping the (very few) at the sake of the (very many) via excessive/on-going assistance w/clearly esoteric, likely unreachable (i.e. poster's skills/experience clearly mismatched to post's goals/objectives) - serves no one!  In fact - the time (misspent) in this effort directly subtracts from that available for items far more necessary - and beneficial to the far larger, MCU user community.

As past stated (3 times now) "Post not in compliance w/forum rules/regulations!" as the sole response to "improper requests" - at minimum demands some, "trial run..." 

Present method has demonstrably failed (24 bit ADC confusion extends now to 30 back-forth) - is getting worse - and the ability to better conserve & focus skilled tech resources should be "welcomed" - not resisted!