1
\$\begingroup\$

I need to send a command to multiple I2C devices on the same wire. The devices are OpenServos. Each device get's it command and begins processing the information in the command.

How do I ensure that they all start processing the command at the same time?

EDIT: Just to clarify, this question is mainly about I2C's ability to support syncing.

\$\endgroup\$
  • 2
    \$\begingroup\$ Isn't there a broadcast address for I2C devices? \$\endgroup\$ – Connor Wolf Oct 30 '11 at 13:33
  • \$\begingroup\$ @FakeName, yeah it looks like there is: nxp.com/documents/user_manual/UM10204.pdf Support for the "general call" address is optional for the device. Laid out in the spec for general call are: address change with reset, address change without reset, and software reset. I suppose it is possible to add a custom command and use(/abuse) the general call for your own purposes. Editing answer to include information... \$\endgroup\$ – Jon L Oct 31 '11 at 22:07
2
\$\begingroup\$

A few possibilities come to mind:

  1. Have an I2C Master device dedicated for each servo (a microcontroller for example) and a single microcontroller dedicated for generating a synchronization signal which will go to each of the I2C Masters.

  2. If possible, configure all the servos to have the same I2C address. They will all receive the command at the same time thinking that it is for them. Absolutely will not work if each motor needs its own parameters - only if they are to receive the exact same identical commands. Possible issues: multiple devices trying to drive the line during ACK or during a reply may cause unpredictable bus contention. Might be worth a try though if they're all going to receive identical commands.

A quick look at the OpenServo page tells me that these devices are re-programmable and you can write your own firmware. It sounds like to me that plain I2C may not be the best choice here considering your synchronization problem and there may be an opportunity to do something clever by modifying the motor controller firmware to accept an additional 'sync' signal.

EDIT: Fake Name mentions a broadcast address in I2C and this may be hacked to your advantage. The official I2C Specification supports a "general call" address which is optional for the device. Laid out in the spec for general call are: address change with reset, address change without reset, and software reset. I suppose it is possible to modify the firmware to support a custom command and use(/abuse) the general call for your own purposes.

\$\endgroup\$
  • \$\begingroup\$ I thought so. Documentation never states the limitations of the technology :( SPI at least has a sync feature built into the thing. So the only way to do that would be to send a sync command by programming the firmware. Thanks. \$\endgroup\$ – user3045 Oct 28 '11 at 22:22
  • \$\begingroup\$ This is certainly not a limitation of the technology. This is an open source project. If it needs a feature add it, or persuade somebody to add it for you. Its preferable that the documentation dos NOT tell you all the things it can't yet do as nobody can tell which of a very very long list of inabilities will prove useful enough to be added. \$\endgroup\$ – Russell McMahon Oct 29 '11 at 9:24
  • \$\begingroup\$ This is certainly not a limitation of the technology. This is an open source project. If it needs a feature add it, or persuade somebody to add it for you. Its preferable that the documentation dos NOT tell you all the things it can't yet do as nobody can tell which of a very very long list of inabilities will prove useful enough to be added. \$\endgroup\$ – Russell McMahon Oct 29 '11 at 9:24
  • \$\begingroup\$ I don't think having the devices all ack will be a problem - I2C is open-collector, and clock-stretching is permitted, so the master will simply wait for the last device to finish acking. A third option would be to run a 'sync' line to each servo, and only apply changes when that line goes high. \$\endgroup\$ – Nick Johnson Nov 1 '11 at 6:14
  • \$\begingroup\$ @NickJohnson, perhaps it wasn't clear but that's what I implied with "...modifying the motor controller firmware to accept an additional 'sync' signal." \$\endgroup\$ – Jon L Nov 1 '11 at 6:30
0
\$\begingroup\$

Terms like OpenServo should be explained in questions and links should be provided to relevant websites.

Some details and links to OpenServo resources are provided below.

There are two obvious ways of achieving simultaneous starting of multiple servos. There will be other ways.

  • As OpenServo is open source and processor based it would be "easy" to add non standard features. One such method which should be achievable with a minimum of modification of the system would be to allow all servos to listen for a common I^2C address and implement "All stop" and "All start" signals which can be decoded by all connected servos. Commands for an individual servo received during "all stop" are quesd and implemented immediately after an "all start: is received. So -
  • Send All Stop signal.
  • Send codes to each connected servos.
  • Send Y'All start now

    - Hardware control.

The SparkFun Openservo circuit diagram eferenced below uses the H bridge driver shon below. If the +12V feed at top centre is interupted the servo will not drive. If this feed point is common to a group of servos, all may be turned on and off with ease with a single "switch" (probably a high side P Channel MOSFET.

enter image description here

OpenServo is an open community-based project with the goal of creating a high quality digital servo for robotics. They say

  • Some of the many features of the OpenServo include:

    -High performance AVR 8-bit microcontroller
    -Compact H-Bridge with high performance MOSFETs
    -Precision control over servo position and speed
    -I2C/TWI based interface for control and feedback
    -Feedback of position, speed, voltage and power
    -Advanced curve based motion profile support
    -EEPROM storage of servo configuration information
    -Software written in C using free development tools
    -I2C/TWI bootloader and GUI programmer

Documentation page
SparkFun index page
Circuit of sparkFun implementation.

\$\endgroup\$
  • \$\begingroup\$ Yes, I agree that terms should be explained. However the question was about I2C's ability to do syncing. Good answer though. \$\endgroup\$ – user3045 Oct 31 '11 at 21:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy