START/STOP Sync pattern

Hi all,

I am implementing some logic in FPGA(Transmit/Reveive).

On the receive data first i look for a 8- bit pattern to detect the START pattern.Now my question is in the data also i may get the same START pattern how to distinguish between the START /STOP pattern and data.

Any comments are appreciated.

Regards, Prav

Reply to
praveen.kantharajapura
Loading thread data ...

Use Google!

Here is a start:

formatting link
formatting link

Reply to
Kryten

If the receiver delivers bytes to the upper level, I recommend you to use escape sequences.

For instance:

Received Meaning

-------- -------

00 00 .. .. FC FC FD 0D FD FD 0E FE FD 0F FF FE Beg of packet FF End of packet

Every time you receive 0xFE, you know you are at the beginning of packet. You cannot find 0xFE inside the message (assuming no errors). Similarly for 0xFF. Also, every time you receive 0xFD, you know you have hit a 2-byte escape sequence, and you need to read the next byte.

Reply to
Mochuelo

Okay, so now as well as avoiding one byte code in the data, you now have to avoid more than one.

This has not improved the situation.

8-bit data links have been invented.

Don't re-invent them.

Reply to
Kryten

Another very simple way to do this (in line with Mochuelo's technique) is to use a standard encoding (such as 8bit - 10bit encoding as used in various ethernet and other communications protocols) and then assign a comma code [sometimes known as a code violation] (precisely as is done in such links) for start / stop.

This adds overhead, of course, but unless you want to get into statistical analysis (such as framing bits require), it's simple, uses a published standard and cheap in hardware to implement.

Cheers

PeteS

Reply to
PeteS

It makes synchronization -look at the thread title- more simple and robust, using a very simple mapping with a ridiculous overhead involved (1.2 % for long messages).

I could make it to avoid only one byte code, but I chose it to avoid two to distinguish between beginning and end of packet. The benefit is clear and the overhead is just 0.4 %, so go for it.

Like which one?

Show me one with better ratio benefit/overhead, and with a similar implementation complexity.

Reply to
Mochuelo

HDLC

Reply to
Kryten

HDLC is not 8-bit oriented. It is 1-bit oriented. Implementing bit stuffing when you work one byte at a time is possible, but also a pain in the ass (I did it once). Nothing to do with the simplicity of the mapping I mentioned. I should remind that the first sentence of my first post was "If the receiver delivers bytes to the upper level."

Reply to
Mochuelo

ElectronDepot 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.