Support for Digital Potentiometer Analog Devices AD5263 (I2C)

[Michel Lawaty]

Hi,

I would like to have support for a digital potentiometer chip (AD5263 with 4 channels). There are also other members available in this family.

As I didn't find any of these supported I fear I have to write my own driver.

• How would I start with this?
  
• Could I use a specific device driver as a template to start with ?
  
• I wired it up with I2C but the chip apparently also supports SPI

thanks in advance!

Michel

[hal8000b]

I would be careful with that IC, as it requires a dual +5, -5 V supply or 10 to 15V if used on a single supply.
You dont want any of this voltage on the Pi's I2C bus whose core voltage is 3V3.

Also as the  AD5263 has 256 positions (8bit)   you can safe yourself a headache and use the PCF8591 which is already
supported in Webiopi.

The PCF8591 has 4 ADC input channels (8bit) and 1 8bit ADC output and can run directly from the Pi's 3V3 supply.
The device is CMOS so to use to measure potentiomers, wiire output connections to ground and Vcc and each wiper
to analog inputs.  This gives you values of 0 to 255  (bearing in mind that a potentiometer generally has a rotation
of 270 degrees).
If this is something you want I will send a schematic though its very easy to connect to the I2C bus.

[Michel Lawaty]

hello hal,

the PCF8591 is a ADC DAC and not a digital potentiometer chip. It doesn't output resistance.

There is no digital potentiometer chip supported in webiopi, yet.

And the datasheet shows that the AD5263 works fine with  5V.

From datasheet:

Power Single-Supply Range VDD RANGE VSS = 0 V 4.5 16.5 V 

Actually I already wired it up and can see the device on the I2C Bus.

It seems that it is working. 

I will experiment more and let you know.

cheers

Michel

[Andreas Riegg]

Hi,

the attached basic driver may do the job. Its only tested with my I2C mockup classes, so errors may occur with the real chip, but you will see.

It has some limitations due to the capabilities of the chip and works only for I2C, but setting the resistor values for all 4 channels should work fine (e.g. via the Devices Monitor)

You have to replace the __init__.py in the .../analog subdirectory with the new one and also copy ad5238.py to this subdirectory. Then stop WebIOPi, execute "sudo ./setup.sh skip-apt" once in the root directory of your WebIOPi installation and restart WebIOPi.

The config file entry is just

dac1 = AD5263

in the [DEVICES] section.

Cheers,
Andreas

[Michel Lawaty]

Hello Andreas!

Thank you for your awesome work!

I tested the driver with my eval board and it worked!!!

As I am using 5 Volts. The address scheme of this chip according to the datasheet is 

0101 1 AD1 AD0 (R/W)

When I use sudo i2detect -y 1 

I get a 0x2e as the address.

So I configured the device like that:

dac1 = AD5263 slave:0x2e vref:5

Then it starts successfully as DAC device with the messages at the bottom. Would be nice to have ohm values instead of voltages, but this would need calibration. Therefore this should be solved on the "Application" level I guess.

@Eric: Are you planning to integrate all these awesome drivers like AD5263(Andreas Riegg) or MCP3424 (Justin Miller) in one of the next releases?

