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

I hadn't really considered something like this before, though I'm sure it came up on the lists at some point. We've tried hard to keep ROBIN implementable on $3 microcontrollers, so some things like that have not made it into the implementation because they typically introduce complexity into the protocol and the implementation. Larger processors already have many options for this type of communication, but there's a void when it comes to the low-end. We want to be able to use ROBIN on our small microcontrollers (PICs, AVRs, etc). Making something like DHCP work is non-trivial, at least when you might have very limited RAM and/or flash, and you still need to actually implement the target application (h-bridge, or whatever).

My personal perspective is that some minimal amount of configuration is necessary on the device off-line before connecting it to the bus, whether that be jumpers, dip switches, or even the semi-online "configuration commands" of ROBIN. Hot connect is not a problem, though. Any master device can scan the bus for new nodes at any time using the "id request" bit on all possible addresses and noting which ones respond.

But if you can think of a way to do a DHCP-like method that is not too taxing in terms of complexity or flash or ram space, I think that would be excellent. But ... what is not too taxing for an SBC ARM board with several meg of memory might be out of the question for a $3 AVR. As it stands, ROBIN works just fine on a $3 AVR (my h-bridge pid controller is an example). It's gotta fit in a small micro.

I like screw terminals. The only tools you need are wire cutters and a screw driver :-) And they are compact, and you can make multiple connections with just the single connector for daisy chaining along the bus to the next node. Also, screw terminals make RS-485 biasing and terminating resistors very easy to add.

I will do. Check back from time to time. Also, hook up with D. Jay Newman who has also been quite active and interested in ROBIN also. And do let us know if you can come up with a lightweight auto-enumeration method. That would be interesting, in and of itself.

I think at this point, ROBIN needs more implementors and we need to go through a cycle of tweaking, trimming, and tuning - be brutal, cut the fat and keep the lean. I think our biggest danger is feature creep. Beware! It's easy to add little features here and there which seem neat and nifty in your head, but when translated to code can greatly inflate the complexity and code size. Try to retain a minimalist yet still functional approach which is necessary to keep it viable for small micros ($3 PICs and AVRs). ROBIN still works fine and is quite powerful on larger processors, but one is not apt to add 10 ROBIN sensor nodes to pimp-out their robot if each one requires a $120 microcontroller board :-)

Yet still, there's got to be enough muscle to to get the job done. And perhaps a few "luxury items" to make it interesting, perhaps even if some luxury items are optional as long as they are not "central" to the core of the protocol.

-Brian

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

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++); }

Nice. They haven't published their English translation of the Korean manual for the protocol yet, and I can't navigate in . Still, it's the right idea though it looks expensive.

There's also ARCnet, which is decades old and works on RS-485.

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

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

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

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

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

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

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

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, . It seems not to address RS422/485 at all however.

Clifford Heath.

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

I fully agree with this. Keep ROBIN simple.

-- D. Jay Newman