Searching \ for '[PIC]: Protocols for Serial Communications' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: piclist.com/techref/microchip/ios.htm?key=serial
Search entire site for: 'Protocols for Serial Communications'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Protocols for Serial Communications'
2000\08\25@012301 by Philip Addicott

flavicon
face
I have been working towards a stable serial link with a PC. I am not sending
a lot of data, things like date,time stamps plus the odd 6 or 8 byte codes.
However it has become pretty clear that good serial coms has a lot more to
it than banning bits in and out of a PIC, bits DO go missing or get
corrupted. It also seems that the pins for hardware handshaking are never
used so there must be protocols involved, so here are my questions.

Is there a standard protocol or at least a guideline that one could work
from?

Do I need to use CRC or is a xor check sum ok?

Thanking you in advance.
Philip

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


2000\08\25@015201 by Paul Drummond

flavicon
face
Philip,  RS-232 standards are good to 10 metres or more depending on noise
and cable specs.  If you are missing bits then it sounds like you may have a
timing issue. Make sure you are using a crystal because the error with a RC
network is often too great for reliable comms unless you are transcieving at
very slow speeds.  You also have to sample the bits in the centre of the BIT
time.  Taking many samples towards the centre of the bit and then going on
the highest ratio or a set standard ratio (say 80%) will improve things.


{Original Message removed}

2000\08\25@023003 by Mike Cornelius

flavicon
face
Hi Phillip,

HDLC (or some variation thereof) has well and truly stood the test of time
it is very easy to implement, efficient, and most importantly well
understood.

Many protocols base themselves on HDLC particularly its framing structure.
If your product is fairly specific you'll probably just want to use the HDLC
framing rules and your own protocol for the actual data.

An HDLC frame looks like this :-

FLAG            ADDRESS Payload         CRC             FLAG
(8bits)         (0-16Bits)  (8 * N Bits)        (16 Bits)       (8Bits)

Basic rules:-
The flag is a fixed byte (often 0b01111110 or 0x7E)
The flag must be escaped if it appears in the data stream.

Have a search around the web for more details..