(I don't know how to write a PN to him)

That are the registration messages while starting the webiopi server:

2015-10-09 08:11:28 - WebIOPi - DEBUG - Mapping AD5263(slave=0x2E).analogCount to REST GET /devices/dac1/analog/count

2015-10-09 08:11:28 - WebIOPi - DEBUG - Mapping AD5263(slave=0x2E).analogMaximum to REST GET /devices/dac1/analog/max

2015-10-09 08:11:28 - WebIOPi - DEBUG - Mapping AD5263(slave=0x2E).analogRead to REST GET /devices/dac1/analog/%(channel)d/integer

2015-10-09 08:11:28 - WebIOPi - DEBUG - Mapping AD5263(slave=0x2E).analogReadAll to REST GET /devices/dac1/analog/*/integer

2015-10-09 08:11:28 - WebIOPi - DEBUG - Mapping AD5263(slave=0x2E).analogReadAllFloat to REST GET /devices/dac1/analog/*/float

2015-10-09 08:11:28 - WebIOPi - DEBUG - Mapping AD5263(slave=0x2E).analogReadAllVolt to REST GET /devices/dac1/analog/*/volt

2015-10-09 08:11:28 - WebIOPi - DEBUG - Mapping AD5263(slave=0x2E).analogReadFloat to REST GET /devices/dac1/analog/%(channel)d/float

2015-10-09 08:11:28 - WebIOPi - DEBUG - Mapping AD5263(slave=0x2E).analogReadVolt to REST GET /devices/dac1/analog/%(channel)d/volt

2015-10-09 08:11:28 - WebIOPi - DEBUG - Mapping AD5263(slave=0x2E).analogReference to REST GET /devices/dac1/analog/vref

2015-10-09 08:11:28 - WebIOPi - DEBUG - Mapping AD5263(slave=0x2E).analogResolution to REST GET /devices/dac1/analog/resolution

2015-10-09 08:11:28 - WebIOPi - DEBUG - Mapping AD5263(slave=0x2E).analogWrite to REST POST /devices/dac1/analog/%(channel)d/integer/%(value)d

2015-10-09 08:11:28 - WebIOPi - DEBUG - Mapping AD5263(slave=0x2E).analogWriteFloat to REST POST /devices/dac1/analog/%(channel)d/float/%(value)f

2015-10-09 08:11:28 - WebIOPi - DEBUG - Mapping AD5263(slave=0x2E).analogWriteVolt to REST POST /devices/dac1/analog/%(channel)d/volt/%(value)f

This is how the WebInterface looks like:

[Andreas Riegg]

Hello Michael,

great to hear that it works, so it makes sense to finalize the driver.

I have polished the driver file a bit, fixed the I2C default address and added the possibility to do an arbitrary channel read. The updated version is attached.

To update, you have to replace the driver file and call setup as mentioned once again.

To test the updated driver, first look in the device monitor if everything works correct. Then set the sliders to different values. After that, you can enter the URLs in a new browser window to retrieve the individual channel values like

..../analog/0/float
..../analog/1/float
..../analog/2/float
..../analog/3/float

and see if the different slider values are still just read correct.

If this is ok, then all works as it should.

Cheers,
Andreas

[Michel Lawaty]

Hello Andreas,

thanks again! I tested the driver with a AD5263 and the same config as in the last post.

Then I followed your test procedure and came to this result.

I used a rest call like you said:

http://*******:8000/devices/dac1/analog/2/float

Test:

Channel 0

0.00V --> 0.00

5.00V --> 1.00

2.60V --> 0.52

Channel 1

0.00V --> 0.00

5.00V --> 1.00

2.25V --> 0.45

Channel 2:

1.80V --> 0.36

I hope Eric takes this driver to the release.

As I understand there is only shutdown and the digital outputs missing

Thanks again and have a nice weekend!

Michel

--
You received this message because you are subscribed to a topic in the Google Groups "WebIOPi" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/webiopi/8NvzHB-4s98/unsubscribe.
To unsubscribe from this group and all its topics, send an email to webiopi+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andreas Riegg]

Hi,

just to finalize this activity, I have generalized the driver a bit so that it supports now all AD52-series chips that implement the I2C protocol and have a volatile register memory.

They are:

"AD5161", "AD5241", "AD5242", "AD5243", "AD5245", "AD5246", "AD5247", "AD5248", "AD5263", "AD5280", "AD5282"

You find the updated driver files attached, maybe someone wants to test them.

Cheers,
Andreas

[Michel Lawaty]

I will test them with the AD6263, and post the result.

Thank you Andreas for your work !

[Michel Lawaty]

Hi Andreas,

I tested at least the AD5263. It works as before. But I don't have other chips to test.

One other question:

Would it be possible to expand the ADXX driver to SPI support?

The AD5263 is quite limited with its two address bits (only four chips can be used and I would need at least four more).

So I thought of a chip select for I2C, using some GPIO expanders I have stacked onto my raspberry.

But the same expander could be used to provide chip selects for SPI, I guess.

The problem is, that this creates a dependency to other ports being used setting the chip select. So I think this is not possible without creating a custom made driver specific to the hardware. 

Sorry for being unspecific here, but I am still in idea creation for how to solve the problem with limited amount of address bit for I2C.

Any ideas welcome.

cheers

Michel

[Andreas Riegg]

Hi Michel,

I understand your problem but it is not trivial to solve it. Switching I2C bus would be an option, there are a lot of I2C "switch" chips on the market you could use (e.g. the PCA9540B just to name an example). This solution will work stable, but you will have additional wiring necessary plus a driver for the I2C multiplexer chips (which would be not a severe problem anyway).

Using SPI is indeed an alternative, but it comes with some constraints:

- The AD5263 SPI interface comes with some restictions, mainly it does not allow to read the resistor values back unlike the I2C interface which allows this. This can be somewhat compensated by caching the written values in the device driver, but if you use the same driver instance for multiple chips by controlling the CS signal via any GPIO port, then the cached values will become inconsistent. As long as you just write the values, the whole thing will still work, but as soon as you begin to rely on read back values, this will fail. And, it makes no sense to enrich the existing I2C driver with this functionality. It will be better to provide a fully separate driver for this.

- Controlling the CS signal directly via some GPIO port will probably not work stable as this is very likely to violate some constraints of the SPI timing protocol. A possible solution would be to enable and disable the original CS signal with some logical gate that combines the original CS signal with the state of some GPIOs as this will keep the timing of the CS signal intact. However, you will need some additional gate chips and wiring for this solution.

And finally if you look at the chip spec of the AD5263 on page 19 (figure 47) there is something like a "daisy chain configuration" in the SPI mode. This solution is by far clearly the one with the most simple wiring at all, you just need an additional pullup resistor between the individual chips. However, such a configuration would need a different driver implementation as the "values" get shifted through a complete sequence of chips, but it looks to be still possible to have a driver for this.

In order to tackle the problem I can try to first create a driver that supports a single AD5263 SPI chip (which is in fact 2 chips as you have two CS signals on the RPi SPI header). If this works correct I can try to modify that driver in a way so that it supports the daisy chain configuration for SPI and maybe this works. However, the number of chips that can be chained together will still be limited to some unknown number as some timing problems may occur due to the small delays between the SDO and SDI ports at the end of the chain. Plus, the CS and CLK outputs of the RPi will have to drive the inputs of ALL chained SPI chips simultaneously, maybe this can also introduce problems depending on the number of chips. Overall, I can't say if this will occur when using 4 chips or 400, its just unknown for me.

Cheers,
Andreas

[Michel Lawaty]

Hello Andreas,

thank you for your long answers and ideas.

I will comment every solution:

1. Switching I2C: I think this sounds interesting, but I don't know how this would work without combining multiple drivers together. Somehow a cluster of Switcher Chip and peripheral chips is necessary and a control mechanism for this. So I think this is too complicated.
2. Manual switching via Chip enable: I totally agree, this is to fickle and buggy. It wouldn't be of any use for someone else. Or it would be to  complicated to setup something like this.
3. Using daisychain via SPI: This is the solution I know from other use cases. It is slow, but it works reliable. You're right, that the amount of chips would be limited, but I think this would be a valid limitation. I could test this here an build up a chain of e.g. 5 chips. Then we would comment the driver and claim that it was tested with e.g. 5 chips

So, thank you very much and of course I would be really happy to test drivers you write for this. Just let me know.

Cheers

Michel

[Andreas Riegg]

Hi Michael,

ok, I would then try to provide a pure SPI driver for a single chip first to make sure the SPI connection to this chip works correct and stable.

After this proves to work as expected, I would try to provide a modified (separate) driver for the SPI daisy chain configuration.

Best,
Andreas

[Andreas Riegg]

Hi Michael,

here is the SPI driver beta for the AD5263. It works currently only for a single AD5263 and not in a daisy chain wiring.

The device class for the config file is AD5263S to select the SPI version. It has one parameter "chip" that allows to select the used CS signal from the SPI controller, default is 0. I have renamed the driver file without the digits to "advrspi.py" as this makes more sense due to the vast number of different named VR devices from AD.

I will also rename the I2C driver file and classes to stay consistent.

Please test the driver if it works for one chip.

Best,
Andreas

[Michel Lawaty]

Hello Andreas,

thanks very much for the driver. I will test it on the coming monday. As there will be my eval platform available.

I will let you know the result.

cheers

Michel

[Michel Lawaty]

Hi Andreas,

hmm I have a problem right now.

I registered the chip in config with that:

dac2 = AD5263S chip:0

My __init__.py in /analog/ contains that:

DRIVERS["ad52XX"]  = ["AD5161", "AD5241", "AD5242", "AD5243", "AD5245", "AD5246", "AD5247", "AD5248", "AD5263", "AD5280", "AD5282"]
DRIVERS["mcp3424"] = ["MCP3424"]
DRIVERS["advrspi"] = ["AD5263S"]

The folder /analog/ contains your driver:

./advrspi.py

But webiopi output log gives me following error, when I start it:

2015-11-17 09:13:20 - WebIOPi - DEBUG - Mapping AD5263(slave=0x2E).analogWriteVolt to REST POST /devices/dac1/analog/%(channel)d/volt/%(value)f

2015-11-17 09:13:20 - WebIOPi - INFO - DAC - AD5263(slave=0x2E) mapped to REST API /devices/dac1

2015-11-17 09:13:20 - WebIOPi - ERROR - Device driver not found for AD5263S

Traceback (most recent call last):

  File "/usr/local/lib/python2.7/dist-packages/WebIOPi-0.7.1-py2.7-linux-armv6l.egg/webiopi/__main__.py", line 75, in <module>

    main(sys.argv)

  File "/usr/local/lib/python2.7/dist-packages/WebIOPi-0.7.1-py2.7-linux-armv6l.egg/webiopi/__main__.py", line 69, in main

    server = Server(port=port, configfile=configfile, scriptfile=scriptfile)

  File "/usr/local/lib/python2.7/dist-packages/WebIOPi-0.7.1-py2.7-linux-armv6l.egg/webiopi/server/__init__.py", line 66, in __init__

    manager.addDevice(name, driver, args)

  File "/usr/local/lib/python2.7/dist-packages/WebIOPi-0.7.1-py2.7-linux-armv6l.egg/webiopi/devices/manager.py", line 24, in addDevice

    raise Exception("Device driver not found for %s" % device)

Exception: Device driver not found for AD5263S

What do I do wrong??

Thank you!

Michel

[Andreas Riegg]

Hi Michel,

at at first glance it looks you did nothing wrong on source and config file level. However, you may have trapped into one of the small pitfalls Python/WebIOPI offers ...

After copying/updating the new files to /analog, did you then call "sudo ./setup.sh skip-apt" at least once again? If not, please do it and retry.

If you look at the error message you will notice that WebIOPi does in fact at runtime not use the source files from your installation directory, but from somewhere else ("/usr/local/lib/python2.7/....). The same applies for the compiled *.pyc files that Python really runs. The WebIOPi setup procedure handles this correct and automatically, but to do so, you MUST call it EVERY time you change any of the source files of WebIOPi.

In a very rare case I also had the problem that my SD card (better, the whole RPi filesystem) went accidentially into read-only mode due to some unknown problem. In this case I also encountered the problem above, because I called setup.sh correct, but after restarting the RPi the changes were lost. It took me some time to figure that out, but I hope you do not have the same problem.

In any case, you can look at the special path stated above and check if the __init__.py in the /analog directory there is the same updated version you need and if the corresponding *.pyc file has a timestamp newer that the *.py file.

Hope this helps,
Andreas


[Michel Lawaty]

Hi Andreas!

Yes this helped! Actually I read one of your other answers and figured it out by myself. So, sorry for bothering you with that!

Now to the test of the driver:

The driver is loading properly it seems:

2015-11-17 11:12:09 - WebIOPi - DEBUG - Mapping AD5263S(chip=0).analogCount to REST GET /devices/dac2/analog/count

2015-11-17 11:12:09 - WebIOPi - DEBUG - Mapping AD5263S(chip=0).analogMaximum to REST GET /devices/dac2/analog/max

2015-11-17 11:12:09 - WebIOPi - DEBUG - Mapping AD5263S(chip=0).analogRead to REST GET /devices/dac2/analog/%(channel)d/integer

2015-11-17 11:12:09 - WebIOPi - DEBUG - Mapping AD5263S(chip=0).analogReadAll to REST GET /devices/dac2/analog/*/integer

2015-11-17 11:12:09 - WebIOPi - DEBUG - Mapping AD5263S(chip=0).analogReadAllFloat to REST GET /devices/dac2/analog/*/float

2015-11-17 11:12:09 - WebIOPi - DEBUG - Mapping AD5263S(chip=0).analogReadAllVolt to REST GET /devices/dac2/analog/*/volt

2015-11-17 11:12:09 - WebIOPi - DEBUG - Mapping AD5263S(chip=0).analogReadFloat to REST GET /devices/dac2/analog/%(channel)d/float

2015-11-17 11:12:09 - WebIOPi - DEBUG - Mapping AD5263S(chip=0).analogReadVolt to REST GET /devices/dac2/analog/%(channel)d/volt

2015-11-17 11:12:09 - WebIOPi - DEBUG - Mapping AD5263S(chip=0).analogReference to REST GET /devices/dac2/analog/vref

2015-11-17 11:12:09 - WebIOPi - DEBUG - Mapping AD5263S(chip=0).analogResolution to REST GET /devices/dac2/analog/resolution

2015-11-17 11:12:09 - WebIOPi - DEBUG - Mapping AD5263S(chip=0).analogWrite to REST POST /devices/dac2/analog/%(channel)d/integer/%(value)d

2015-11-17 11:12:09 - WebIOPi - DEBUG - Mapping AD5263S(chip=0).analogWriteFloat to REST POST /devices/dac2/analog/%(channel)d/float/%(value)f

2015-11-17 11:12:09 - WebIOPi - DEBUG - Mapping AD5263S(chip=0).analogWriteVolt to REST POST /devices/dac2/analog/%(channel)d/volt/%(value)f

2015-11-17 11:12:09 - WebIOPi - INFO - DAC - AD5263S(chip=0) mapped to REST API /devices/dac2

But I can't measure changing ohm Values when measuring between A1 and W1 or B1 and W1.

It seems that the values are floating between 290kOhm and 304kOhm, which is not possible...

So either I am measuring wrong (Digital Multimeter) , or the circuit is wrong.

Now I fear, that I did something wrong with the circuit. As I have no bus level converter anymore, I used the Vlogic input for using 3VDC3 as bus logic level and 5VDC for powering the chip.

See attached my circuit.

[Andreas Riegg]

Hi Michel,

from what I see from your wiring, it looks nothing is completely wrong. The separate VDD and VLOGIC wiring seems to match the spec of the chip, so that should be ok.

What I observe:

• You also connect SDO of the chip to the MISO pin. This is unnecessary as the chip never sends anything specific back. It just replicates the SDI signal with a slightly delay, The SDO pin has to be used later to realize the SPI daisy chain between the chips.
• You leave the SHDN and RES pins open (and thus floating). At least for the SHDN the spec says to connect it to 5 V if unused. So maybe it helps to connect both to 5 V (maybe even via a pullup).

What you could check:

• What is the behaviour of the chip when the RPi is powered on but the driver not loaded (WebIOPi not running)?
• Are there differences between the channels?
• What dou you mean with floating? Do you change any of the AD channel settings just once, let it then be constant and the value still floats while doing nothing with WebIOPi?
• If you change the analog value for ANY of the channels and measure ONE channel, does it show any reaction or not, especially when you change a channel value that is not dedicated to the measured channel?
  

Maybe this helps to figure out the problem a bit.

Cheers,
Andreas

[Michel Lawaty]

Hello Andreas,

thank you for your answer. I debugged the circuit (not wired by me ;-)) and found some power issue. Now it is fine. I wrote to each of your questions an inline answer.

