Implementation suggestions requested for serial protocol 1

Noway2 · Feb 27, 2006

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.

itsmoked · Feb 27, 2006

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

Figure out a protocol, like:
*ADDR

ATA;CHECKSUM<CR>
<*> denotes a message from the "remote"

Confirmation from the "master":
$ADDR

ATA;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>

Noway2 · Feb 27, 2006

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!

itsmoked · Feb 27, 2006

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 happens [banghead]

", where's the problem scenario.

Keith Cress
Flamin Systems, Inc.- <

http://www.flaminsystems.com>

- kcress@<solve this puzzle>

VEBill · Aug 17, 2006

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.

Noway2 · Aug 17, 2006

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.

IRstuff · Aug 17, 2006

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

Noway2 · Aug 17, 2006

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.

Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

Implementation suggestions requested for serial protocol 1

Noway2

Electrical

Recommended for you

itsmoked

Electrical

Noway2

Electrical

itsmoked

Electrical

VEBill

Military

Noway2

Electrical

IRstuff

Aerospace

Noway2

Electrical

Similar threads

Part and Inventory Search

Sponsor