ADS1256 (A/D) doesn't output - Page 1
Forum section: electronics / general

author: AjayS
author_rank: Newbie
timestamp: July 12, 2018, 04:21:07 pm
content: 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.pdfI 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!

author: Kleinstein
author_rank: Super Contributor
timestamp: July 12, 2018, 04:51:22 pm
content: 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 readadc_val += spi_tranceiver(0);instead ofadc_val = spi_tranceiver(0);

author: AjayS
author_rank: Newbie
timestamp: July 12, 2018, 05:10:44 pm
content: 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).

author: sokoloff
author_rank: Super Contributor
timestamp: July 12, 2018, 05:19:01 pm
content: Quote from: AjayS on July 12, 2018, 05:10:44 pmNo.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 <<= operatorIt 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 <<= operatorIt 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.

author: AjayS
author_rank: Newbie
timestamp: July 12, 2018, 06:11:55 pm
content: 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.

author: sokoloff
author_rank: Super Contributor
timestamp: July 12, 2018, 06:20:22 pm
content: Quote from: AjayS on July 12, 2018, 06:04:15 pmNo, 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.Quote from: AjayS on July 12, 2018, 06:04:15 pmNo, ints are 16 bits wide on Arduino. You will get 0x0203Quote from: AjayS on July 12, 2018, 06:04:15 pmNo, it will be 0x0102Quote from: AjayS on July 12, 2018, 06:04:15 pmThis one is correct, but mostly by happenstance.Quote from: AjayS on July 12, 2018, 06:04:15 pmNo, 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 <<= operatorIt gets 0x00000002 added by the second spi call. The result of 0x00000100 + 0x00000002 is 0x00000102.It gets assigned to 0x00010200 by the <<= operatorIt 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

author: AjayS
author_rank: Newbie
timestamp: July 12, 2018, 06:33:51 pm
content: 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)

author: iMo
author_rank: Super Contributor
timestamp: July 12, 2018, 06:43:01 pm
content: For example:Code:..long unsigned int adc_val = 0; // long is 32bits with atmega arduino, you have to do the math with 32bitsadc_val = (adc_val + spi_tranceiver(0)) << 8; // MSB firstadc_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?

author: AjayS
author_rank: Newbie
timestamp: July 12, 2018, 06:51:36 pm
content: 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.

author: iMo
author_rank: Super Contributor
timestamp: July 12, 2018, 06:53:58 pm
content: 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).

author: AjayS
author_rank: Newbie
timestamp: July 12, 2018, 06:59:09 pm
content: 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?

author: iMo
author_rank: Super Contributor
timestamp: July 12, 2018, 07:02:59 pm
content: 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..

author: joeqsmith
author_rank: Super Contributor
timestamp: July 14, 2018, 01:34:36 pm
content: 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.

author: AjayS
author_rank: Newbie
timestamp: July 16, 2018, 02:37:42 pm
content: 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.