Network suggestions (was: Re: RoboBricks2 bus: (was: Re: How exactly do (hobby) servo moto...

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

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.
--
Jeff Shirley
spam-nuke@mindspring.com
"Bill Gates is filthy rich, but that doesn't mean I want to be married to him."

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
      
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId 24&appnote=en011810

    b. AKO Protocol Specification (http://ako.sourceforge.net )

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

[snip]


[snip]

[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

(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