0

I have a Texas Instruments DAC8568 in their BOOST breakout board package. The DAC8568 is an 8 channel, 16bit DAC with SPI interface. The BOOST package has headers to connect it to my raspberry pi, and it has LEDs connected to the output voltage so you can easily check to see if your code is doing what you think it does. Links to the BOOST package and datasheet of the DAC8568 are in my python code below.

I have the package wired to the raspberry Pi with the 3.3V supply, the 5V supply (needed for LEDs), and ground. The DACs SCLK goes to Pi SCLK, DAC /SYNC (which is really chip select) goes to Pi CE1, DAC /LDAC goes to Pi Gnd, and DAC MOSI goes to Pi MOSI. I do not wire the DACs /CLR, but I can physically hook it to ground to reset the chip if I need to.

I believe my wiring is good, because I can light the LEDs with either a python script or from the terminal using: sudo echo -ne "\xXX\xXX\xXX\xXX" > /dev/spidev0.1

I learned the terminal trick from this video: https://www.youtube.com/watch?v=iwzXh2V1SP4

My problem though is that the LEDs are not lighting as I would expect them to according to the data sheet. I should be lighting A, but instead I light B. I should light B but instead I light D, etc. I have tried to make sense of it all and can dim the LEDs and turn on new ones, but never in the way I would really expect it to work according to the datasheet.

Below is my python script. In the comments I mentioned where in the datasheet I am looking for the bits to send. I am very new to working with analog components and am not a EE, so maybe I am not doing the timing correctly, or making some other silly error. Perhaps someone can look at the datasheet and see my error without having to actually have the chip in hand. Thanks for the help!

# -*- coding: utf-8 -*-
"""
Created on Sat Jul  8 16:33:05 2017

@author: pi

for texas instruments BOOST DAC8568
for BOOST schematic showing LEDs http://www.ti.com/tool/boost-dac8568
for DAC8568 datasheet:  http://www.ti.com/product/dac8568
"""


import spidev
import time

spi = spidev.SpiDev()  #create spi object
spi.open(0,1)  #open spi port 0, device (CS) 1
#spi.bits_per_word = 8  does not seem to matter
#spi.max_speed_hz = 50000000  #does not seem to matter

#you have to power the DAC, you can write to the buffer and later power on if you like
power_up = spi.xfer2([0x04, 0x00, 0x00, 0xFF]) #p.37 Table11 in datasheet: powers all DACS

voltage_write = spi.xfer2([0x00, 0x0F, 0xFF, 0xFF ]) #p.35 Table11 in datasheet supposed write A--but lights B
voltage_write = spi.xfer2([0x00, 0x1F, 0xFF, 0xFF ]) #supposed write B--but lights D
voltage_write = spi.xfer2([0x00, 0x2F, 0xFF, 0xFF ]) #supposed write C--but lights F
voltage_write = spi.xfer2([0x00, 0x3F, 0xFF, 0xFF ]) #supposed write D--but lights H
voltage_write = spi.xfer2([0x00, 0x4F, 0xFF, 0xFF ]) #supposed write E--but does nothing

spi.close() 

Note for future readers, the power up needs to power on the internal reference which is

power_up = spi.xfer2([0x08, 0x00, 0x00, 0xFF]) #(p.37 datasheet
stovfl
  • 14,998
  • 7
  • 24
  • 51
cuxcrider
  • 125
  • 3
  • 9

1 Answers1

0

Comment: the bits are shifted. ... how ... compensate for the shift or eliminate the shift?

This could be the case, if the SPIDIV.mode is not in sync with the DAC.

DAC Datasheet Page 6/7:
This input is the frame synchronization signal for the input data.
When SYNC goes low, it enables the input shiftregister, and data are sampled on subsequent SYNC falling clock edges.
The DAC output updates following the 32nd clock.

Reference: Clock polarity and phase

According to the above and the Timing Diagram I come to the conclusion that SPDIV.mode == 2 is the right.

  1. Check the actual SPDIV.mode
  2. Change to SPDIV.mode = 2