But I have another assumption. Right now two other chips are connected to SPI as well! So maybe the data going to the AD5263 gets corrupted or something ?

I would then try to remove all chips sitting on SPI, except AD5263.

Am Dienstag, 17. November 2015 18:01:34 UTC+1 schrieb Andreas Riegg:

Hi Michel,

from what I see from your wiring, it looks nothing is completely wrong. The separate VDD and VLOGIC wiring seems to match the spec of the chip, so that should be ok.

What I observe:

• You also connect SDO of the chip to the MISO pin. This is unnecessary as the chip never sends anything specific back. It just replicates the SDI signal with a slightly delay, The SDO pin has to be used later to realize the SPI daisy chain between the chips.

 Yeah, I thought so, that it will be used for daisy chaining, just wanted to already wire this output. If it is no technical problem, I can leave it, I assume.

• You leave the SHDN and RES pins open (and thus floating). At least for the SHDN the spec says to connect it to 5 V if unused. So maybe it helps to connect both to 5 V (maybe even via a pullup).

 Ok, I pulled them to 5V.

What you could check:

• What is the behaviour of the chip when the RPi is powered on but the driver not loaded (WebIOPi not running)?

Both states (webiopi server running/not running) the measurement between B1 and W1 /resp. B2 and W2) is 10.45 kOhm. This is the nominal value, the chip should output after startup.

