×
INTELLIGENT WORK FORUMS
FOR ENGINEERING PROFESSIONALS

Log In

Come Join Us!

Are you an
Engineering professional?
Join Eng-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Eng-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Jobs

Implementation suggestions requested for serial protocol

Implementation suggestions requested for serial protocol

Implementation suggestions requested for serial protocol

(OP)
In my design, I have two system boards that I am planning to connect via a serial link.  On a hardware level, I am planning on using two LVDS transmitters and receivers on both ends to implement a varient of SPI.  The varient comes into play in that I am planning on using the second transmitter on the 'slave' device as a form of interrupt line  to signal that either the device is ready or that it requires some attention.  I am also planning on utilizing a CRC on the data with some form of handshaking to know that data has been transmitted and received correctly.

At the moment, I am starting to work on the implementation details of this protocol and have run into a question that I could use a suggestion on.  My concern is, how to handle the start and end of message framing.  While the electrical properties are such that missing or extra bits should be rare, I need a way to detect this.  Basically I need a way for the receiver to know that the sender is done transmitting and the message is ready for processing.  

I have considered using a form of "start" and "stop" bits or the method of X amount of idle comm time means end of message (like Modbus) but I am wondering if there is a better method.  Both sides will have their own clocks, in addition to the "data" clock that is used to communicate the bits.  

If any of you have some suggestions of what works well, perhaps soemthing that you have implemented before I would greatly appreciate it if you would be willing to share your ideas.

RE: Implementation suggestions requested for serial protocol

You want two systems to communicate reliably, this is how it is normally done...

Figure out a protocol, like:
*ADDR:DATA;CHECKSUM<CR>
<*> denotes a message from the "remote"

Confirmation from the "master":
$ADDR:DATA;CHECKSUM<CR>

The remotes send their data.  Then start a timer.(if you care) Then the remote scans the data coming from the Master looking for the $.  Once the $ is found it is added to every other character until the CHECKSUM.  The CHECKSUM is compared.  If it matches the received message was intact and the message is "valid" or was "received".

If after the timer runs out then the message is assumed to have been garbled and is resent.


If messages are sent both ways then you can add other special characters &,#,%, to assist the two parties in instantly identifying what the message is going to be a confirmation or a command, etc.

Just use a standard ASCII serial link.  Drop kick that CRC.
CRCs are for long messages that come over lousy channels that often garf up the data.  This should not be very common in your system or you have other more serious problems.

The standard serial ports handle all the asynchronous synchronization automatically.  You can hang hyper-terminal onto a line and observe the data and in a few seconds know if things are happy or sad.

I see zero reasons for mucking about with idle time and stop and start bits (outside of the standard async serial ones).

Keith Cress
Flamin Systems, Inc.- http://www.flaminsystems.com - kcress@<solve this puzzle>

RE: Implementation suggestions requested for serial protocol

(OP)
itsmoked,

Thank you for your reply. Sometimes I think I get buried to where I can't see the forest because of the trees dazed

The wheels are starting to turn.  The idea of using sentinel characters is so obviously simple that it could have bit me in the backside and I wouldn't have known it.  The idea of using multiple characters so that the master and slave can each recognize the start of a message simultaneously is Ingenious!

RE: Implementation suggestions requested for serial protocol

Hi Noway2.

When designing stuff(especially industrial!) (industrial is far less cost sensitive) I try pretty hard to look at how to troubleshoot and work thru the development of a design.  That way you go in hoping for "no worries mate" but if a hitch shows up you can quickly diagnose it.  Hence the ASCII easily readable messages as apposed to cryptic dense binary.  Binary would be the choice if you had a restricted data channel or a truck load of data to shift.

  Same goes for the Asynchronous instead of SPI.  If there are other reasons then SPI may make better sense, but I find it often a bigger headache since it is harder to look at.  If for example you have two processors on the same physical board SPI would make more sense.  If you are dealing with separate boards ASCII makes lots of sense because then production can just jack the boards in to a PC and test/calibrate/preset/troubleshoot the individual components preventing the, "we thru the switch and nothing happensbanghead", where's the problem scenario.

Keith Cress
Flamin Systems, Inc.- <http://www.flaminsystems.com> - kcress@<solve this puzzle>

RE: Implementation suggestions requested for serial protocol

It might help to review the 7-layer ISO communications model. Even if you don't implement all the layers, it can really help to organize your thoughts. It can also help you to keep the functions mentioned by Mr. Smoked segregated at the proper levels in your code.

RE: Implementation suggestions requested for serial protocol

(OP)
Thank you for the replies.

We have finally settled on using SPI over a short length of ribbon cable for the communication between the two system boards.  It turns out that both boards have the same processor on them, both with built in SPI support, so getting them to talk to each other shouldn't be too difficult of a task (I know famous last words).

The cable only has to go a few feet, so I am going to attempt to use standard ribbon with S-G-S-G arangement, but the signals were assigned to pins so that I can use twisted ribbon if need be.

On top of this, I will undoubtedly implement some software 'handshaking' to ensure that any critical data is received properly.

Ve1Bll, a review of the communications model would probably be a good idea.  It has been a few years since I have looked at it.

RE: Implementation suggestions requested for serial protocol

I would suggest that you find some IP that you can plop in there and be done.

We went the custom bit-pushing route on one design and spent MONTHS debugging the FPGA.  It was horrible...

TTFN



RE: Implementation suggestions requested for serial protocol

(OP)
I hear you there, with regards to finding some IP.  This is exactly what I am doing for communication between the main processor and the one that is implemented in the FPGA (Nios2) that will handle the ethernet interface.  I know, ethernet, please don't ask - it wasn't my idea.  It has the same origins as the Safety Relays that I was asking about earlier this year.  

In any case, I was handed a block to plop in the FPGA that will handle the bus arbitration between the two processors for any shared resources.  They can both place their busses in a High-Z state and allow the other one to have at it. It looks like a pretty simple piece of Verilog, which of course has prompted me to start studying Verilog.  Upto this point, I had  predominatly used VHDL, which was the language of preference when I started working with programmable logic.

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Eng-Tips Forums free from inappropriate posts.
The Eng-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Eng-Tips forums is a member-only feature.

Click Here to join Eng-Tips and talk with other members!


Resources