ADS1256 (A/D) doesn't output

[AjayS]

Hello all,

I have been working on this A/D converter designed by texas instruments for about a month now. It is an 8 channel (differntial/singal ended), 24 bits A/D that uses SPI to send the converted data.

http://www.ti.com/lit/ds/symlink/ads1256.pdf

I am struggling to get the SPI to transfer the data. The micro-controller that I am using is an AVR ATmega1284P (8-Bit micro-controller). The SPI is configured on this controller works just fine. In the data sheet of A/D converter, the pin /DRDY goes high when the chip is reading the data and goes low until the 24-Bits have been shifted out. I am using the /DRDY as an interupt on falling edge When the /DRDY goes low or the interrupt occurs, I start the SPI communication. What the issue seem to be is the timing. I have also attched the code. Any help would be much appreciated.

many thanks!

[Kleinstein]

One obvious problem is in the ISR to read the 24 bit data. The first 2 bytes are over-written by the next date. So only the last byte is expected to be there. So it should read
adc_val += spi_tranceiver(0);
instead of
adc_val = spi_tranceiver(0);

[AjayS]

To prevent this occurrence, I am shifting 8 bits after receiving them:

adc_val = spi_tranceiver(0);
adc_val <<= 8;
adc_val = spi_tranceiver(0);
adc_val <<= 8;
adc_val = spi_tranceiver(0);


It should basically do the same thing. So when the data come in, which are the 8 bits, it gets shifted to the left and the new 8 bits gets stored at its place and it gets shifted and new 8 bits takes its place. I have tested it with my own values and I think it works. The issue that I believe could be is the timing (when you send data during the LOW /DRDY period or receive data).

[sokoloff]

To prevent this occurrence, I am shifting 8 bits after receiving them:

adc_val = spi_tranceiver(0);
adc_val <<= 8;
adc_val = spi_tranceiver(0);
adc_val <<= 8;
adc_val = spi_tranceiver(0);

It should basically do the same thing. So when the data come in, which are the 8 bits, it gets shifted to the left and the new 8 bits gets stored at its place and it gets shifted and new 8 bits takes its place. I have tested it with my own values and I think it works. The issue that I believe could be is the timing (when you send data during the LOW /DRDY period or receive data).

No.

Imagine that the 3 bytes that come in are 0x01, 0x02, and 0x03 in sequence.

Here's what will happen to adc_val:
It starts undefined.
It gets assigned to 0x00000001 by the spi call.
It gets assigned to 0x00000100 by the <<= operator
It gets assigned to 0x00000002 by the second spi call. (Yes, yes, it does. You are assigning all 32 [or 64] bits of adc_val with the assignment statement.)
It gets assigned to 0x00000200 by the <<= operator
It gets assigned to 0x00000003 by the third spi call. (Yes, yes, it does.)

If you make the operator on the spi call a += as Kleinstein suggests, you'll at least have a chance of getting all three bytes.

[AjayS]

Ahh wait!! I see what you are saying sokoloff. Yes I think I know what the issue is in this case. Took me a while to understand but I got it.

thanks a lot!

But this still doesn't help to get the 24 bits out of A/D.

[sokoloff]

unsigned long adc_val; //Since its a long, you can have as many bits in it as you want right?

No, C and C++ integers are fixed size. This particular one is likely to be 32 bits if I remember correctly. (It's platform dependent.)
You can do sizeof(unsigned long) and that will tell you how many characters wide the type is.

then it gets assigned 0x03 and it becomes 0b000000010000001000000011 or 0x010203

and if i try to access adc_val i will get only the 8 least significant bits
int a;
a = adc_va;
then a will be 0x03;

No, ints are 16 bits wide on Arduino. You will get 0x0203

to get the rest i will do something like:
a = adc_val >>8;
a will be 0x02;

No, it will be 0x0102

a = adc_val >> 16;
a will be 0x01;

This one is correct, but mostly by happenstance.

I dont know if this works but I will try to do it your way and see if it takes me anywhere. But then, adc_val +=api_transceiver(0); basically adding? so we will have0x01+0x02+0x03 at the end?

No, what will happen is this (keep the first one as assignment and the other 2 as plus-equals):

It gets assigned to 0x00000001 by the spi call.
It gets assigned to 0x00000100 by the <<= operator
It gets 0x00000002 added by the second spi call. The result of 0x00000100 + 0x00000002 is 0x00000102.
It gets assigned to 0x00010200 by the <<= operator
It gets 0x00000003 added by the third spi call. The result of 0x00010200 + 0x00000003 is 0x00010203.

If you want to be clearer about what's happening, you can also use |= (bitwise OR-equals).
Mathematically, they are the same.

Edit: bitwise instead of logical OR

[AjayS]

Thanks a lot! I finally understand it otherwise I will be having issues processing the received 24 bits. Now this is figured out, I still cant get the A/D converter to send 24bits to the micro! I do get something but I think all I am getting are junk values. (I use oscilloscope instead of transferring the 24bits via UART and see it in my computer)

[iMo]

For example:

Code: [Select]

..
long unsigned int adc_val = 0;  // long is 32bits with atmega arduino, you have to do the math with 32bits
adc_val = (adc_val + spi_tranceiver(0)) << 8;   // MSB first
adc_val = (adc_val + spi_tranceiver(0)) << 8;
adc_val = (adc_val + spi_tranceiver(0));        // LSB last
..BTW, do you run both mcu and adc at 3.3V?

[AjayS]

The MCU is at 5V. The A/D has given both 5V and 3.3V. 5V for the analog voltage and 3.3V for the digital as recommended in the datasheet.

[iMo]

That is why I ask. You cannot connect 3.3V adc_digi to 5V atmega.
Run the 1284p at 3.3V too (it works fine up to 16MHz).

[AjayS]

Okay I will have 3.3V going in to the atmega for power. But should I leave the analog voltage of the A/D to 5V? Is this going to be an issue?

[iMo]

When the datasheet says the analog part of the ADC is powered from 5V then do it.
But the digital signal levels must match, otherwise you may smoke the adc... I would run the mcu at 3.3V, indeed..

[joeqsmith]

Just an FYI, I found a bug early on when this device first came out.   The data sheets now reflect the work around.  The problem is the LSB of the decoder for the multiplexer was not properly implemented.  If you scanned the channels out of order for example where the LSB does not change states,  the mux would not switch correctly.   If you were to scan all of the channels in sequence, the interface can be simplified.   The new data sheets no longer cover this and they just give you examples that will work for all cases.

If you run the part at the max frequency, you will notice that you basically spend all the time communicating with the part and every little sliver my help. 

[AjayS]

Thanks Joeqsmith. I will keep that in mind. I found the issue. Basically the IC was working fine I don't know since when but it is my breadboard that was causing the whole issue and still is. The signal gets disconnected anytime and it happens with all the SPI pins/wires. That is the only issue stopping me to get the data. I just need to work on better connections. Maybe if this is not the case then I will just switch to another A/D converter.

[joeqsmith]

It seems that the reset pin was sensitive.  Eventually I gave up using this pin all together and tied it off.  Beyond this, I can't remember any other problems with the part.