• Are there differences between the channels?

No 

• What dou you mean with floating? Do you change any of the AD channel settings just once, let it then be constant and the value still floats while doing nothing with WebIOPi?

Solved by fixing the wiring. 

• If you change the analog value for ANY of the channels and measure ONE channel, does it show any reaction or not, especially when you change a channel value that is not dedicated to the measured channel?
  

Solved by fixing the wiring. 

[Andreas Riegg]

Hello Michel,

how are the two other SPI chips connected? Under normal operation and the condition that is used for WebIOPi SPI communication, the RPi can only control 2 different SPI chips which are selected via the CE0 and CE1 chip select signals. Some special chips exist that use some kind of extended subadressing, but the AD5263 does not support this so it should be selected by exactly one CEx line that is dedicated to it. Also, some "tricks" exist to control the CEx signals via any of the GPIO outputs more or less manually, but the SPI drivers of WebIOPi do not support or implement this. Are the other connected SPI chips also controlled via WebIOPi? What are they?

If for any reason the chip selection for the AD5263 does not work reliable it will pick up any bits sent via MOSI to him (and others) and use them as new value as soon as the CE signal goes high again. This will result in arbitrary resistor values for all 4 channels.

To get correct test results, I would recommend to first test the AD5263 being the only chip on the SPI bus and see if that works correct or not.