I can confirm your used Values by reading Table 11 Page 35.
Write to Input Register - DAC Channel X
My Example set Feature Bits = 0

            3         2         1
           10987654321098765432109876543210
           RXXXCCCCAAAADDDDDDDDDDDDDDDDFFFF
A = 32-bit[00000000000011111111111111110000]:0xffff0 ('0x00', '0x0f', '0xff', '0xf0')
            3         2         1
           10987654321098765432109876543210
           RXXXCCCCAAAADDDDDDDDDDDDDDDDFFFF
B = 32-bit[00000000000111111111111111110000]:0x1ffff0 ('0x00', '0x1f', '0xff', '0xf0')

Page 33: DB31(MSB) is the first bit that is loaded into the DAC shift register and must be always set to '0'.

The wireing seems straight forward and simple, but worth to doublecheck.

Code Snippet from testing:

def writeDAC(command, address, data, feature=0x0):
    address = ord(address) - ord('A')
    b1 = command
    b2 = address << 4 | data >> 12          # 4 address Bits and 4 MSB data Bits
    b3 = data >> 4                          # middle 8 Bits of data
    b4 = 0xF0 & (data << 4) >> 8 | feature  # 4 data Bits and feature Bits
    voltage_write = spi.xfer2([b1, b2, b3, b4])

# Usage:
# Write Command=0 Channel=B Data=0xFFFF Default Features=0x0
writeDAC(0, 'B', 0xFFFF)
stovfl
  • 14,998
  • 7
  • 24
  • 51
  • Hi stovfl, Thank you for your response. After some more testing I am pretty sure the polarity is correct because I have been setting my feature bits as '1'. If the polarity was switched and reading this in first, then the first bit being a '1' would be the reserved bit for the DAC and cause it to not function according to the datasheet. – cuxcrider Jul 11 '17 at 16:28
  • Also, I can get the 'A' LED to illuminate with 0x00, 0x02, 0xFF, 0xFF. The second byte can actually be 0x02 through 0x07 to light the 'A' LED. At 0x08 I think the B Led turns on but is extremely faint, at 0x09 the B LED is definitely on but very dim, and at 0x0A, then the B LED is pretty bright. Perhaps that information can provide clues as to what is going on? The only thing that seems to make sense is if the bits are shifted. Do you know how I could compensate for the shift or eliminate the shift? Would this be related to the speed of my raspberry pi SPI interface? – cuxcrider Jul 11 '17 at 16:29
  • Hi Stovfl, I tried your for loop but no LEDs turned on. I think .to_byte is for converting integers. – cuxcrider Jul 13 '17 at 04:30
  • Also, I see why you think the bits might be reversed, but I think they are just shifted. For example, if my second byte is 0x07, this represents 0000 0111. If this were reversed it would be 1110 0000, which would make the address bits an "invalid code" according to the datasheet. However, when I use x07, the A LED turns on very bright, so I think the DAC is actually reading 0000 111x where x is the bit in my next byte which in this case is a 1. – cuxcrider Jul 13 '17 at 04:34
  • HI Stovfl, My aplogies, in your for loop, 0x0007ffff will light A, but with 0x0008ffff, the B LED will turn on very dimly. With 0x000Affff, the B LED is pretty bright. So I believe this is the same functionality I see in my code. But this is 0000 0000 0000 1010 ...1111 meaning all address bits are 0 and the A LED should come on and not the B LED. If the bits are shifted one place to the left, then it is 0000 0000 0001 0101 .... and now the B address is 1. I fully admit my understanding of how the bits are fed into the register is very shaky, so I hope my logic here makes sense. – cuxcrider Jul 13 '17 at 05:08
  • 1
    Hi Stovfl, got it! spi.mode = 2 makes everything work. Thanks for the help! Also, of note for future readers in my original question code, the power up needs to power on the internal reference which is power_up = spi.xfer2([0x08, 0x00, 0x00, 0xFF]) (p.37 datasheet). I was just "lucky" that the bits were shifting due to incorrect clock phase in my original post. – cuxcrider Jul 13 '17 at 13:28