Re: Serial Control Protocol

All:

Sorry, about the late response, I was off in Europe doing some
consulting (robotics related no less) and have just been catching
up on comp.robotics.misc this weekend...

Gordon McComb wrote:
Not sure how widely used it is beyond the product line it was developed
for, but you might look at the protocol used in the RoboBricks project:

http://www.gramlich.net/projects/robobricks/specifications.html
http://www.gramlich.net/projects/rb2/index.html

Wayne often posts here and he can provide the pros and cons. Certainly
one benefit would be compatibility with these little modules. For a
while RobotStore was selling them (before Jameco bought them), but I
don't know what their current status is.

The first set of modules, called RoboBricks 1 (or RoboBRiX) used
5Volt signalling at 2400 baud. It was a binary protocol where
a master module would send a 1 or more bytes and get 0, 1 or more
bytes in return. It worked well with the bit banged serial protocol
that the Parallax Basic Stamp, OOPic, Javalin, etc. could do.
The RoboStore used to carry them, but Jameco did not pick up the
contract when they purchased RoboStore. (Actually, there is quite
a bit more to the RoboBrick 1 saga, but not on this forum.)

The next set of modules, called RoboBricks 2, (as you can see,
I'm not very inventive with my project names) is based on a
multi-drop bus. It evolved out of an extensive discussion we
had on the Home Brew Robotics Club mailing list last September.
It uses the CAN bus physical layer which is a differential
signalling bus that was developed by the automotive industry.
We only use the CAN bus physical layer and and UART's. We
do *not* require microcontrollers that support the full CAN
bus stack; we just need "addressable" UART's.

The first set of RB2 modules is up and running at 625,000 baud.
CAN bus is capable of 1M bps, so the next set of modules is
going to have all of the microcontroller crystals and resonators
changed to shoot for 1M bps. By the way, the next set of modules
is sitting on my dining room table waiting for a soldering party
this coming Tuesday.

The jury is still out on how well the RB2 modules will work.
Hopefully, in the next few weeks we'll get a chance to get
a robot or two working with them to see how they do.

With regards to protocol selection, there are plenty of them
out there. Either choose one that already exists or roll your
own.

-Wayne

One thing to keep in mind about both of these specs: they've been proven
in real-life products, and I think that's important. I think Scott has
used SCP in products other than OOPic (I'm pretty sure Speakjet, for
one), and Wayne has demonstrated the efficacy of the Robobricks
communications platform.

Good luck with your project!

-- Gordon


Eddy Wright wrote:

Gordon, I agree that it looks like a good protocol. I was wondering if
there was another serial protocol that is widely accepted that I may
have missed in my searching. Doesn't look like there is though.

I think SCP will fit my needs so I plan to use it.

It looks like openscp.com is gone but I found that openscp.org wasn't
taken. I am willing to build a site for SCP at openscp.org if anyone
is interested collaborating on it. I'd like to promote the standard if
I'm going to use it.
.

Relevant Pages

  • Re: Knowledge in DUP-line protocol?
    ... each pulse Low for 0,3 ms, High for 0,7 ms, to describe the 0-signal. ... bus. ... The DUP-line protocol is allready engineered further! ... unless a transmitter is connected at the very end of each branch. ...
    (sci.electronics.design)
  • Re: Knowledge in DUP-line protocol?
    ... each pulse Low for 0,3 ms, High for 0,7 ms, to describe the 0-signal. ... bus. ... The DUP-line protocol is allready engineered further! ... unless a transmitter is connected at the very end of each branch. ...
    (sci.electronics.design)
  • Re: USB transfer not working after 6 incomplete IN transactions
    ... I tried to see the activity on the USB bus using Ellisys USB protocol ... If my application stops writing to the device, ...
    (microsoft.public.development.device.drivers)
  • Re: Basic MIL-STD-1553B questions
    ... RTs "flood" the bus in the manner of nodes on an Ethernet network? ... RTs are not allowed to say anything at all unless spoken to and then are limited to transmitting 32 data words. ... the definition of the protocol prevents "flooding". ... manufacturers have to have a second physical bus, ...
    (comp.arch.embedded)
Loading