Best,
Andreas

[Michel Lawaty]

Hi Andreas,

The other two chip are from a shield:

ADC-DAC-Pi

These two chips are used, the vendor also has python code on the website:

MCP3202

MCP4822 

I removed this board, though. Then tested AD5263 on CE_0 and CE_1 (but AD5263 is connected to CE_0).

But still, always 10Kohm at the outputs.

The value doen't even move, if I am loading/stopping the driver...

I am pretty sure that it is wired up correctly, but can go through it again.

cheers

Michel

[Andreas Riegg]

Hi Michel,

from what I can see from the wiring of the additional breakout board is that you can't use it together with your AD5263 board as the ADCDAC board utilizes CE0 and CE1 already. No more CE signal is left.

However, as WebIOPi also supports MCP4822 officially (but not the MCP3202 as of today), you can test this chip on your ADCDAC board also separate to see if WebIOPi can handle that chip correct on your RPi setup. If you don't use the ABElectronics code this will make sure that WebIOPi SPI communication works correct at all at least for the MCP4822. The chip parameter should be 1 for that board.

In fact, my AD526 driver is very deep inspired (partly identical) by the official MCP4822 driver, so this will be an important hint to see if that works.

Cheers,
Andreas

[Michel Lawaty]

Hi Andreas,

thank you very much!

Both chips from the DAC/ADC shield work with webiopi on my setup (MCP3203 has a driver from the forum, not official).

So if your driver is near to the MCP4822, it should actually work.

And I found something! 

DIS pin has to be 0 for SPI mode ( I knew that), but now I tied him to GND, apparently the pin was floating!

Now I can control the chip!

When I measure between B and W: 

I can change the values from ca. 100ohm to 20kohm.

Applies to :

channel-0

channel-1 

channel-2

channel-3

Awesome! Sorry for bothering you with this wiring issues. 

your driver works!

Would be great to test the daisy chain ;-) But for this I will need to build up a bigger sample, which will take a bit.

cheers

Michel

[Andreas Riegg]

Hi Michel,

great to hear it works :-)

I will now generalize the driver first so that it supports a bunch of the other VR chips of AD in SPI mode and put it together with the I2C variants into one complete package to have a consistent state.

After that, I will create another driver that allows SPI daisy chaining. That may take a while because it will be a bit tricky for multichannel VR chips. Daisy chaining of single channel chips will be quite easy. Daisy chaining of arbitrary mixtures of multi/single chips is possible in principle but will not be supported because it is too complicated and not worth the effort.

Cheers,
Andreas

[Michel Lawaty]

Hey Andreas,

thanks.

Will you generalize the driver for VR chips also in that sense, that not float values but binary values (0-255 steps) are used? 

