Minimal multi-drop serial protocol for motor controllors and sensors.

Brian Dean wrote:


I'm following this. As long as they check with me at my normal email rather than my work email.
I could live with a 16-bit checksum if that is the concensus, but I think an 8-bit one works fine for our needs. -- D. Jay Newman http://enerd.ws/robots /
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
D. Jay Newman wrote:

Assuming a multi-master mode rather than "speak only when spoken to", you have a high likelihood of packet collisions. Considering the possible damage that could be caused by suddenly reversing an h-bridge for example, I'd want confidence that more than one collision in 256 would yield erroneous data that would be acted on - on a busy network this could be one erroneously-accepted packet per second(!)...
I implemented the Dallas/Maxim crc16 in C code for the MSP430. The code is four lines long, and uses lookups in two 256-byte tables. There really isn't a good enough reason not to use a safe checksum. I'll be happy to provide this code for any purpose.
Just for reference and in case you want to check the compiled code size on your architecture, here it is (see Dallas appnote 27):
typedef struct { unsigned char lo, hi; } CRC16T; extern const unsigned char crc16_tablo[256]; extern const unsigned char crc16_tabhi[256];
void CRC16Byte(CRC16T* crc, unsigned char byte) { byte ^= crc->lo;
crc->lo = crc16_tablo[byte] ^ crc->hi; crc->hi = crc16_tabhi[byte]; }
void CRC16(CRC16T* crc, const unsigned char* block, int len) { while (--len >= 0) CRC16Byte(crc, *block++); }
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Wed, 20 Oct 2004 15:12:30 +1000, Clifford Heath wrote:

I think the rub here is the 2 256 byte tables, not the program space. Stored in flash, this would probably be OK, but if these need to go into RAM (for performance, perhaps), that's usually a much tighter commodity. The 512 bytes consumes 1/2 of the ATmega8's RAM space. On a larger processor like the ATmega128, that's not a problem, but then you get into the more expensive microcontroller boards being necessary to implement the node. I am very price concious consumer as well as vendor and even my ATmega128 boards cost $85 at the low end with a good feature set. But with ROBIN, I'm shooting for the $10 mark for the chip + PCB board. Add a couple bucks for the transceiver and other necessities. Thus, we're trying hard to make it not so much of an economical burden to add a cheap sensor or simple controller node to your project.
If strong checksums make or break your application, perhaps these could be implemented over the data payload only and be part of the application layer - that way only applications that need that level of error dectection need to worry about taking the hit?
-Brian
--
Brian Dean
http://www.bdmicro.com/
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Brian Dean wrote:

There's absolutely no reason for the table to go into RAM, so this is a non-argument. In fact, the MSP430F1121 where I used this has only 256 bytes - we're talking a chip worth only a buck. I'm totally with you on the cost argument. That's why I want enumeration too, to remove the DIP switch. And if FLASH is tight, the CRC can use a loop and chew more cycles instead.
Re enumeration, all that's required is to store a unit serial# (say 64 bits as in One-Wire), and if no address has been assigned, to respond with an ACK to a query containing a bit-string of length 0-64 if the specified bits match the serial#. The query has an additional bit indicating that it contains an address assignment (for when enumeration is complete). The whole client code should be under 100 bytes, and one byte of RAM for the assigned address - surely worth it to remove the DIP switches.
Then the smarts are all in the controller board, which sends pairs of queries starting with a single bit. Any response, even a framing error, says that someone has that prefix and the controller should try again with each value (0, 1) of the next bit. Since devices having assigned addresses needn't respond, hot-plugging can be supported by a single pair of packet probes every so often (no need for a full enumerate). It's absolutely straight-forward once you see how it's done. It seems I'll have to implement it to prove the point however :-).
Re Arcnet, it seems to regard RS422/485 as point-to-point standards. If you want to investigate Arcnet without buying the standard, there's a Linux Arcnet driver, <http://www.worldvisions.ca/~apenwarr/arcnet/ . It seems not to address RS422/485 at all however.
Clifford Heath.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Brian Dean wrote:

Thank you Brian. I would have posted pretty much the same thing if you hadn't already done so.
I'd go as far as a 16 bit checksum, but I think anything larger is overkill for ROBIN.
As you stated, encapsulate a more complex command set in the data section and put a CRC in there if it is needed by an application. -- D. Jay Newman
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Just a couple of points.
I really do not think enumeration is critical. It is great when unknown agents install unknown hardware, but why not keep things simple?
The issue of checksums came up. Personally I think that is something that should be part of a specialized implementation. Once I get my lines balenced, I almost never see bad checksums. Make a bigger checksum as part of the data, but keep the ROBIN standard the same in my opinion.
In my world, there are a few major enemies. One is feature creep, and the other is code bloat. i like the KISS method.
Mike

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
blueeyedpop wrote:

Enumeration on a parallel bus is hard to do right, although it's certainly possible.
The argument against enumeration is that it adds complexity. The argument for it is that otherwise, you either have to add DIP switches, or you have to program each device offline before installing it.
                John Nagle
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Sing it brother! That's why I like hardware better than software. Most of the time nobody even considers making the bridge a couple of feet longer of adding another lane after it's built, but I've NEVER seen a software application that was complete and had no pending list of enhancements, and rarely one that fit in the space originally estimated and allocated.
When is it going to be done? When IS it going to be done? WHEN IS IT GOING TO BE DONE? By the way, can you also make the light blink when I push the button? ... and we need it to print a report... and can you change the color of the icon when... and When is it going to be DONE?
--Steve
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Wed, 20 Oct 2004 13:59:10 +0000, blueeyedpop wrote:

I think a checksum in the protocol is necessary. But the 16-bit crc proposed I think it too much for little processors. It's not the code - that is short and sweet - its the 512 bytes of RAM is chews up. That is fully 1/2 of the SRAM available on an ATmega8. Not impossible, but it seems rather overkill to devote that much resources to that unless it is shown that a simple overflowing checksum 8-bit or 16-bit even is not adequate for most application. If stronger checksum are necessary for a particular application, the data payload area can include its own checksum as part of the application layer.

Feature creep! What starts simple and elegant can quickly become a spaghetti nightmare. I agree completely.
-Brian
--
Brian Dean
http://www.bdmicro.com/
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
blueeyedpop wrote:

I fully agree with this. Keep ROBIN simple. -- D. Jay Newman
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
CAN is really really nifty, but it requires hardware specific chips to implement, and I am 90% sure there are liscensing issues, ( could be wrong.)
RS-485 is great because it is relitively simple, requires a couple of bucks of simple hardware, and a micro with a UART or UART emulation.
It just seems that if the OP decides to do what it is he intends to do, he will be diluting all the efforts that have gone into ROBIN if he is at all successful, since in my understanding of it, ROBIN covers most of what he is looking to do. Perhaps I misunderstand the ROBIN implementation.
Mike

notions
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
blueeyedpop wrote:

There's also ARCnet, which is decades old and works on RS-485.
    http://www.arcnet.com
It's widely used for embedded control and building automation. The ARCnet trade association claims 10 million installed nodes. ARCnet was designed to run on machines in the Z-80 range, so it doesn't take much of a microcontroller to run it.
There's downloadable firmware and a board layout on the site.
                John Nagle                 Team Overbot
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Wed, 20 Oct 2004 08:20:40 +0000, John Nagle wrote:

Now this is very cool. It does appear to be a bit more heavy-weight than ROBIN, but has a lot of the features that Clifford is looking for such as auto-enumeration. Not sure if it can fit in our target goal of $3 MCUs, though. But this is definitely worth serious consideration.
Investigation in progress ...
Thanks, John!
-Brian
--
Brian Dean
http://www.bdmicro.com/
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
See tribotix.com, they sell Megarobotics (TTL serial) & Robotis (RS485) modules already.
Clifford Heath wrote:

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Peter Turner wrote:

Nice. They haven't published their English translation of the Korean manual for the protocol yet, and I can't navigate in <www.robotis.com>. Still, it's the right idea though it looks expensive.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
I have a copy of Dynamixel manual in English, if you send email to me I'll reply with manual attached.
Clifford Heath wrote:

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.