AD5262 in daisy chain mode

Hi,
I am currently working on a project where I want to control two AD5262 with an ATTiny861.
So far I have achieve to control the first AD5262 by sending 16 bits to the SDI pin.
The first byte is the address and the other is the value as indicated in the AD5262 manual.
I know that the AD5262 is working with 9bits but I am using 16 bits and I don't have any issues, since the rest are ignored and only 9bits are kept.
The problem is when I try to put two AD5262 as daisy chained.
I use the pull up resistor (2.2KOhm) connected to the SDO pin and to VDD. I DONT use any capacitor.
Then I am sending 32bits (4bytes). The result is that the first AD5262 is working properly but I have no data on the second one.
If exactly 9 bits are required I don't know how to bit bang 9bits to an ATTiny861, but since the first AD5262 is working I don't believe that's the issue.

Any help will be much appreciated.
Thanks in advance.

Below is the part of the code I am using for sending the commands to the pots.

void digitalPotWritePOTCh1(byte value1,byte value2)
{
digitalWrite(SPI_CS, LOW);
SPI.transfer(0b00000000); //POT 1 on AD5062 #1
SPI.transfer(value2);
SPI.transfer(0b00000000); //POT 1 on AD5062 #2
SPI.transfer(value1);
digitalWrite(SPI_CS, HIGH);
}

void digitalPotWritePOTCh2(byte value1,byte value2)
{
digitalWrite(SPI_CS, LOW);
SPI.transfer(0b11111111); //POT 2 on AD5062 #1
SPI.transfer(value2);
SPI.transfer(0b11111111); //POT 2 on AD5062 #2
SPI.transfer(value1);
digitalWrite(SPI_CS, HIGH);
}

So far I have achieve to control the first AD5262 by sending 16 bits to the SDI pin.

While you you may think you have achieved control of the AD5262, sending 16 bits to the device is an invalid message.

The first byte is the address and the other is the value as indicated in the AD5262 manual.

No, the first BIT is the channel address.

I know that the AD5262 is working with 9bits but I am using 16 bits and I don't have any issues, since the rest are ignored and only 9bits are kept.

Please show me in the AD5262 datasheet where AD says the device ignores the additional 7 bits. If you didn't have any issues with 16 bits you'd not be here asking questions!

The simple answer to your problem is that you're sending invalid data to the device. The device requires a 9 bit format word, the Arduino SPI library cannot provide this functionality, it must be done in software, it is called "bit banging".

Here is a ready made library for your use. You'll need to extract just two files, AD5262.cpp and AD5262.h. If you need help in creating a library directory and using the library presented here, please ask.

First of all thanks for your reply and for your help!
I will give it a try and let you know of the results.
Yes I know how to import and use a library.
I am not the first to use an AD5262 and in all the examples I found online everybody uses 16bit. The problem is that they don't use a daisy chain configuration thought.
If you go to page 15 the manual says:

"For the AD5262, the last nine bits of the data word entered into the serial register are held when CS returns high. Any extra bits are ignored. At the same time CS goes high, it gates the address decoder, enabling one of two positive edge-triggered AD5262 RDAC latches (see ). Figure 48"

So it's not something I invented.

My problem is the daisy chain configuration.
I know about bit banging (not in depth) but I have never used it.
Your libraries will be a great help, thanks again!

You are correct but dropping CS deselects the part - which cannot be done after transmitting just 9 bits with the existing SPI library. In order to use the existing SPI library, as you were attempting to do, you must create a continuous bit stream of the desired data, you cannot send 16 bits and then drop the CS line and then re-assert the CS line. You'll never get the data out of the first device and into the second device in this way.

Let's try to achieve what you want for two daisy chained AD52562's. We'll assume the following desired values for the pots:

Device 1 Pot 0 =  63 (0x3F) 
Device 1 Pot 1 = 127 (0x7F) 
Device 2 Pot 0 = 191 (0xBF) 
Device 2 Pot 1 = 255 (0xFF)

This represents a total of 36 bits of data (4*9) which requires 5 bytes to convey the information. Sending that data stream would require this code:

void digitalPotsDemo()
{
 digitalWrite(SPI_CS, LOW);
 SPI.transfer(0x1F);
 SPI.transfer(0xDF);
 SPI.transfer(0xD7);
 SPI.transfer(0xFF);
 SPI.transfer(0xF0);
 digitalWrite(SPI_CS, HIGH);
}

Please give that a try, it should work. I will then leave you to decode the bitstream to see how you'll need to do some significant bit shifting to get this method to function as a subroutine.

In the end, you may find it easier to just use the existing library. I cannot speak for you but I'm the type of individual that must understand how a device works, it is more important at times than just being able to use the device.

Here's the decoding:

Device 1 Pot 0 = adr0 & 0d7->0d0 
Device 1 Pot 1 = adr1 & 1d7->1d0
Device 2 Pot 0 = adr2 & 2d7->2d0
Device 2 Pot 1 = adr3 & 3d7->3d0

+------+------+------+------+------+------+------+------+
| adr0 | 0-d7 | 0-d6 | 0-d5 | 0-d4 | 0-d3 | 0-d2 | 0-d1 | byte 1 (0x1F)
+------+------+------+------+------+------+------+------+
| 0-d0 | adr1 | 1-d7 | 1-d6 | 1-d5 | 1-d4 | 1-d3 | 1-d2 | byte 2 (0xDF) 
+------+------+------+------+------+------+------+------+
| 1-d1 | 1-d0 | adr2 | 2-d7 | 2-d6 | 2-d5 | 2-d4 | 2-d3 | byte 3 (0xD7)
+------+------+------+------+------+------+------+------+
| 2-d2 | 2-d1 | 2-d0 | adr3 | 3-d7 | 3-d6 | 3-d5 | 3-d4 | byte 4 (0xFF)
+------+------+------+------+------+------+------+------+
| 3-d3 | 3-d2 | 3-d1 | 3-d0 |      |      |      |      | byte 5 (0xF0)
+------+------+------+------+------+------+------+------+

Thanks for your detailed answer and for your time spend on my problem.
I understand what you are saying and you are right about the fact that for a daisy chain operation the bytes that they supposed to be ignored are causing a problem to the bit information at the next AD5262.
I will give a try to what you are suggesting and come back with the results.
If it works it will be a challenge to create the function to convert the desired values to the right 36 bit information with the addresses as you described :slight_smile:

Thanks again!