Using "ohm" as a unit would be great, but without calibration mechanism this probably makes no sense.

I will order parts and create an eval board for the daisy chaining. You mentioned the degradation of the signal going through multiple chips. What would be the recommend amount? I wanted to prepare the eval board for e.g. ten chips and then see (by measurement) where the degradation of the SDO signal is so high, that it won't be safely detected anymore. This could serve as a constraint for the driver and documentation.

Arbitrary mixtures is not necessary, probably nobody would use it, because you usually decide for one type of chip and stick to that

How will the operation look like? Will the driver be initialized with a specific type and amount of chips? Like today the chip:0 or VRef=5 statement?

Thank you for your support!

Michel

P.S.: Building up the demo will take one or two weeks probably, due delivery etc. I will let you know.

[Andreas Riegg]

Hi Michel,

here is the complete package of the "normal" ADVR drivers.

It consists of 3 files:

• advri2c.py which has the drivers for the I2C versions of the chips
• advrspi.py which has the drivers for the SPI versions of the chips
• __init__.py for /analog that is updated to provide the driver classes lookup

In summary, all the following chips are supported:

• I2C: "AD5161I", "AD5241", "AD5242", "AD5243", "AD5245", "AD5246", "AD5247", "AD5248", "AD5263I", "AD5280", "AD5282"
• SPI: "AD5160", "AD5161S", "AD5162", "AD5165", "AD5200", "AD5201", "AD5204", "AD5206", "AD5263S", "AD5290", "AD8400", "AD8402", "AD8403"

The two chips that offer a selectable I2C and SPI interface are marked in red. The drivers have been tested only with your AD5263 real hardware for I2C and SPI.

Concerning the REST interface for using integers, it is already implemented within WebIOPi for a longer time. Given "dac1" is one of the ADVR chips, you can already set any of the resistor values by e.g. using

• HTTP POST ...devices/dac1/analog/1/integer/255 or
• HTTP POST ...devices/dac1/analog/1/integer/10

You can also read them as integers this way:

• HTTP GET ...devices/dac1/analog/1/integer

