OpenServo.com

[kbb]

[ginge]

[kbb]

[ginge]

I am on the fence with connectors. I would probably put my own on there if we decided that it was going to connectorless.

My STK600 arrived today. It looks like I went crazy with the quantity of the STK600-RC044X-15 adapter board and ordered 4 of them. If anyone wants one let me know.

I also took delivery of the D4 chips, and after speaking to Farnell, it looks like we should get the A4 chips next week. It also seems like the TQFP adapter socket shim is not arriving until next week. For now I am playing the supplied mega2560 until the socket arrives.
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/

[kbb]

About duplicating bus types on the host connector

It is difficult to know whether to put this in “Hardware”, or “Software”, but in regards to the wish for more than one of each port on the host connector. I am wondering what the main aim is? Especially in regards of SPI. For host comms, surely one is enough? A second serial port as somekind of OpenServo "debug port" maybe.

Host comms

I2C/TWI is an already well defined protocol.

So by way of an example, here is a very simplified view of using a single serial port for communications between OpenServo devices and the host.

Serial, one port - example 1: ring based

Here is a _very simple_ example for the purpose of outlining how it might be implemented.

The host and devices are cabled up so that the host transmits to a device; this device transmits to another and so on, until finally the last device in the ring transmits back to the host. A packet based protocol might be used. For example:

START, device-address, command, [data0, ...dataN], CHECKSUM, END

If a device has seen START but the address is not it’s own, then it sends START and the address to the device to which it is connected (which is the host if it is the last one in the link, it does not know), and then relays all the following bytes it sees, immediately, until END is encountered.

If the address is it’s address, then it sends nothing to the next device until after the END is seen. It responds in what ever way is appropriate to what it has received. This may include sending something to the host (by transmitting it to whatever it is attached, which, if it is a device will merely forward it on).

Once END has been seen, the process starts again from the next time a START is seen.

So, for example, let the host be address 0, there are 3 devices (1, 2 and 3). The order in which the devices are wired up does not matter, but for the purpose of exampling this example we will assume it is address order. So, the host sends a command to read the position from device 2:

Device1 sees: "START, 2, READPOS, CRC, END". So this will be sent to the cabled up next device.
Device2 sees: "START, 2, READPOS, CRC, END". So this will never be sent to the next device.
After the END, device2 responds by sending "START, 0, MYPOSITIONIS, data0, data1, CRC, END" to device 3.
Device3 sees that the packet is not for it, so it transmits everything as-is to the next device (which unbeknown to it is the host).

The host has got its answer and an acknowledgement that what it sent was received.

There is a small latency here, but nothing to worry about. The main disadvantage is that if a device “dies” the host cannot talk to any of them: on the other hand, a breakage probably ruins the game anyway, and the same thing can happen with I2C and many other protocols.

Serial, one port - example 2: "multi-drop"

I’ll skimp on some of the details again.

The TX from the host is connected to RX on all devices, TX of all devices is connected to RX on the host. All devices listen all the time, but "only one speaks at any one time". All devices keep their TX pins at high impedance whilst they’re not talking. Other than that this is just a different off-board wiring strategy.

A very simple example again: Using the same packet structure as the other example to keep things sane, but this time the devices do not relay what they see and the host does not send the END until it has received an acknowledgement (or times out). So for example (using the same example as above).

All devices see: "START, 2, READPOS, CRC"
All devices but device 2 “ignore” the request. When device 2 sees the CRC, it enables its TX pin and transmits "START, 0, MYPOSITIONIS, data0, data1, CRC, END" and then disables its TX pin again.

The host accepts the MYPOSITIONIS is as an acknowledgement and sends the END. All devices now wait for the next START.

The main disadvantage is providing (if needed) some form of protection in case two devices enable their TX pins at the same time (i.e. one ground, one high) - it possibly depends on what the ATxmega series of processors have in the way of protection (if anything). As with any other bus, if one of the devices dies it may block the bus.

Finally

It is worth mentioning that all devices have to monitor the traffic to know what is what.

Assuming asynchronous serial, both examples can be achieved using just two pins and ground. An additional pin could be added for some more control (for example: a “bus reset”).

Advantages of using a serial link over I2C: it might be faster (depends on...), it is more accessible (it is much easier to hook up and program for a serial link, especially if you have never used I2C/SPI).

Clearly I left out some of the finder details: including things that make it better and a little more advanced. The “multi-drop” method might benefit from an extra control pin.

SPI may be faster, but over a long length of cable? Using the SPI bus is also somewhat more complicated.

[kbb]

[jharvey]

Would it be possible to include a "1wire" bus or similar technology? Such that you simply give it power lines and the data bus is on that connection. There are some interested projects about it here.

http://owfs.org/

I see the wikipedai notes a parallel port running at 100kbits/s can make the signals for this bus. Perhaps that's an approximate through put of this bus. Not exactly sure how fast (or slow) it is. I also see a note of 100m bus length, so I suspect our short runs are just fine with this bus.

[ginge]

Ok,

let's boil this down then...

* Hirose connector: It stays
* Power: Leave power on the Hirose. Add additional solder pads for connecting power to the "bus bars"
* Twisted Pair with matching grounds: If we can, yes.
* SPI: Why do we need SPI at all? I am still not sure where this request came in, and if it is relevant. Personally I don't want to see it on the host connector if it means we lose something else (PDI)
* PDI: I think this is important, if only for sanity during development.
* Exposed Busses: Serial, two is nice but a ring or multidrop is fine by me. How does the dynamixel stuff implement serial? I2C is a must (or course).

Personally I am only interested in making OpenServo serial and i2c compatible. So, I think the host connector should have:

PDI
SERIAL
I2C
1x GPIO

obviously some pin overlap is going to occur here, but at first glance it looks feasible. It isn't like we are going to use more than one protocol at a time. Kbb?

Something else occurred to me. People were asking for a 3.3v input pin on the host connector. Did we decide that because of the larger diffference between servo and mcu voltage that it no longer matters? When we converted v3 to 3.3v it made a positive difference to the stability but added more noise. We can combat noise in our xmega filtering circuits.

As for One Wire... there is no hardware support, but it doesnt stop you writing a bit bang interface to talk to the host. OWi is a pretty simple protocol, and quick to implement. Personally it doesn't really fit into anything I need to do with the OpenServo, but I would certainly add it to the CVS if someone wrote it. There is no reason why you couldn't also write it for the v3, v2 or v1 OpenServo.


EDIT:

forgot to mention my STK600 arrived yesterday and I have some basic TWI and PWM code running. Now to discuss ADC in the software thread!
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/

[kbb]

[kbb]

[jharvey]

[ginge]

[kbb]

[ginge]

Yeah I see your point of view here, but how are we going to flash them?
Assume I just got 2000 in box box, pre assembled but no bootstrap. I don't want to have to solder anything on to the board in order to first time bootstrap them.
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/

[kbb]