Show Posts
Pages: 1 ... 66 67 [68] 69 70 ... 91
1006  Forum 2005-2010 (read only) / Interfacing / Re: Any advantage to running SPI interface faster? on: October 12, 2010, 06:48:49 am
How does it know to transfer the data after you've put a value into the register though?  

Is _BV(SPIF) a function which transmits a bit at a time?  How does it work?  Where can I find the code or documentation for it?
1007  Forum 2005-2010 (read only) / Interfacing / Re: Any advantage to running SPI interface faster? on: October 11, 2010, 04:28:12 pm
The thing is, I don't have much time to get this working.  I have to finish the design of this circuit by the end of the week.  And I could look at the datasheet all day but in the end all I can do is guess about whether I understand something or not.

For example, the datasheet seems to indicate the SS pin isn't modified when you transfer a byte.  But then there is a diagram of how the data is sent when you initiate a transfer and the SS pin is being shown going high and low.  So which is it?  Is it set high after a single byte is transferred, or not?  The data sheet says it's not, but some posts I've read here says it does, and the digaram indicates it does, so I have no idea what's right.
1008  Forum 2005-2010 (read only) / Interfacing / Re: Any advantage to running SPI interface faster? on: October 11, 2010, 03:45:36 pm
I was referring to the Transfer() function in the SPI library:

Code:
byte SPIClass::transfer(byte _data) {
  SPDR = _data;
  while (!(SPSR & _BV(SPIF)))
    ;
  return SPDR;
}

I don't really understand what that's doing, but since you mentioned registers, maybe SPDR is a register.

It looks like this function does in fact wait for something.  I suspect that is for the transfer to finish, because the documentation for the SPI lib makes no mention of having to wait or check any bits before you attempt the next write.

How might I change this code so it doesn't set the CS bit high after transferring the first byte, so I can transfer a second to my DAC which requires 16 bits in a row?

I guess I'll look at the Arduino datasheet and see if I can find these registers in there.  I'm not sure how I'm supposed to know the constants used for different registers.
1009  Forum 2005-2010 (read only) / Interfacing / Re: Any advantage to running SPI interface faster? on: October 11, 2010, 03:14:29 pm
What happens if you call the function again before the completion flag is set?
1010  Forum 2005-2010 (read only) / Interfacing / Re: Any advantage to running SPI interface faster? on: October 11, 2010, 01:16:42 pm
So when you call the function to send a byte out over hardware SPI, does the function return immediatley, or after the transfer of the byte has completed?
1011  Forum 2005-2010 (read only) / Interfacing / Any advantage to running SPI interface faster? on: October 11, 2010, 11:43:15 am
Let's say I need to send 16 bits of data to a device at 44khz.  That's 704,000 bits per second.  My Arduino is running at 16mhz.  And the default SPI divider is 4.  So the SPI bus by default runs at 4mhz, but I only actually need it to be able to send 1 million bits per second.

Is there any advantage to be gained by slowing the SPI bus down?  Will it use less CPU time?  Or will I use less CPU time by speeding it up?  The chip I'm sending data to can handle data at 20mhz, so I could set the SPI bus to the fastest speed... 16mhz/2...  and the Arduino still couldn't outpace it.

So what should I do?  Speed it up, slow it down, or just leave it as is because changing the speed will have no effect at all on the speed at which my program executes?
1012  Forum 2005-2010 (read only) / Interfacing / Re: Chip select with shift register and dac on: October 11, 2010, 08:09:54 pm
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.
1013  Forum 2005-2010 (read only) / Interfacing / Re: Chip select with shift register and dac on: October 11, 2010, 12:45:28 pm
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:

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1286797300/12#12
1014  Forum 2005-2010 (read only) / Interfacing / Re: Chip select with shift register and dac on: October 11, 2010, 11:05:11 am
See this thread where I was asking specifically about the dac:
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1286797300

Specifically reply #6.

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.)
1015  Forum 2005-2010 (read only) / Interfacing / Re: Chip select with shift register and dac on: October 10, 2010, 06:27:17 pm
Hm... I think I'm confused here.

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.
1016  Forum 2005-2010 (read only) / Interfacing / Re: Chip select with shift register and dac on: October 10, 2010, 05:58:24 pm
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.
1017  Forum 2005-2010 (read only) / Interfacing / Re: Chip select with shift register and dac on: October 10, 2010, 10:22:51 am
The problem with writing 16 bits every time is:

1) The DAC itself requires 16bits, so I'd have to write 24 bits.

2) 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.

3) 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.

But I like the idea...
1018  Forum 2005-2010 (read only) / Interfacing / Re: Chip select with shift register and dac on: October 10, 2010, 09:35:47 am
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...
1019  Forum 2005-2010 (read only) / Interfacing / Chip select with shift register and dac on: October 10, 2010, 05:22:16 am
Hey guys,

I have these two chips I need to interface with:

http://focus.ti.com/lit/ds/symlink/tpic6b595.pdf
http://ww1.microchip.com/downloads/en/DeviceDoc/21897a.pdf

One is a shift register, and one is a dac.  

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?
1020  Forum 2005-2010 (read only) / Interfacing / Re: DAC questions on: October 11, 2010, 12:16:09 pm
Grumpy... I think you might have been mistaken about that capacitor/resistor on the voltage reserence pin that  I asked about.  I just found this on the waveshield page:

http://www.ladyada.net/make/waveshield/design.html

Quote
The DAC also has a Vref input, this is the reference voltage that it uses to define the maximum analog value it can generate. There is a very low low-pass filter connected to it (C6 and R8) so that any digital noise (there is -a lot-) will not make it into the audio signal.

So it is a low pass filter.

[edit]

Well maybe you weren't mistaken.  Maybe I just didn't explain what I was asking well enough.  The wikipedia voltage divider page I linked to showed that type of resisotr capacitor combination and seemed to indicate it was both a voltage divider and low pass filter.  So when you said it wasn't a voltage divider, I assumed you meant it also wasn't a low pass filter.

I guess though that those tiny bypass caps must be low pass filters.  But I haven't seen them used with resistors like that before... :/
Pages: 1 ... 66 67 [68] 69 70 ... 91