Network suggestions (was: Re: RoboBricks2 bus: (was: Re: How exactly do (hobby) servo motors work?))

The choice of CAN bus physical layer vs. RS-485 or RS-422 is

> because CAN bus is multi-drop (like RS-485) *and* we do not > have to fiddle with a transceiver direction line. All RS-485 > transceivers have a direction control line and it is kind of > a pain in the rear to get the microcontroller to deassert that > line after it is done transmitting. (For the PIC, you have > to go into a tight loop checking the transmit buffer empty > flag.) Other that that important little detail, CAN and RS-485 > are pretty interchangeable.

This is a great lead-in to the question I was planning on posing anyway. My inquiry is:

Assuming I get the contract I'm hoping for, in about a month I'll be designing a robotic device with several on-board processors, which will be connected by a network of some sort. I'm wondering if anyone has any suggestions for the network, before I roll-my-own YANP (yet another network protocol). Significant design criteria are:

- Multi-master protocol: I'd prefer not to use collision detect, although with a CAN-like priority scheme this might be OK. Alternatively, some sort of token-passing scheme might work. One of the processors will be acting as a watchdog to kick-start things if the packet gets lost. However, I'd like the ability to dynamically add/remove nodes while causing only a transient disturbance to the network.

- Relatively low data rates: 9600 baud *might* be barely enough, although I'd feel much more comfortable at about 10 times that rate. There may be video, but if so the image processing will occur at the camera processor, so only object information needs to go over the network.

- A variety of processors on the net, ranging from embedded-PC power all the way down to 8051-class devices. In general, code space probably won't be too much of a problem, but available RAM probably will be. For ease of writing/debugging, I'd prefer a fairly simple protocol.

- The physical layer will be a CAN bus, probably using the same MCP2551 transceivers that Wayne selected. This limits my minimum data rate to 16.5 kbps before the transceiver decides the node is sick and turns itself off. If possible, I'd like to use something based on 8-bit bytes, so that I can use the built in UART in the 8051s.

So, any ideas? I need open-source of some sort, since I'll be porting it to a variety of processors. Just a description of the protocol itself is enough, since I can code it myself (see "ease of wiring/debugging", above!).

Thanks!

-- Mark Moulding

Reply to
LocalHost
Loading thread data ...

Mark,

I have similar (nearly identical, actually) requirements in mind for putting together a network of microcontrollers in my robot. I like CAN for the physical layer too, though for small networks (2-4 processors) I will probably

430 No such article 222 10925 body LocalHost wrote:

Mark,

I have similar (nearly identical, actually) requirements in mind for putting together a network of microcontrollers in my robot. I like CAN for the physical layer too, though for small networks (2-4 processors) I will probably just use a single GAL chip.

I am working on a very simple protocol with a preamble byte (or two), a fixed number of data bytes, and a checksum byte. My approach does use collision detection by comparing the next byte received with the last byte sent. If they don't match, I implement collision recovery.

Initial testing looks promising, but my code is nowhere near ready for prime time. It was largely inspired, however, by an example project in "C and the

8051", 3rd edition, by Thomas Schultz (1-58961-237-X, Pagefree Publishing).

Good luck,

Jeff.

Reply to
Jeff Shirley

I've been searching the Net for a while for my own hexapod robot project, but to date I've come up with only two references...

a. the Microchip Application Note 736 for Enviromental Monitoring network An I2C Network Protocol for Environmental Monitoring

formatting link
b. AKO Protocol Specification
formatting link
Probably, there are some more but definetely aren't opensource.

I finally decided to come up with my own project, named Simple Embedded Network Protocol (SENP) compiled under SDCC for PIC18F devices utilizing I2C

I have done some progress but nothing working to the moment, and possibly if there isn't any particular reason for that, it will take some time to finish...

We could write a new specification and make it a standard... (!)

regards, Vangelis

Reply to
Vangelis Rokas

[snip]
[snip]
[snip]

Mark:

One of our club members has become a convert of the Microchip MCP2515 CAN bus controller with SPI interface. This allows him to use whatever microcontroller is right for the task at hand, and then using a small number of wires on the microcontoller to talk to the 2515. The problem with this strategy is that you have to implement a fairly complete CAN bus stack for each microcontroller. This club member also claims that it is possible to trim down the CAN bus stack to a smaller but useful subset, but I am not able to speak to this possibility. You might want to seriously consider using the MCP2515 chip.

For UART's connected to CAN bus, I am not aware of any specific protocol stack, but there are plenty of generic stacks out there. Just remember that the UART's that are on most microcontrollers are pretty limited with only one or two bytes of buffering. The longer you make your packets, the easier it is to overrun the UART buffer. Also, be aware that 8-bit CAN/UART bus is a "party line" kind of environment. Everything that is sent is received by all platforms. The more complicated the protocol you use, the more you bog down all of the processors listening on the bus. For 9-bit packets (disallowed in your requirements above), it is possible to get the UART's to ignore data traffic destined to other nodes. (This is controlled by the ADEN bit on the PIC microcontrollers; I have heard that the AVR is supposed to have similar functionality.)

My experience with CAN/UART is that the noise immunity is extremely high. Thus, I have found no need to packet lengths and checksums. My commands tend to be between 1-3 bytes long and work just fine.

Lastly, I have found having a tool that can record traffic on the bus to be extremely useful for debugging. For me it is just a PIC that buffers up the last 32 bytes of traffic and I can print them out to a terminal emulator.

-Wayne

Reply to
Wayne C. Gramlich

(Belated) thanks for the tip; I read the data sheet, and have ordered a few from DigiKey. It really looks pretty simple (of course, I haven't actually

*done* it yet) to put together a viable network this way.

A downside to using the CAN protocol, for me at least, is that the data portion of the message is quite short, limited to only 8 bytes. For most of my purposes, that's OK, since the structure I'll be using is to have each processor periodically post its interesting data to specific addresses on a virtual "bulletin board", which all the other processors can maintain their own virtual copy of. Certain specific addresses are reserved as command portals, one for each processor. There's really no structural difference, just that the addressed processor will know to treat that particular address as an executable command, and probably issue a separate acknowledgement of some sort.

However, because the maximum packet size is so small, commands which require a longer data portion would have to use some sort of multi-part message protocol, with the attendant development effort and, more fundamentally, a modality that otherwise doesn;t have to exist. Hopefully I can make this not necessary, but I'm still working that part out...

I'm counting on this to make my "bulletin board" model work. I believe this is a fairly standard technique for automotive applications.

Also 8051's. I've used this method of addressing on a project, and it really works quite well; just set the top (ninth) bit of the address byte, which must be the first in the packet, and use the special interrupt to cause the addressed processor to begin caring about the remainder of the packet bytes - quite easy to implement, at least on processors with this option. For those that don't (like a PC), it can be a real pain...

You're probably right about this, but the downside to an erroneous packet (as opposed to a lost one) could be pretty significant in this project, so I'll use some sort of error checking. The CAN protocol includes a CRC (conveniently in hardware on the MCP2515), so that will certainly be sufficient.

Now that's a really good idea. That (perhaps enhanced to allow sending packets as well) will be my first device - sort of a "hello, world" for the entire protocol hardware and software stack.

-- Mark

Reply to
Mark Moulding

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.