| View previous topic :: View next topic |
| Author |
Message |
JoaoSantos
Joined: 19 Jun 2007
Posts: 20
Location: Castelo Branco, Portugal
|
| hardware question |
 Posted: Tue Mar 04, 2008 9:44 am |
 |
|
Hello,
I have to connect several boards together, in a master/slave configuration. I will have one master and a total amount of 32 possible slaves. The maximum distance between master and slave is of 80 meters.
I was thinking on using a I2C bus with the 2 wires crossing all the slaves and with the slave address defined by hardware.
Am I going in the right direction?
Thank you |
|
 |
Guest
|
| 80 metre connection |
| Posted: Tue Mar 04, 2008 11:01 am |
|
|
You might consider RS-485 instead.Much better for the distance and noise immunity.Just as easy from the programming consideration.
Jay |
|
|
JoaoSantos
Joined: 19 Jun 2007
Posts: 20
Location: Castelo Branco, Portugal
|
|
| Posted: Tue Mar 04, 2008 11:12 am |
|
|
hello, thanks for the awnser.
I thougth of that, but can i share the RS485 connection? this is, can I use a bus shared by the 8 slaves without problems?
thanks |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Tue Mar 04, 2008 11:37 am |
|
|
| have a look at http://www.rs485.com/rs485spec.html. You can have a maximum of 32 listening devices on the same line. By adding repeaters this can be extended to hundreds. |
|
|
Humberto
Joined: 08 Sep 2003
Posts: 1215
Location: Buenos Aires, La Reina del Plata
|
|
| Posted: Tue Mar 04, 2008 11:41 am |
|
|
| Quote: |
I thougth of that, but can i share the RS485 connection? this is, can I use a bus shared by the 8 slaves without problems?
|
The RS-485 standard specifies up to 32 drivers and 32 receivers on a single (2-wire) bus.
The number can increase adding repeaters. We have systems running +180 MCU's simultaneously.
Humberto |
|
|
Guest
|
|
| Posted: Tue Mar 04, 2008 11:45 am |
|
|
Actually you can have up to 256 'lowpower' units online,though reality says you should 'break up' units into more manageable groups , especially if (WHEN) the communication wire breaks.
Jay |
|
|
JoaoSantos
Joined: 19 Jun 2007
Posts: 20
Location: Castelo Branco, Portugal
|
|
| Posted: Tue Mar 04, 2008 1:46 pm |
|
|
thank you all for your anwsers,
Just on (basic) doubt: the routines and protocol used in RS485, are the same of the RS232?
what i mean is: for the PIC point of view it's like i'm using RS232.
Thank you once more. |
|
|
RLScott
Joined: 10 Jul 2007
Posts: 465
|
|
| Posted: Tue Mar 04, 2008 2:01 pm |
|
|
| JoaoSantos wrote: | thank you all for your anwsers,
Just on (basic) doubt: the routines and protocol used in RS485, are the same of the RS232?
what i mean is: for the PIC point of view it's like i'm using RS232.
Thank you once more. |
No, there is a fundamental difference in the fact that RS485 is a half-duplex communication with a transmit enable signal that needs to be controlled by anyone trying to transmit on the shared bus. Many people have run into problems trying to control this enable signal with the correct timing.
However you may just have to do it, because 80 meters is not appropriate for I2C.
Robert Scott
Real-Time Specialties |
|
|
Guest
|
|
| Posted: Tue Mar 04, 2008 2:04 pm |
|
|
Yes, except you have one pin controlling whether a PIC xmits or rcvs. I think there is an example either in the CCS manual or in the examples
files......
I use another form of long distance serial that is hackersafe and impervious to the 'cut-wire-syndrome' so other's who use RS485 can better help you out.
jay |
|
|
JoaoSantos
Joined: 19 Jun 2007
Posts: 20
Location: Castelo Branco, Portugal
|
|
| Posted: Tue Mar 04, 2008 3:00 pm |
|
|
thank you all. this discussion was a real eye openner.
I will take all of this into consideration, and decide what's best. |
|
|
Humberto
Joined: 08 Sep 2003
Posts: 1215
Location: Buenos Aires, La Reina del Plata
|
|
| Posted: Tue Mar 04, 2008 3:00 pm |
|
|
| Quote: |
Just on (basic) doubt: the routines and protocol used in RS485, are the same of the RS232?
what i mean is: for the PIC point of view it's like i'm using RS232.
|
From the PIC point of view, handling RS485 is the same that handling RS232, except
the extra pin needed to handle the enable Tx/Rx of the transceiver. In most applications,
the pin #2 and #3 of the transceiver are wired together and are handled by the PIC pin
defined in the option "enable". Then let the compiler to do it's job.
#use rs232(baud=9600, xmit=PIN_C6,rcv=PIN_C7,enable=PIN_C5)
The standard doesn't mention anything regarding any special protocol. The main difference is in the physical layer and the way they drive the transmition lines, being RS232 a voltage controlled (+V/-V swing) and RS485 a differential current loop, being the last a high improvement in the common mode noise rejection. This feature is very important in data transmition lines running in severe electrical environments.
Humberto |
|
|
JoaoSantos
Joined: 19 Jun 2007
Posts: 20
Location: Castelo Branco, Portugal
|
|
| Posted: Tue Mar 04, 2008 5:00 pm |
|
|
| Humberto wrote: | | Quote: |
Just on (basic) doubt: the routines and protocol used in RS485, are the same of the RS232?
what i mean is: for the PIC point of view it's like i'm using RS232.
|
From the PIC point of view, handling RS485 is the same that handling RS232, except
the extra pin needed to handle the enable Tx/Rx of the transceiver. In most applications,
the pin #2 and #3 of the transceiver are wired together and are handled by the PIC pin
defined in the option "enable". Then let the compiler to do it's job.
#use rs232(baud=9600, xmit=PIN_C6,rcv=PIN_C7,enable=PIN_C5)
The standard doesn't mention anything regarding any special protocol. The main difference is in the physical layer and the way they drive the transmition lines, being RS232 a voltage controlled (+V/-V swing) and RS485 a differential current loop, being the last a high improvement in the common mode noise rejection. This feature is very important in data transmition lines running in severe electrical environments.
Humberto |
Thank you for another most usefull information.
But you lost me in the the pin #2 and #3 of the transceiver are wired together and are handled by the PIC pin
When you say transceiver you are refering to MAX483, for example?
I found this circuit , is it something
http://web.ukonline.co.uk/j.winpenny/pic/rs485.pdf
like this, or you are refering to something else? |
|
|
RLScott
Joined: 10 Jul 2007
Posts: 465
|
|
| Posted: Tue Mar 04, 2008 6:57 pm |
|
|
[quote="Humberto"] | Quote: |
...Then let the compiler to do it's job.
#use rs232(baud=9600, xmit=PIN_C6,rcv=PIN_C7,enable=PIN_C5)
|
I have never used the compiler's serial driver. I have always dealt directly with the PIC registers. So I am curious how the compiler "automatically" handles the enable signal. I have always found this to be the most difficult part of RS-485. It is easy to know when to turn it on - just before you start sending. But it is not so easy to know when to turn it off. You need to leave it on until the last character of a packet has completely shifted out of the PIC. This is not the same thing as the transmit holding register going empty, which causes an interrupt. The transmit holding register goes empty when it transfters its contents to the output shift register. But there is no interrupt telling you when the output shift register is done. There is a status bit that you can poll, but does that mean the compiler library function sits in a busy-loop polling to see when the output shift register goes empty?
Robert Scott
Real-Time Specialties |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Mar 04, 2008 7:13 pm |
|
|
Here's the code for PCH vs. 4.069:
| Code: |
... #use rs232(baud=9600, xmit=PIN_C6,rcv=PIN_C7,enable=PIN_C5)
0004: BCF TRISC.5
0006: BSF LATC.5 // Enable = high
0008: BTFSS PIR1.TXIF // Wait for TXREG empty
000A: BRA 0008
000C: MOVFF 06,TXREG // Put byte in TXREG
0010: NOP
0012: BCF TRISC.5
0014: BSF LATC.5 // Enable = high
0016: BTFSS TXSTA.TRMT // Wait until byte is sent
0018: BRA 0016
001A: BCF TRISC.5
001C: BCF LATC.5 // Enable = low
001E: GOTO 0048 (RETURN)
|
| Quote: | #include <18F452.h>
#fuses XT,NOWDT,PUT,BROWNOUT,NOLVP
#use delay(clock=4000000)
#use rs232(baud=9600, xmit=PIN_C6,rcv=PIN_C7,enable=PIN_C5)
//====================================
void main()
{
putc(0x55);
while(1);
} |
|
|
|
Humberto
Joined: 08 Sep 2003
Posts: 1215
Location: Buenos Aires, La Reina del Plata
|
|
| Posted: Tue Mar 04, 2008 7:58 pm |
|
|
Robert wrote:
| Quote: |
So I am curious how the compiler "automatically" handles the enable signal. I have always found this to be the most difficult part of RS-485.
|
Thanks to the code posted by PCM Programmer  you will see the code generated by CCS Compiler.
The "enable" option feature had been implemented in the first quarter of 2003 close-to PCM Version 3.136
Robert wrote:
| Quote: |
You need to leave it on until the last character of a packet has completely shifted out of the PIC.
|
It is self-answered looking in the .asm code generated.
JoaoSantos wrote:
| Quote: |
But you lost me in the the pin #2 and #3 of the transceiver are wired together and are handled by the PIC pin
When you say transceiver you are refering to MAX483, for example?
|
Yes the MAX483 is an RS485 transceiver. The oldest -and most popular- is the SN75176 made by National.
Most manufacturers have its own version.
Analog Devices: ADM2483
Linear Technology: LTC1685/6/7
Maxims: MAX3080/9 MAX3280 MAX3362 MAX3430/60/64/80 ,etc.
Texas Instruments: SN65HVD1176
SipexCorporation: SP481
Intersil: ISL41387
.........................
In the following thread you will find an interesting RS485 discution.
http://www.ccsinfo.com/forum/viewtopic.php?t=25720&highlight=rs485
Humberto |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
