Serial protocol

[Miamicanes]

Suppose a controller I've made based on an Atmel Mega168 has just transmitted a valid datagram to the Dynamixel serial bus that's supposed to return a response. How long MUST I wait for that response after the final bit of the checksum byte has been transmitted before I can legitimately assume that something went wrong, there isn't going to BE a response, and I should go ahead and handle it as a communications error?

Likewise, after I've received all the bytes of a response datagram and validated the final checksum byte, how long MUST I wait before I can legitimately send the first byte of the next datagram?

Also, is the parse strategy followed by the AX12's controller defined for ambiguous situations where a valid datagram (header to checksum) is found IN THE MIDDLE of what's allegedly an even longer datagram? For example, take the following sequence of bytes:

0xff 0xff 0xfe 0xf0 0x69
0xff 0xff 0x04 0x03 0x01 0x??
(timeout)

... with no pause between the first and second group. Humor me for a moment and pretend the second line is the proper datagram for "ping device #4", even though I probably butchered the length and/or checksum values

WOULD device #4 even interpret the ping datagram? Or, upon realizing it was told to expect 0xf0 bytes and timed out before then, would it dump the entire buffer as invalid? Would it simply dump everything up to the NEXT 0xff 0xff... sequence it found in the buffer (line 2), then parse it again? Would it even HAVE to time out, or would it realize it had a valid datagram on its hands (addressed to it, proper length, valid checksum) by virtue of recursively parsing the entire buffer after each and every new byte were appended to the end?

