Hi Eric,
The choice of protocol is really dependant on the application, and
how much effort you wish to expend.

My experience is that most of the "standard protocols" require a great
deal of effort to implement, and are generally hopelessly overblown in
complexity.

The time required to produce your own is probably less, and generally
will lead to a more efficient effective solution.

The downside of course is you lose the ability to use whatever diagnostic
tools and software that already exists for a given standard. Also you
need to consider whatever marketting advantage may be gained by being
able to claim "inter-working" with some standard network.

If you decide to roll-your own protocol here are some things to consider.

1. Master/Slave is easier than Peer-to-Peer. ( I like dictatorships!)
   Has the subtle advantage of concentrating error recovery procedures
   at the one end of the link.

2. A unique flag sequence is required if you want
   your network to be data-transparent.
   This can be acheived with a number of different methods.
   1. Bit Stuffing (like HDLC)
   2. Byte Stuffing.
   3. Time slots.
   4. Combinations of the above.

3. A mechanism for identifying corrupted packets. (at the Rx end)
   1. Simple XOR checksum
   2. CRC checksum
   3. Hamming Codes (advantage of error correcting)

4. A mechanism for identifying bad transactions  ( at the Tx end )
   1. An ACK/NAK method. ( Rx end responds with either.)
   2. TimeOut method     ( Rx end doesn't respond with a time slot)
   3. Packet numbering   ( Rx end sends sequenced ACK/NAK's)

5. A recovery method for failed transactions.
   1. Simple retry.
   2. Alarm Handling
   3. Defined behaviour for nodes that get disconnected from
      the network. If nodes are able to appear and dissapear
      from the network you might need some sort of "attach"
      "detach" protocol.

Finally, don't forget that for HDX you should allow a turnaround
delay. (can be very short) Also don't flip back to receive after
transmission until tx shifting is complete.

                                Good Luck!,     Ray

>
>Anybody has information about implementing RS-485 "network" protocol on a
>PIC 16C84 or 16C71?
>
>I'm looking for software capable of handling half-duplex comms (single
>pair of RS-485 cable) between various devices (minimum 64). Speed is not
>important. I have already some ideas but I don't want to reinvent the
>wheel...
>
>Thanks in advance
>
>Eric.

Ray Gardiner, Shepparton, Victoria, Australia       ray@netspace.net.au