Unless you're really tight on time or program space I'lld say go with the
CRC (it's VERY easy to implement) over a simple checksum.

Regards,

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mike Cornelius                  Internet: .....mikeKILLspamspam@spam@bytethis.com.au
Byte This Interactive           Phone:    +61 2 9310-2157
PO Box 1342 Strawberry Hills    FAX:      +61 2 9319-3948
NSW 2012 Australia              URL:      http://www.bytethis.com.au
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

{Original Message removed}

2000\08\25@050633 by WALSH, Scott

flavicon
face
Philip,

It sounds like something simple such as SLIP is what you need. See,
http://www.faqs.org/rfcs/rfc1055.html you only need to go to the extent of a
CRC if you wish to correct a small number of detected bit-errors, so yes a
XOR or unsigned addition is probably all the you need.

regards,
SW.

{Original Message removed}

2000\08\25@082517 by mike

flavicon
face
On Fri, 25 Aug 2000 07:21:25 +0200, you wrote:

>I have been working towards a stable serial link with a PC. I am not sending
>a lot of data, things like date,time stamps plus the odd 6 or 8 byte codes.
>However it has become pretty clear that good serial coms has a lot more to
>it than banning bits in and out of a PIC, bits DO go missing or get
>corrupted. It also seems that the pins for hardware handshaking are never
>used so there must be protocols involved, so here are my questions.
>
>Is there a standard protocol or at least a guideline that one could work
>from?
>
>Do I need to use CRC or is a xor check sum ok?
For a fixed-wire link a simple checksum is fine - the only errors you
will see will be block-framing ones, e.g. when someone pulls the plug.
You only need CRC when you are actively expecting hardware bit-errors,
e.g. on a radio link.

A really handy way to make a very robust PC-Serial link is to specify
that all data for a command is sent within a specified time, and there
is a minimum time gap between commands -  the PIC can then do a
watchdog timeout if part of the block is missing and it will
automatically re-sync for the next command. Almost no software
overhead on the PIC - just stop clearing  the watchdog after the first
byte of a command has been received, until the whole command has been
got.

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


2000\08\25@093555 by Bob Ammerman

picon face
There are many protocols defined at various levels of standardization, but
nothing really stands out as being the way to go here.

I strongly recommend that you implement some sort of block-oriented
protocol, with appropriate framing characters and some sort of block
checking and retry. A CRC is _much_ stronger than an XOR, but the complexity
might not be needed, depending on your application.

A reasonable alternative to the complexity of a CRC is sending your data
redundantly (ie: send each critical byte twice and only accept the packet if
both copies are the same).

There are more ways to do this than there are participants on PICLIST. Just
be sure to think about all the possibilities (eg: what happens if...) of
data being corrupted/lost on the link.

Obviously, I short link directly between two pieces of hardware in the same
box usually doesn't need the same level of protection as a cross-continent
link via a satellite bounce, for example.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

{Original Message removed}

2000\08\25@102802 by W. K. Brown

flavicon
face
Imho, implementing HDLC without hardware support is hard (bit stuffing,
yuk). If your cpu has an HDLC controller, or you can afford to add a chip,
then use by all means.  For a PIC, I would look at some ASCII based
protocols (SDI-12, for example).  Use some CRC. CRC-16 is, I think, good for
error detection for messages up to 4KB. (If the message is short enough you
can even correct errors. Don't ask me how - I just report the news.)
Regards,
Keith
       {Original Message removed}

2000\08\25@103406 by Severson, Rob

flavicon
face
Try S.N.A.P. at http://www.hth.com

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


2000\08\25@115133 by Ray Gardiner

flavicon
face
Hi Philip,
Someone once said, the nice thing about standards, is that there are so
many to choose from.

Since what you want is a point to point link between the PC and a PIC based
controller, I recommend that you consider the following approach.

Use modbus framing. This is simple and well documented. see http://www.modbus.org
Implement only two transaction types. ReadHoldingRegister and
WriteHoldingRegister. This allow you to simply read and write any
memory that you choose on the target (PIC) Additionally you can extend the
networking to multiple PIC's by going to RS485 HDX.

see:--

   http://www.modicon.com/techpubs/toc7.html

for more detail on how to do other functions, crc calculation etc.

The basic modbus frame for reading is 8 bytes as follows.

       <NetAddress>         == 0x01    // ok, you don't really need it but
                                          // it makes for a convenient sync flag
                                           // anyway
       <FunctionCode>       == 0x03    // 0x03 == read holding register
       <DataAddressHi>      == 0x??    // address in PIC data space
       <DataAddressLo>      == 0x??
       <NumberofRegistersHi>== 0x??    // number of registers to read
      <NUmberofRegistesLo> == 0x??    //
       <16bitCRClobyte>     == 0x??
       <16bitCRChibyte>     == 0x??

The response will be something like...
       <NetAddress>         == 0x01
       <FunctionCode>       == 0x03
       <DataCount>          == 0x??
       <Data>               == 0x??
       <Data>               == 0x??
       <Data>               == 0x??
      .... for DataCount Bytes ...
       <16bitCRClobyte>     == 0x??
       <16bitCRChibyte>     == 0x??

The 16 bit CRC is sufficient for most applications. But... IF you are
transmitting over a noisy link (eg radio), you could consider implementing
some kind of FEC (forward error correction) using hamming codes or
reed-solomon. This means assembling the packet and then encoding with
the appropriate FEC. Then decoding and correcting errors before passing
up to the modbus receive routine. If you have low error rates then you
don't really need it.



{Quote hidden}

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


2000\08\25@132149 by Bob Ammerman

picon face
Note: this thread started witha  discussion on communicating PIC<->PC.
Therefore I'd stick to async stuff, since anything sync is a pain on the PC
and async comes free with just about every PC made.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

----- Original Message -----
From: W. K. Brown <kbrownspamspam_OUTMARSH-MCBIRNEY.COM>
To: <@spam@PICLISTKILLspamspamMITVMA.MIT.EDU>
Sent: Friday, August 25, 2000 7:41 AM
Subject: Re: [PIC]: Protocols for Serial Communications


> Imho, implementing HDLC without hardware support is hard (bit stuffing,
> yuk). If your cpu has an HDLC controller, or you can afford to add a chip,
> then use by all means.  For a PIC, I would look at some ASCII based
> protocols (SDI-12, for example).  Use some CRC. CRC-16 is, I think, good
for
> error detection for messages up to 4KB. (If the message is short enough
you
> can even correct errors. Don't ask me how - I just report the news.)
> Regards,
> Keith
>         {Original Message removed}

2000\08\25@141937 by W. K. Brown

flavicon
face
       Your Pick can be one of many.
       Pick SOME NAMED STANDARD and stick to it (sorry for the shout).
Modbus, STD-12, et., al.
       IMHO. if you let someone bastardize some Standard , I think you are
doomed for life.

       Regards
       Keith

       {Original Message removed}

2000\08\25@143906 by Bob Ammerman

picon face
Pick one of the following:

A: Pick an existing standard, then stick to it and implement if _correctly_.

B: If you don't have any reason to interoperate with other equipment, feel
free to implement your own protocol. Many standard protocols are
overcomplicated for the sometimes simple needs of the PIC world.

My US$0.02.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

----- Original Message -----
From: W. K. Brown <KILLspamkbrownKILLspamspamMARSH-MCBIRNEY.COM>
To: <RemoveMEPICLISTTakeThisOuTspamMITVMA.MIT.EDU>
Sent: Friday, August 25, 2000 2:17 PM
Subject: Re: [PIC]: Protocols for Serial Communications


>         Your Pick can be one of many.
>         Pick SOME NAMED STANDARD and stick to it (sorry for the shout).
> Modbus, STD-12, et., al.
>         IMHO. if you let someone bastardize some Standard , I think you
are
> doomed for life.
>
>         Regards
>         Keith
>
>         {Original Message removed}

2000\08\25@153254 by Olin Lathrop

flavicon
face
> I have been working towards a stable serial link with a PC. I am not
sending
> a lot of data, things like date,time stamps plus the odd 6 or 8 byte
codes.
> However it has become pretty clear that good serial coms has a lot more to
> it than banning bits in and out of a PIC, bits DO go missing or get
> corrupted. It also seems that the pins for hardware handshaking are never
> used so there must be protocols involved, so here are my questions.
>
> Is there a standard protocol or at least a guideline that one could work
> from?

The only "standard" ways to do flow control that I know of is either using
the handshake lines or XON/XOFF.  The former requires extra wires, and the
latter uses up two byte codes, which can be a pain is you want to send
arbitrary binary data.  If you own both ends of the link, you can create
your own protocol that takes care of both flow control and error tolerance.

I have sometimes designed the protocol so that that host sends a small
number of characters or even individual characters before expecting some
sort of ACK from the PIC.  The max burst the host can send is something you
know the PIC can swallow in hardware or in an interrupt serviced input
buffer before the first byte gets overrun.  Of course this costs bandwidth,
so it's not a good choice when lots of data is being moved from host to PIC.
I've done this a number of times when a the host just sends an occasional
command.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, spamBeGoneolinspamBeGonespamcognivis.com, http://www.cognivis.com

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


More... (looser matching)
- Last day of these posts
- In 2000 , 2001 only
- Today
- New search...