To save a pin, and just because it's a more elegant solution, I'd like to connect the same three pins to both chips, and use another two pins to select the chip I want to interface with.
For the shift register I have the following pins:
SER IN = data
SRCK = clock
RCK = latch
And the equivalent pins on the dac are:
SDI = data
SCK = clock
LDAC = latch
Then the dac has the pin CS for chip select, which is active low, and pulling it down enables the chip.
But which pin on the shift register should I pull low to enable it instead? The datasheet is confusingly written. I thought maybe G was the right pin to pull down, but now reading it again, it says when G is held high, all drain outputs are off. I don't want the leds connected to the shift register to turn off when I am talking to the DAC. So maybe the pin I want to pull down is actually SRCLR?
Hm... Then what if instead of using chip select lines, I leave both chips enabled all the time, and simply run one clock pin to each?
Hm... no that wouldn't work. I have to latch the chips at some point, and a single latch line would latch both.
If I could write all the bits to one, and then all the bits to the other, then latch them... that could work... IF I needed to latch both chips at the same time every time. Unfortunately, in my case I need to write a dac a lot more than the shift register.
So then what if I had a unique clock and latch pin for each IC, but shared the data pin?
That would take five pins. Which incidentally is the same number of pins as it would take if I went the other route and used chip select pins... Hm...
The DAC itself requires 16bits, so I'd have to write 24 bits.
I'm not sure if the shift register can handle data being fed to it at the same speed I'll need to feed the dac.
I'm concerned about the Arduino's ability to send data fast enough to the dac as it is. I need a sampling rate of around 30-44Khz. Adding another eight bits on top of the 16 I already have to send at that rate may eat up any processor time I have remaining.
the G not input should be held high that is supposed to turn off the outputs, that should be the same as tri-state but the ti datasheet does not state that.
The 74SN595N does state that it will set the outputs to high impedance
Looking at the datasheets seems to show that they both go high impudence but I am guessing since TI's datasheets are inconsistent.
The SR can shift at about 25MHz, I'm pretty sure it will keep up
Only you can decide this because you know what else the code has to do, but if you're using the SPI hardware there's almost 0 overhead in shifting bits out at 4MHz so it shouldn't affect your code much.
Anyway it's worth a try.
Rob
EDIT: Looks like the SR can shift at about 12.5MHz.
Ah crap... I may have to use the SPI hardware. I decided to look that up and a page I found indicates shiftout() can only output data at like 8Khz. But using the hardware is something like 15 times faster.
The info I'm funding is confusing though. It mentions pin 13 is clock, 12 is input, and 11 is output, but if output is data, and clock is clock, then is input the latch?
Is there a lib or good tutorial on using hardware SPI? I gotta get this stuff working in the next few days.
My shift register isn't using an SPI interface, is it? The dac does though.
My confusion arose because the wave shield shematics show the dac having a clock, data, and latch just like the shift register.
But it seems like the dac only needs two pins to communicate via SPI... because it doesn't need to send data back to the Arduino. So pin 12 on the Arduino doesn't need to be connected to anything.
And the LDAC pin on the dac... that's a latch of some kind, but it seems like it's used for the 16 pin dual dac form factors of the dac in question? I can't tell if it's needed for the smaller single dac chip I'm using.
But it seems like the dac only needs two pins to communicate via SPI... because it doesn't need to send data back to the Arduino. So pin 12 on the Arduino doesn't need to be connected to anything.
True, you don't have to use MISO.
I can't tell if it's needed for the smaller single dac chip I'm using.
The single version still has an LDAC pin, so yes it would be needed.
Unfortunately LDAC is an active LOW latch enable so you can't just hook it up to SS on the SPI interface as SS will go low for the entire frame. You can with the SR because it's a rising-edge clock, but not the DAC.
You need to organise a low pulse (min 100nS) on the rising edge of SS and feed that to LDAC.
It would seem from the datasheet that the proper procedure is to stick a 10K pulldown on LDAC, and connect the chip select, data, and clock pins to the Arduino for the SPI interface. Specifically to pin 13 for the clock, 11 for the data, and 10 for the chip select, as those are the only pins you can do hardware SPI with. (Unless you're using a mega, then you use different pins.)
common clock line
common data line
shift register latch
DAC latch
DAC chip select
You'll have to be a little careful about order of operations, but it should work, since both chips will ignore and/or dump the data they get when they're not specifically selected or latched.
I think I'm just gonna keep things simple and use six pins. I have the pins to spare.
My major concern at the moment is that it seems I may not be able to use hardware SPI to interface with this dac at all because I think it expects 16 bits before the CS pin goes high again:
Well after looking at the datasheet and examples, and the SPI library functions... I think maybe the posts I read about the SPI only being able to send 8 bits at a time before it triggers the CS pin are wrong.
It would seem that one must trigger the CS pin themselves, setting it low to indicate the start of the bitstream, and then high again once the bitstream has been completed. Neither the SPI library nor the SPI hardware it interfaces with appears to touch the CS pin.
I'm at a loss as to why it's even defined as being pin 10, or why there are posts about being unable to interface with 16 bit devices without bit banging, but the datasheet and examples seem to indicate it should not be an issue.
I suppose I'll find out tomorrow when I rig up a test circuit and try to output some simple tones.
AFAIK it's up to the program to toggle SS, there's no other practical way to do it because the SPI hardware can't know how many bytes you want to send.
If the SPI library toggles for each byte then you can't use it, or you can use it but implement you own SS and leave the normal one (pin 10?) unconnected.