Providing an Ohm interface makes almost no sense at the moment as the final value depends on the different basic Ohm values of the chips and needs an extension of the REST API that may be too specific at the moment. If you really need any Ohm value today you could implement that within a WebIOPi macro if you want.

For the daisy chain driver I think of providing special driver classes that indicate the basic type and daisy chain wiring in their name (e.g. AD5263DC) and having an additional config parameter like "chips:x" that indicates the amount of chips in the chain. The analog channels will just be sequenced according to the number of channels each chip has, so for a AD5263 having 4 channels, channel #2 of chip #0 is analog channel 2 in WebIOPi, channel #3 of chip #3 would be analog channel 15 in WebIOPi (assuming all numbering starts at #0).

Regarding the total of possible chips in the chain, I have no glue what this could be until problems occur. I assume something around 10 should be possible, but this is just a rough guess. Decreasing the overall SPI frequency will help, but then the maximum update frequency of the channels will degrade. So at the end, it depends on your wiring and concrete application.

That's it for today, just let me know when your daisy chain demo board is ready to be tested.

PS: If you update the drivers, don't forget to call "sudo ./setup.sh skip-apt" at least once again :-).

Cheers,
Andreas

[Michel Lawaty]

Hi Andreas,

I ordered the samples. So this will take a while until the eval board is build up.

Will write here when ready.

Cheers

Michel

[Michel Lawaty]

Hello Andreas,

happy new year to you and all the others in the forum!

The prototype for the AD5263 daisy chain control is in progress.

Here's the latest state:

It will still take some time, but not long any more.

So if you are still willing to help, I would be glad to test a driver with this board, which has up to 10 AD5264 Potentiometer chips!

cheers

Michel

[Michel Lawaty]

I am not sure if the picture was inserted properly, so I attached it to this post

[Andreas Riegg]

Hello,

happy new year to all also from my side.

Picture looks great. I have the structure/algorithm of the driver already in my head, but it will take some days to write it down in Python code :-)

Cheers,
Andreas

[Andreas Riegg]

Hi Michel,

found the time to implement the daisy chain driver.

You find the two files attached. The driver has no limitation regarding the number of chips in a chain, but as we have already discussed the timing along the chain may cause instability at some currently unknown number of chips in the chain.

The driver can only support a chain with almost identical types of chips. Their number of resistor ports must be the same and they must use the same addressing scheme and number of bits for these ports.

The chip channels are mapped as follows:

You will get one single WebIOPi DAC device with a channel numer being the number of ports per chip multiplied by the number of chips in a chain.

The first chip in a chain will start with port number 0 and the number increase subsequent per ports on a chip in the sequence along the chain.

So, for example, the port 0 of an AD5263 being the third in a chain will get the channel number 8, the port 3 of the fifth chip in the chain will get channel number 39.

In the config file, the entry e.g. should be:

daisychaindac = AD5263DC chips:5

if you have 5 chips in the chain listening to SPI 0 and having all CS 0 connected at once.

The driver is complete but beta and has some extended debug output statements, so please test it and we will see if it works.

Cheers,
Andreas

[Michel Lawaty]

Hello Andreas!

Great Thank You!

If everything will go fine, the board is ready on friday, so I will test the driver next week.

I will let you know, how it worked with 10 chips, and will reduce, if I run into issues.

Thank you very much.

Michel

[Andreas Riegg]

Hi,

is there anything new here or has this activity being stopped?

Cheers Andreas

[Michel Lawaty]

Hi Andreas,

no, the activities didn't stop, but slowed down dramatically, as there were some changes here being in the way. But I have all components on my desk. Now I will try to get your driver running.

I will let you know my results soon.

Sorry that it takes so long.

Cheers

Michel

[Michel Lawaty]

I ordered some additional electronic parts I need, for finishing the board. Apparently Conrad supplier seems to have problems with its order process in germany right now. They cancelled two of my orders and I wait already three weeks for the parts...that's why the project is delayed.

greetings 

Michel

[Andreas Riegg]

Michel,

thanks for the update. Well, software problems could be easier solved :-)

Greetings,
Andreas