Sonsivri
 
*
Welcome, Guest. Please login or register.
Did you miss your activation email?
March 29, 2024, 12:52:22 00:52


Login with username, password and session length


Pages: [1]
Print
Author Topic: PIC to PIC _ RS485  (Read 13024 times)
0 Members and 1 Guest are viewing this topic.
7hills
Inactive

Offline Offline

Posts: 5

Thank You
-Given: 7
-Receive: 1


« on: August 22, 2014, 11:08:04 11:08 »

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.
Logged
Cain
Junior Member
**
Offline Offline

Posts: 81

Thank You
-Given: 165
-Receive: 102


« Reply #1 on: August 22, 2014, 11:46:46 11:46 »

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.
« Last Edit: August 22, 2014, 11:50:54 11:50 by Cain » Logged
zab
Active Member
***
Offline Offline

Posts: 137

Thank You
-Given: 25
-Receive: 58


« Reply #2 on: August 23, 2014, 07:01:19 07:01 »

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.
Logged
fernandodiaz
Junior Member
**
Offline Offline

Posts: 73

Thank You
-Given: 1
-Receive: 18


« Reply #3 on: August 23, 2014, 03:56:43 15:56 »

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
Logged
biko4710
Newbie
*
Offline Offline

Posts: 33

Thank You
-Given: 45
-Receive: 40


« Reply #4 on: August 24, 2014, 12:40:15 00:40 »

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.
Logged
cako
Newbie
*
Offline Offline

Posts: 10

Thank You
-Given: 7
-Receive: 7


« Reply #5 on: September 18, 2014, 07:51:51 19:51 »

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
Logged
zab
Active Member
***
Offline Offline

Posts: 137

Thank You
-Given: 25
-Receive: 58


« Reply #6 on: September 20, 2014, 06:11:01 18:11 »

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
« Last Edit: September 20, 2014, 06:46:04 18:46 by zab » Logged
flo0319
Junior Member
**
Offline Offline

Posts: 81

Thank You
-Given: 7
-Receive: 17


« Reply #7 on: September 20, 2014, 09:51:40 21:51 »

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

Regards
Logged
bobcat1
Senior Member
****
Offline Offline

Posts: 295

Thank You
-Given: 4135
-Receive: 89


« Reply #8 on: September 21, 2014, 07:51:14 07:51 »

@Biko4710

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

Bobi
Logged
metal
Global Moderator
Hero Member
*****
Offline Offline

Posts: 2420

Thank You
-Given: 862
-Receive: 678


Top Topic Starter


« Reply #9 on: September 21, 2014, 08:02:31 08:02 »

Google it!

First result should give you an idea...
Logged
Ichan
Hero Member
*****
Offline Offline

Posts: 833

Thank You
-Given: 312
-Receive: 392



WWW
« Reply #10 on: September 21, 2014, 09:03:20 21:03 »

Google it!

First result should give you an idea...

IMHO, LMGTFY tend to stop discussion  Wink.

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

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
Logged

There is Gray, not only Black or White.
metal
Global Moderator
Hero Member
*****
Offline Offline

Posts: 2420

Thank You
-Given: 862
-Receive: 678


Top Topic Starter


« Reply #11 on: September 21, 2014, 09:56:05 21:56 »

OK, the thread is yours.
Logged
Signal
Active Member
***
Offline Offline

Posts: 197

Thank You
-Given: 111
-Receive: 81



« Reply #12 on: September 22, 2014, 10:44:36 10:44 »

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.


Logged

Give a right name to a right game and play it right
Ichan
Hero Member
*****
Offline Offline

Posts: 833

Thank You
-Given: 312
-Receive: 392



WWW
« Reply #13 on: September 22, 2014, 06:47:02 18:47 »

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.

OK, the thread is yours.

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

-ichan
Logged

There is Gray, not only Black or White.
flo0319
Junior Member
**
Offline Offline

Posts: 81

Thank You
-Given: 7
-Receive: 17


« Reply #14 on: September 22, 2014, 08:49:01 20:49 »

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.
Logged
Gallymimu
Hero Member
*****
Offline Offline

Posts: 704

Thank You
-Given: 151
-Receive: 214


« Reply #15 on: September 23, 2014, 05:30:46 05:30 »

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)
Logged
Signal
Active Member
***
Offline Offline

Posts: 197

Thank You
-Given: 111
-Receive: 81



« Reply #16 on: September 23, 2014, 11:17:48 23:17 »

<...> because CAN have a lot more bigger barrier to entry on learning it, at least on me.
don't use CAN, it's super complicated.
CAN controller has a complexity much more than UART has, I agree. I talked about usage and forgot about knowledge.

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.

I'd suggest using MODBUS.
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.
« Last Edit: September 23, 2014, 11:41:30 23:41 by Signal » Logged

Give a right name to a right game and play it right
Pages: [1]
Print
Jump to:  


DISCLAIMER
WE DONT HOST ANY ILLEGAL FILES ON THE SERVER
USE CONTACT US TO REPORT ILLEGAL FILES
ADMINISTRATORS CANNOT BE HELD RESPONSIBLE FOR USERS POSTS AND LINKS

... Copyright © 2003-2999 Sonsivri.to ...
Powered by SMF 1.1.18 | SMF © 2006-2009, Simple Machines LLC | HarzeM Dilber MC