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, 12:38:55 pm
Let's say I don't need to read anything from the SPI bus.  Would it be more efficient and possible to do this?

Code:
byte SPIClass::transfer(byte _data) {
  while (!(SPSR & _BV(SPIF))); // Wait for previous transfer, if any, to complete.
  SPSR = SPSR & !_BV(SPIF); // Set SPIF bit in SPSR register to 0.
  SPDR = _data; // Begin transfer of next byte.
}

The idea here is that since I can do other things while I'm waiting for the transfer to complete, why sit around waiting for that to happen?  By the time I go to transfer another byte the transfer will probably have completed, but if not, the function will wait.  And in general even if it did have to wait, it would waste less time than it would if every time I initiated a transfer I waited for it to finish.

What do ya think?  

(I'm not sure if it's okay to just reset the SPIF bit like that.)
1007  Forum 2005-2010 (read only) / Interfacing / Re: Any advantage to running SPI interface faster? on: October 12, 2010, 07:56:52 am
Quote
_BV = Bit Value, a macro I think that will eveluate to 1000000 or bit 7 which is the location of the SPIF flag.

So the code is ANDing the SPSR reg with 1000000, if the result is 0 then the flag is not set and therefore the byte has not been fully transmitted.

Hm...

Quote
while (!(SPSR & _BV(SPIF))) ;

So SPSR is a register, and _BV(SPIF) is a macro which converts the constant SPIF into the binary balue 1000000.  Presumably the value of SPIF is either 6 or 7.

And the SPIF bit does this:

Quote
• Bit 7 – SPIF: SPI Interrupt Flag
When a serial transfer is complete, the SPIF Flag is set. An interrupt is generated if SPIE in
SPCR is set and global interrupts are enabled. If SS is an input and is driven low when the SPI is
in Master mode, this will also set the SPIF Flag. SPIF is cleared by hardware when executing the
corresponding interrupt handling vector. Alternatively, the SPIF bit is cleared by first reading the
SPI Status Register with SPIF set, then accessing the SPI Data Register (SPDR).

So somehow... in the cpu, that SPIF bit is cleared for me by the act of checking to see if the bit is set, and the act of returning SPDR from the function.

Oy.  


So many acronyms.  Why can't there be some kind of identifier in these register names so I know when I'm looking at a register or a constant? smiley-sad
1008  Forum 2005-2010 (read only) / Interfacing / Re: Any advantage to running SPI interface faster? on: October 12, 2010, 07:45:12 am
Quote
Not hard to conceptualize really. Say the pulse that writes data into SPDR also clocks a FF that releases a counter and gates a clock through to a shift reg. The timer allows 8 clock pulses to the SR then resets the FF which stops the SR and counter.

Uh...  Makes perfect sense now!

I'll just accept that it works. :-)

(What's an FF?)
1009  Forum 2005-2010 (read only) / Interfacing / Re: Any advantage to running SPI interface faster? on: October 12, 2010, 06:59:01 am
Hm.  Reading the AtMega datasheet....

Quote
The SPI Data Register is a read/write register used for data transfer between the Register File
and the SPI Shift Register. Writing to the register initiates data transmission. Reading the register
causes the Shift Register Receive buffer to be read.

What?  Simply looking at the data register or writing a value to it causes some action to be taken?  No command beyond simply writing the data needs to be given to the processor to cause it to take this action?

I always thought of registers just as little fast access memory locations on the CPU.  I don't think I ever encountered a situation when I was working with them on a PC where writing one alone could cause something to happen.
1010  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?
1011  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.
1012  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.
1013  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?
1014  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?
1015  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?
1016  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.
1017  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
1018  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.)
1019  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.
1020  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.
Pages: 1 ... 66 67 [68] 69 70 ... 91