piclist 2002\10\13\132613a >
Thread: Embedded Communication System
www.piclist.com/techref/microchip/devices.htm?key=pic
flavicon
face BY : Wagner Lipnharski email (remove spam text)



Donovan Parks wrote:
{Quote hidden}

It doesn't matter so much if you chose one or another,
all of them would be based on simple things;

Packet preamble identification (sync) byte or bits.
Destination address byte(s)
Sender address byte(s)
Packet Frame number in 8 or 16 bits
Type of Frame - Data, Request or Confirmation.
Size of dataframe (in bytes)
DataFrame
CheckByte(s)

With this in mind, you can develop your own protocol.

Preamble ID can be anything you create, some sugestions goes to 55h, AAh,
or any combination of those. You can use one byte or more to ensure the
receiver will not start to receive a frame in middle of it.

Destination address should match destination hardwire or softwire station
setup.

Sender address should be used by the destination to answer the frame.

Packet Frame Number will be used to identify an answer, request or
confirmation.

Type of Frame - So the destination will know what this frame is about,
data, request, etc. and deal accordingly. A single byte should do it.  You
can think to share just one byte for Type of Frame and Packet Frame Number
if you want - 4 bits each.

Size of dataframe - 1 or 2 bytes, you should define the max length of your
data transmission.  The receiver will know exactly when the data part ends
and crc or other check bytes start.

Dataframe - a bunch of data - binary or packed bcd - the Type of Frame can
identify the data type.

CheckByte(s) - CRC16 is recommended, easy and fast.

Confirmation should be always done to the sender by the receiver with frame
number, so the sender will know the receiver got the data.  A retry count
should be accounted, so the sender will just consider destination not
operational after a certain retry attempts, or by reception error, or by
timeout (destination is really offline).

Frame number should be a dedicated sequence between sender and receiver, so
the receiver will always expect an incrementing number in a multiple frame
reception.  A broken sequence will flag a missing frame and should start a
destination request for that particular missing frame to the sender.

Easy simple protocol is what is the best.  You can accomodate exactly what
you need, how you need and as simple as you need.

Except if you want to explore the market with available protocols for a
better marketing approach.

Wagner Lipnharski - email:  EraseMEwagnerspamspamBeGoneustr.net
UST Research Inc. - Development Director
http://www.ustr.net - Orlando Florida 32837
Licensed Consultant Atmel AVR _/_/_/_/_/_/

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestspammitvma.mit.edu


<017301c272dd$46ad5a20$9acc1b18@cfl.rr.com> 7bit

See also: www.piclist.com/techref/microchip/devices.htm?key=pic
Reply You must be a member of the piclist mailing list (not only a www.piclist.com member) to post to the piclist. This form requires JavaScript and a browser/email client that can handle form mailto: posts.
Subject (change) Embedded Communication System

month overview.

new search...