Sonsivri

Hello All,

Looking for some ideas regarding RS485 communication between PIC to PIC.
1. One master and 2 slave boards.
2. Master will have 4 outputs (Triggering Port 1 & 2 from Slave-1 and Triggering Port 3 & 4 from Slave-2)
3. Slave-1 will have 2 keys +  2 status LED.
4. Slave -2 will have 2 keys + 2 status LED.

any help is really appreciated!

Regards.

If you are looking for a simple network protocol maybe S.N.A.P could help you get starting...

  http://www.hth.com/snap/

There are PIC and AVR example code I belive.

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.

Hi, read this links
//forums.parallax.com/attachment.php?attachmentid=52528&d=1204741425
//www.protonbasic.co.uk/showthread.php/58216-RS485-and-PicBasic
//www.micromint.com/app_notes/notes/an207.htm

Best regards

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.

Hello friend. I have used PBP for a lot of years.

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.

Here is  image in spanish showing a small diagram with 16F628A

http://i.imgur.com/fAhh7p9.png

Please add termination resistors 120 ohm on both sides. For protection TVS need to be added for longer distances.this link will give practical aspect of rs485 http://www.ti.com/lit/an/slla292a/slla292a.pdf  .http://www.analog.com/static/imported-files/circuit_notes/CN0313.pdf
one more thing add fuses on both lines before TVS.
  For enhanced protection isolated rs485 ics  can be utilised.like http://www.analog.com/static/imported-files/overviews/ADM2587E_82E.pdf
http://www.linear.com/product/LTM2881
http://img.hqew.com/file/Others/320000-329999/325968/Electronic/2012211891194091.pdf
may be helpful in this regard

Hi 7hills,

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

Regards

@Biko4710

Can you show how to connect/add  optocoupler in 485 network?

Bobi

Google it! (http://lmgtfy.com/?q=isolated+RS485+using+optocouplers)

First result should give you an idea...

IMHO, LMGTFY tend to stop discussion  ;).

I also interested how to use optocoupler on RS485 - using specialized ic (iCoupler, IsoLoop, etc) is just too easy ;D.

Attached my isolated USB/RS232 to RS485 converter, here i use transformer with two secondary winding to power the circuit - would like to know other ways.

-ichan

OK, the thread is yours.

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.

Correct me if I am wrong.

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.


Ups.... and then i saw this thread is on PIC Basic Language board which i do not know anything about  :o.

-ichan

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

don't use CAN, it's super complicated.

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)

CAN controller has a complexity much more than UART has, I agree. I talked about usage and forgot about knowledge.

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.

MODBUS is an overkill here. CAN bus too.

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 culpa
2) I remember its scalability and built-in functionality that unloads software.