Pic serial port is used for communication, If you do not large data then half duplex is used for simplicity and ease. RS485 IC is used.It requires 3 pins 1 rx tx and enable. This setup would be same for master and slave. In free mode all would be in listening mode. Every pic will have unique address. when master send some data all slave will receive that data but only the addressee slave will respond. others will just ignore that data request. For fault free communication crc checksum is also added in the transmitted data for error correction. If the distance is longer then protection against lightning need to be added in circuit.

If you're using RS485 over longer distances, use an optocoupler to reduce the difference of voltage potentials between master and slaves.Also if you're using this outside beware of lightning strikes which can implant a large power surge or spike, use surge suppressors.

I have made some projects on RS485 for controlling vigilance cameras, solenoid, ...I suggest you to put between each pic two 75176 ICs, they convert RS232 to RS485 with a maximum distance of 1.2 kilometers.I guarantee you that works very well.

I want to help but I am a little bit confused by what exactly you request.If you have experience in using any software tool or compiler let us know and we can give you more information about which library and/or drivers to use for your propose.The RS485

Quote

is a standard defining the electrical characteristics of drivers and receivers for use in balanced digital multipoint systems(wikipedia)

. In an OSI - ISO model RS485 define the physical and data link layers. You can see some PIC uC with (E)U(S)ART peripherals supporting RS485. Your PIC will not contain a RS485 transceiver but it can be configured to control the RE/DE signals for enabling the receiver and transmitter drivers of the transceiver and also can help with sending the 9th bit (address bit : slave/master). If you have already a working RS485 bus between your PIC microcontrollers and you want to know how to communicate between master and slave to exchange the data, then you need to define your one Application layer or to use one like Modbus ASCII.

If I understand correctly, we discuss the new configuration, not the connection to existing RS-485 net. Then I'm very interested what specific requirements lead TC to the choice of that standard. For most cases I can imagine a CAN bus is much easier for developer with more than enough built in functionality.

Even for that tiny payload (4 bit back and forth) extra $ for CAN controller (better integrated - see PIC18F66K80 series as we talk about PIC) is not a problem for tiny production volume I suppose and is much cheaper than days of implementing (and testing) your own protocol over RS-485. Response time comparable with button debounce delay defines slow speed requirements - so distance is again not a problem.

If I understand correctly, we discuss the new configuration, not the connection to existing RS-485 net. Then I'm very interested what specific requirements lead TC to the choice of that standard. For most cases I can imagine a CAN bus is much easier for developer with more than enough built in functionality.

Agree that CAN will be more easier for the configuration defined, maybe RS485 chosen because CAN have a lot more bigger barrier to entry on learning it, at least on me.

Even for that tiny payload (4 bit back and forth) extra $ for CAN controller (better integrated - see PIC18F66K80 series as we talk about PIC) is not a problem for tiny production volume I suppose and is much cheaper than days of implementing (and testing) your own protocol over RS-485. Response time comparable with button debounce delay defines slow speed requirements - so distance is again not a problem.

I cannot see a difference between using RS485 or CAN bus from the Application Layer protocol point of view.

I'd suggest using MODBUS. It's probably one of the simplest industry standard communication protocols for a master/multislave setup. There are tons of good 4 wire and 2 wire transceivers out there from Maxim, ST, and Analog devices. You can get long distances and high speed out of RS485 and the hardware layer (UART) is dead simple (same as RS232 from the uC point of view with one extra I/O for TX enable)

I cannot see a difference between using RS485 or CAN bus from the Application Layer protocol point of view.

I guess you mean a kind of protocol over RS485 like MODBUS. Then yes, usage of Application Layer should be almost as simple as usage of keys of UI. My statement about easiness was not precise. I thought not about using a library, but making stack from scratch - in that case CAN controller takes most of burden, CAN bus itself without upper layers is well suited for transmission of discrete signals, while configuration is not really a hard task. My estimation was biased. And it was my mistake to compare RS485 and CAN bus here.

Two slaves, each pair master-slave communicates by sending 2 bits of data.Master polls slaves by packets that fit in one byte (or 9 bits) including CRC : [master-mark, slaveaddress(0 or 1), status(2 bits), CRC].Slaves respond with packets that also fit in one byte: [slave-mark, slaveaddress, keys(2 bits), CRC].So the protocol handling becomes exceptionally simple:Master periodically sends prepared bytes - appropriate slave responds after checking address and CRC - master reads task from received byte. finish.CRC check is performed by one comparison using table of 16 bytes. CRC for sending is generated using the same table.Not scalable but very compact solution.

I personally would use CAN even for that task for two reasons:1) I am familiar with CAN bus, and probably will start use it before thinking over alternative. biased. mea culpa2) I remember its scalability and built-in functionality that unloads software.