Show Posts
Pages: 1 ... 66 67 [68] 69 70 ... 92
1006  Forum 2005-2010 (read only) / Interfacing / Re: Servos vibrate when I stick a resistor on them? on: October 13, 2010, 05:47:18 pm
I do also have a 47uf electrolytic across the + - rails between the servos and the microcontroller, and a .1uf ceramic near the ATMega pins but I'm pretty sure I added the 47uf after I had the vibration problem.
1007  Forum 2005-2010 (read only) / Interfacing / Re: Servos vibrate when I stick a resistor on them? on: October 13, 2010, 05:45:10 pm
I'm using the mic29150:
http://www.micrel.com/_PDF/mic29150.pdf

And I have the reccomended 10uf electrolytic on the output and a 0.1uf ceramic on the input.
1008  Forum 2005-2010 (read only) / Interfacing / Servos vibrate when I stick a resistor on them? on: October 13, 2010, 05:27:14 pm
So in my quest to get more out of a 9v battery when trying to power two servos and a ton of LEDs, I bought a new very LDO voltage regulator, and some resistors which could handle up to 1 or 2 watts so I could supply around 300mA or so to each servo, and no more.

The voltage regulator worked great, and I'm getting like 3x the life out of the battery that I was with the LM317 I was using.  This new one has a dropout of like 0.35v, though it still seems like it might be more than that, since my circuit goes kaput when the battery reads 7v when unconnected to the circuit.

But the resistors worked terribly.  Even with the highest wattage resistor with the lowest resistance... just 15 ohms... when I stick one on each positive power lead to the servos, the servos buzz like crazy.  They move just fine... but they buzz even when stationary.

The servos work just fine even when the battery is almost down to 7v, but as soon as I stick those resistors on there, even with a fresh battery, I get the buzz.

Any idea what might be causing that?  

I mean if i stick a 15 ohm resistor on a 5v power source, I get 333mA out the other side, don't I?  I'm pretty sure servos only need around 25mA when idle, and 100mA when moving but not loaded, as is the case here.

So what gives?
1009  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.)
1010  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
1011  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?)
1012  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.
1013  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?
1014  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.
1015  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.
1016  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?
1017  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?
1018  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?
1019  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.
1020  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
Pages: 1 ... 66 67 [68] 69 70 ... 92