Also, if someone could refresh my memory (it's been about 7 months since the last time I worked on this), if I send the following bytes:

0xff, 0xff, 0xfe, 0x??, (20 bytes... command byte, 18 arg bytes, checksum byte

would 0x?? be 0x14, 0x15, 0x16, or 0x18?

does the checksum include the value of the length byte? the id byte? the two leading 0xff bytes?

Thanks

[JonHylands]

Suppose a controller I've made based on an Atmel Mega168 has just transmitted a valid datagram to the Dynamixel serial bus that's supposed to return a response. How long MUST I wait for that response after the final bit of the checksum byte has been transmitted before I can legitimately assume that something went wrong, there isn't going to BE a response, and I should go ahead and handle it as a communications error?

I generally set my response timeout at 20 ms. It really depends on how much potential latency there is between the master and the bus. If you're using an ATmega168 directly on the bus, there should be no latency, so probably 5-10 ms would suffice.

Likewise, after I've received all the bytes of a response datagram and validated the final checksum byte, how long MUST I wait before I can legitimately send the first byte of the next datagram?

I generally wait a couple ms in that case.

Also, is the parse strategy followed by the AX12's controller defined for ambiguous situations where a valid datagram (header to checksum) is found IN THE MIDDLE of what's allegedly an even longer datagram? For example, take the following sequence of bytes:

0xff 0xff 0xfe 0xf0 0x69
0xff 0xff 0x04 0x03 0x01 0x??
(timeout)

... with no pause between the first and second group. Humor me for a moment and pretend the second line is the proper datagram for "ping device #4", even though I probably butchered the length and/or checksum values

WOULD device #4 even interpret the ping datagram? Or, upon realizing it was told to expect 0xf0 bytes and timed out before then, would it dump the entire buffer as invalid? Would it simply dump everything up to the NEXT 0xff 0xff... sequence it found in the buffer (line 2), then parse it again? Would it even HAVE to time out, or would it realize it had a valid datagram on its hands (addressed to it, proper length, valid checksum) by virtue of recursively parsing the entire buffer after each and every new byte were appended to the end?

No idea, sorry.

Also, if someone could refresh my memory (it's been about 7 months since the last time I worked on this), if I send the following bytes:

0xff, 0xff, 0xfe, 0x??, (20 bytes... command byte, 18 arg bytes, checksum byte

would 0x?? be 0x14, 0x15, 0x16, or 0x18?

does the checksum include the value of the length byte? the id byte? the two leading 0xff bytes?

Thanks

The checksum is calculated on everything except the two leading 0xFF's...

- Jon

[StuartL]

Suppose a controller I've made based on an Atmel Mega168 has just transmitted a valid datagram to the Dynamixel serial bus that's supposed to return a response. How long MUST I wait for that response after the final bit of the checksum byte has been transmitted before I can legitimately assume that something went wrong, there isn't going to BE a response, and I should go ahead and handle it as a communications error?

The factory standard turnaround time for the servos is supposed to be 250uS. At a bit rate of 1mbit a single byte will take approx 10uS to transmit. If you got to a millisecond without receiving a single byte I think it's safe to assume something bad happened.

Likewise, after I've received all the bytes of a response datagram and validated the final checksum byte, how long MUST I wait before I can legitimately send the first byte of the next datagram?

I don't know about "must", but we're not actually waiting at all between packets. As soon as we get a valid reply the next packet is retrieved from the buffer and queued for transmission. Turnaround time is probably pretty quick, maybe 8-64 cycles (wild guesses) so we're probably waiting a small number of microseconds before each transmission.

Also, is the parse strategy followed by the AX12's controller defined for ambiguous situations where a valid datagram (header to checksum) is found IN THE MIDDLE of what's allegedly an even longer datagram? For example, take the following sequence of bytes:

0xff 0xff 0xfe 0xf0 0x69
0xff 0xff 0x04 0x03 0x01 0x??
(timeout)

... with no pause between the first and second group. Humor me for a moment and pretend the second line is the proper datagram for "ping device #4", even though I probably butchered the length and/or checksum values

Assuming the AX12 finds the start of the first packet I presume (though it is presumption) that it'll pick up the length and wait/checksum the packet before looking for the next frame-start.

Also, if someone could refresh my memory (it's been about 7 months since the last time I worked on this), if I send the following bytes:

0xff, 0xff, 0xfe, 0x??, (20 bytes... command byte, 18 arg bytes, checksum byte

would 0x?? be 0x14, 0x15, 0x16, or 0x18?

I always remember the length field being the total frame length - 4. i.e. Payload length, not frame length.

does the checksum include the value of the length byte? the id byte? the two leading 0xff bytes?

Jon's already picked this one up

[JonHylands]

The factory standard turnaround time for the servos is supposed to be 250uS. At a bit rate of 1mbit a single byte will take approx 10uS to transmit. If you got to a millisecond without receiving a single byte I think it's safe to assume something bad happened.

Actually, that's not quite true. The control table registry defaults to 250, but the actual delay is 2 * value, or 500 us.

However, depending on how you're talking to the bus, there can be far greater sources of latency than that.

- Jon

[MoSin]

when you say "how you're talking to the bus", what do you mean by that jon??

[JonHylands]

when you say "how you're talking to the bus", what do you mean by that jon??

Whether you are connected to the bus from a PC through a USB interface like the one I sell, or through a CM-5 in toss mode, or directly using a micro-controller.

- Jon

[StuartL]

when you say "how you're talking to the bus", what do you mean by that jon??

Whether you are connected to the bus from a PC through a USB interface like the one I sell, or through a CM-5 in toss mode, or directly using a micro-controller.

- Jon

Ok, I'll clarify my previous post:

1) I cocked up on the 250us/500us thing, sorry about that.

2) I was talking about direct from the microcontroller. Certainly if you're sending from a PC via serial through the CM5 in toss mode all bets are off

Thanks to Jon for spotting my error without gloating

[Miamicanes]

Well, in case anyone's wondering, my eventual goal is to design an interface board for the SunSPOT. It's just about the most perfect application for a SunSPOT that you could dream up... they even have almost plug 'n play wireless firmware deployment (connect one SPOT to your PC, and once you get it configured, you can use it to wirelessly deploy new firmware to ANOTHER SPOT). The problem is, the current serial routines aren't quite up to the task of directly communicating with an AX12 at 1mbit/sec, even though the interface board ITSELF is a Mega88. So... here's my tentative plan:

Phase 1:

* Get a Mega168 to successfully send hardwired datagrams to an AX-12 (baby step #1)

* Get it to successfully ping an AX-12 (baby step #2)

* Get it to successfully poll the Bioloid's sensor module (baby step #3)

Phase 2:

* Create an interface board w/Mega168 and CP2103 usb-to-serial interface (from Sparkfun) that buffers a complete datagram, sends it to the AX12 bus at 1mbit/sec, receives the response, and sends it out the CP2103

* Get it to work with the SunSPOT's sensorboard serial.

Phase 3:

* Get it to work via SPI instead of serial. At this point, I'll really, REALLY be wishing I had a SunSPOT protoboard that does nothing but directly expose the ARM9's SPI (I thought about trying to make one, but suspect that I'd never, EVER be able to get the high-density surface mount interboard connector hand-soldered to a PC board because it doesn't look like it would "float" into position via surface tension the way a SOIC or TQFP IC does.)

* port it to the Mega88 interface board Sun sent me a few months ago & I haven't really had a lot of time to play with yet

I actually made a fair amount of headway last summer, but then I got massively sidetracked for a few weeks at work, and spent the last 3 months or so of 2007 working on my string of networked RGB christmas lights

[MoSin]

when you say "how you're talking to the bus", what do you mean by that jon??

Whether you are connected to the bus from a PC through a USB interface like the one I sell, or through a CM-5 in toss mode, or directly using a micro-controller.

- Jon

would there be a huge difference between a ucontroller and the CM-5??