| Electronics > Projects, Designs, and Technical Stuff |
| Borderlands style jewelry box research thread |
| << < (10/17) > >> |
| Youkai:
Ok that is way over my head. Do you have any links to examples that do that? Or keywords i can search to learn how? Also correct me if I'm wrong but communication with the servo only happens when I issue a command to change position right? And once that command is complete there is no more communication with the servo. So as long as i don't try to change the LED color for a short time after moving the servos there shouldn't be an issue. Is that correct? |
| Ian.M:
Once you activate a servo on a pin with servo.attach(pin), the servo ISR continues pulsing that pin even when you aren't moving the servo. If you stop it, one of four things may happen, depending on the servo - it may stay where it is, or power down, or drive to a preset 'safe' position, or drive to either limit. Unless you know what the servo is specified to do on loss of signal, and that's power down or hold position, it isn't safe to use servo.detach(). Most Arduinos will use Timer 1 for the servo library (see ServoTimers.h in the library for exceptions). In Servo.cpp: --- Code: ---#define usToTicks(_us) (( clockCyclesPerMicrosecond()* _us) / 8) // converts microseconds to tick (assumes prescale of 8) // 12 Aug 2009 --- End code --- defines the relationship between timer ticks and us. In Servo.h: --- Code: ---#define MIN_PULSE_WIDTH 544 // the shortest pulse sent to a servo #define MAX_PULSE_WIDTH 2400 // the longest pulse sent to a servo #define DEFAULT_PULSE_WIDTH 1500 // default pulse width when servo is attached #define REFRESH_INTERVAL 20000 // minumim time to refresh servos in microseconds --- End code --- gives the limits for one servo pulse, and the total frame length. The servo library outputs pulses to its active channels consecutively during the servo frame. Therefore if you are controlling three servos, there's a gap between approx 7.2ms and 20ms in the servo frame where you can be certain no servo pulses are being output. That's when you need to update the neopixel string(s). As usToTicks() is private in the Servo lib, you need a copy of its definition in your sketch, then you can simply do --- Code: ---while(TCNT1<=usToTicks(8192)){}; pixels.show(); --- End code --- which waits for the gap in the servo frame before updating the neopixels. For 16 RGBW neopixels, show() has 512 bits of data to send, which will take approx 0.7us @800KHz pixel clock. N.B. you can daisy-chain the neopixel strips by connecting DIN to DOUT, so you'll only need one I/O and one call to the show() method for all the neopixels. |
| Youkai:
I see. Thanks for the great info Ian.M. I'll do some testing with that in the near future. I know I can chain the LED together but I wasn't planning on it because they are kind of in opposite directions from where the micro-controller will be. I guess it wouldn't be too far out of the way to chain them. Is one call to show() less than half the time of two calls? I'm only calling it once but I'm sending twice the data correct? Also my schematic is MUCH simpler now. The new LED run on 5V so that takes out the transistors and the buck converter. Here is the new schematic. Wire colors don't mean anything other than Yellow=Positive and Black=Negative. I think it still needs a little work. According to the notes on the Adafruit site I need to have a capacitor in there for the LED's. Need to do a little more research. |
| Ian.M:
There's a small overhead in show() for setting up the transfer and the reset gap that latches in the data, so one show() would be ever so slightly faster, but if its physically inconvenience to daisychain them, there's no reason not to put them on separate pins then: --- Code: ---while(TCNT1<=usToTicks(8192)){}; // Wait till no servo pulses pixels1.show(); pixels2.show(); --- End code --- You definitely need a *lot* of bulk decoupling capacitance for the Neopixels and the servos. Unfortunately the USB standard calls for a maximum of 10uF on Vbus in a device, which is far too low for running servos on the same 5V rail as a MCU, and if you exceed the 10uF permitted by the standard significantly, you'll have problems with USB over-current at plug-in, or erosion of the connector contacts due to sparking. It would therefore be preferable to keep the buck converter and power it all from a higher voltage. The Arduino would use its onboard regulator and the servos and Neopixels would be fed by the buck converter. The seperate servo/neopixel +5V and Arduino +5v prevents servo noise crashing the Arduino. Also, it could be programmed via USB with just the Arduino powered, and there'd no USB excessive inrush current problem. You'd use an I/O pin to detect if the buck converter is outputting 5V so that the code would only enable the Neopixels and servos if they are powered. N.B. Adafruit recommend a 470R resistor in series with DIN between the Arduino and the Neopixels to prevent damage to DIN due to transients on the data line. If you don't want dead Neopiexls fit the resistors! Also, similar resistors in the servo control lines would be advisable. |
| Youkai:
Ok cool beans. I'll update my schema to include the buck again and add the other stuff. I'll obviously power the Pro Micro from USB while programming it but it's going to be powered by the buck converter in live use. That shouldn't be a problem right? The "RAW" input on the Pro Micro has some kind of regulation on it I believe. Do I just put one capacitor across the two output lines of the Buck converter; before any connections to any powered device? |
| Navigation |
| Message Index |
| Next page |
| Previous page |