Searching \ for 'RS-485' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/io/serials.htm?key=rs%2D485
Search entire site for: 'RS-485'.

Truncated match.
PICList Thread
'RS-485'
1996\04\10@034608 by ugenio Angel Martin Cuenca

flavicon
face
To all PICLIST users:
       I am sorry if these are a repetitive  question, but i suscribe to
the PICLIST yesterday.=20
       I need made and RS-485 multi-drop LAN, using severals modules based
on PIC's.
Could you please inform me about any books, papers, or any bibliografy on
RS-485 and books, papers, over communications protocol, asynchronous or
synchronous.
Many thanks in advance.

Dr. Eugenio Martin Cuenca
Dpto. de Biolog=EDa Animal y Ecolog=EDa
Facultad de Ciencias
Universdiad de Granada - Spain.
Email:spam_OUTemartinTakeThisOuTspamgoliat.ugr.es

Research Group of Chronobiology and Ecophysiology of Fishes
=20

1996\04\10@091542 by mfahrion

flavicon
face
> Could you please inform me about any books, papers, or any bibliografy on
> RS-485 and books, papers, over communications protocol, asynchronous or
> synchronous.
> Many thanks in advance.
>

We have a brief app note on RS-485 on our web site at
http://www.bb-elec.com.  Also, there are many good app notes in the back of
the National Semiconductor Interface data book.

-mike
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Mike Fahrion                .....mfahrionKILLspamspam@spam@bb-elec.com      http://www.bb-elec.com/
B&B Electronics Mfg Co      ph.(815) 433-5100 ext.215    fax (815) 434-7094
707 Dayton Road                 PO Box 1040                  Ottawa IL 61350
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

1996\04\12@034242 by eza Asensio, Roberto

flavicon
face
Hi Eugenio and all,

Saludos, de otro miembro de esta lista en Espa=F1a. (Greetings, from=20
other list member at Spain).

>        I need made and RS-485 multi-drop LAN, using severals modules based
>on PIC's.
>Could you please inform me about any books, papers, or any bibliografy on
>RS-485 and books, papers, over communications protocol, asynchronous or
>synchronous.

You can find a very good description and a lot of tips and tricks,=20
for the "phisical layer" of protocol (RS-485), in the following book
of Texas Instrument:

  RS-422 and RS-485 Interface Circuits
  Data transmision and Control Circuits
  Aplication and Data Book  (Year 92)
  SLLAE01

Best regards:
=20
--
Roberto Deza Asensio               |rdezaspamKILLspampopmail.cti.unav.es
Universidad de Navarra             |.....rdezaKILLspamspam.....cun.unav.es
Centro de Proceso de Datos         |EraseMErdaspam_OUTspamTakeThisOuTcpd.unav.es


'RS-485'
1996\09\11@214752 by Eric & Sophie
flavicon
face
Hi !

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.

1996\09\12@033644 by Edwin Baaij

flavicon
face
Hi Eric,

I don't think there's one real standard to use. The first think you've to
decide is what you want to send over. Pure binaire packets, or just ASCII
command to commercially bought measurement equipment. In the last case you
could take a look on the ADAM-4000 serie from Advantech. They have made all
kind of adressable device like AD, IO, timers, adressable RS232 ect.
If you want to go binairy it's another case. ADAM is total useless for this
transport :-(. Before the decision fell to buy the ADAM stuff I already
invented a protocol to implement. The 'problem' with (little) PIC in general
is that it doesn't have much ram. If you send a binaire packet, you have to
receive it totaly before you can analyse it. That would really restrict the
length of the packets.
So I thought of this:

Adress packet: length always 6 bytes

byte 1: device ID I
byte 2: device ID II
byte 3: number of bytes of data packet
byte 4: number of bytes of data packet
byte 5: checksum
byte 6: checksum

Data packet:  length variable always even number

byte 1: Command to execute
byte 2: data
byte 3: data
 |      |
byte  : status
byte  : status
byte  : checksum
byte  : checksum

The idea behind the two packages is that if a device detects it's adressed
for him, it deletes the first package (except number if bytes) And has
memory free for the data package. If it's not adressed for him it does NOT
store the data-packet, just simply count down the number of bytes. In this
way also very large packets can be send to a computer or an other RAMfull
device.

Incase of binaire transportation to multiple devices there's always a change
that a header will be recognized in a data-packet. In this proposal the
chance is 256^-6. Hope I've got a bigger chance to win a lottery ;-)


Just an idea....
Edwin




Edwin Baaij  (Electronic Engineer)
*********************************************************************
University of Amsterdam                 phone:  +31-20-5256346
Van der Waals,- ZeemanInstitute         fax:    +31-20-5255877
Valckenierstraat 65-67                  e-mail: baaijspamspam_OUTphys.uva.nl
1018 XE Amsterdam
*********************************************************************

1996\09\12@053931 by Ray Gardiner

flavicon
face
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

{Quote hidden}

Ray Gardiner, Shepparton, Victoria, Australia       @spam@rayKILLspamspamnetspace.net.au

1996\09\24@031057 by Mark G. Forbes

flavicon
face
>>[....]It is
>>intended to be a multi-drop system with each slave having a unique node
>>address and only responding when polled.

>Use RS-485 transceivers instead.  RS-485 is designed to be
>multidrop.

>Linear Technology has a good range of devices.

I would strongly advise *against* using the Linear Technology
devices. I was unfortunate enough to substitute in an LTC490 for
a SN75179 TI driver. The LT parts would latch up in the field,
crowbarring the power supply and either destroying the board or
at least completely failing.

The Texas Instruments part (SN75179) was robust but power-hungry.
We finally went with the Maxim MAX490, which has the power-reduced
appetite of a CMOS device, without the latchup and failures of the
LT device.

LT maintained that it was our design at fault, not their parts,
even though everybody *else's* part worked just fine in our application.
And even though it was inside a metal cabinet, with only a foot of
wire between the transceiver and the other end. I've been a little
leery of LT ever since....
KILLspamforbesmKILLspamspampeak.org   http://www.peak.org/~forbesm
Mark G. Forbes
"Outside of a dog, a book is a man's best friend.
Inside of a dog, it is too dark to read."         - Groucho Marx

1996\09\24@192113 by Robert Lunn

flavicon
face
>I would strongly advise *against* using the Linear Technology
>devices. I was unfortunate enough to substitute in an LTC490 for
>a SN75179 TI driver. The LT parts would latch up in the field,
>crowbarring the power supply and either destroying the board or
>at least completely failing.
>
>LT maintained that it was our design at fault, not their parts,
>even though everybody *else's* part worked just fine in our application.
>And even though it was inside a metal cabinet, with only a foot of
>wire between the transceiver and the other end. I've been a little
>leery of LT ever since....

       This divergence of experience happens suprisingly often.

       I have used LT parts for many years, including the '490,
       with no problems (excepting an unfortunate experience with
       a switching capacitor chip).

       I am consistently impressed by the quality, performance,
       and reliability of LT parts, and recommend them to others
       with confidence.

       But all of us have experienced a design where supposedly
       pin compatible products from different manufacturers gave
       different results in the field.

___Bob

1996\09\24@214836 by Greg Young

flavicon
face
.>I would strongly advise *against* using the Linear Technology
>devices. I was unfortunate enough to substitute in an LTC490 for
>a SN75179 TI driver. The LT parts would latch up in the field,
>crowbarring the power supply and either destroying the board or
>at least completely failing.
>Mark G. Forbes

I work for a company that uses 1000's of LTC485 each year without problem.
It is worth noting, however, that some LTC parts do have latch-up
conditions, but these are generally well documented. If the suggested
precautions are taken, the parts are reliable. A possible reevaluation of
your design will expose your violation of LTC's design rules.

I have been experiencing a similar possible latch-up problem with cheaper
charge-pumped RS232 level converters (such as ICL and AD). Any experiences?

1996\09\25@095456 by Keith Kotay

flavicon
face
>
> .>I would strongly advise *against* using the Linear Technology
> >devices. I was unfortunate enough to substitute in an LTC490 for
> >a SN75179 TI driver. The LT parts would latch up in the field,
> >crowbarring the power supply and either destroying the board or
> >at least completely failing.
> >Mark G. Forbes
>
> I work for a company that uses 1000's of LTC485 each year without problem.
> It is worth noting, however, that some LTC parts do have latch-up
> conditions, but these are generally well documented. If the suggested
> precautions are taken, the parts are reliable. A possible reevaluation of
> your design will expose your violation of LTC's design rules.
>
> I have been experiencing a similar possible latch-up problem with cheaper
> charge-pumped RS232 level converters (such as ICL and AD). Any experiences?
>
I have been using a Harris ICL232 & a National DS8921 to do
RS-232 to RS-422 conversion.  It's been working fine for
weeks now and it's on a solderless breadboard.  At around
$5 in parts it's an inexpensive converter.

Keith

1996\09\26@033901 by Jim Robertson

flavicon
face
>I have been experiencing a similar possible latch-up problem with cheaper
>charge-pumped RS232 level converters (such as ICL and AD). Any experiences?
>
Yer, the ICL232 is a dog of a thing and doesn't like to work at 57600 baud.
The standard MAX232 parts gave no problems.

-Jim


'RS-485'
1996\12\02@040235 by Eugenio Martin Cuenca
flavicon
face
Hi all,

I am working in the construction of a microcontroller module based in PIC
16C84 or Micromint PICStic, with RS-485 (75176) interface driver. Y need a
net RS-485 of several modules.

       Could any help me, in the source code of the RS-485 driver for the Net,
in
Microchip assembler or PBASIC compiler ?.

       The PC Host work with Visual BASIC Windows 3.0 professional.

       Many thank for the help.

       Prof, Eugenio Martin Cuenca
       Dpto. de Biologia Animal
       Facultad de Ciencias
       Universidad de Granada
       18071 - Granada - Spain


'RS-485'
1997\04\01@201302 by bstewart
flavicon
face
Does anyone have any experience/knowledge on implementing RS-485 using a
PIC16C6X?  One of my questions regards the way each node is assigned a
unique address.  I have done PIC projects using the CCS PCM "C"
compiler, but have never anything with communication.

Any help or suggestions that the members of this list can provide will
be greatly appreciated.

Sincerely,

Steve Stewart


'RS-485'
1997\09\15@162839 by David Wong
picon face
I'm not that familar with Serial communications.  I'm trying to write code
for a pic to communicate RS-485 to other serial devices.  I'm confused on
what the BRGH bit in the TXSTA register does.  I know that it selects between
high and low speed.  But what constitutes high speed 19.2K, 38.4K, etc. what
constitutes low speed 1200 baud, am I just really confused.  Could somebody
please help.
Thanks
David Wong

1997\09\16@005612 by mikesmith_oz.nosp*m

flavicon
face
On 15 Sep 97 at 16:26, David Wong wrote:

> I'm not that familar with Serial communications.  I'm trying to
> write code for a pic to communicate RS-485 to other serial devices.
> I'm confused on what the BRGH bit in the TXSTA register does.  I
> know that it selects between high and low speed.  But what
> constitutes high speed 19.2K, 38.4K, etc. what constitutes low speed
> 1200 baud, am I just really confused.  Could somebody please help.

Avoid it if you can, by using crystals that will let you use BRGH = 0
AND have good bitrate accuracy.

Trolling the list provided the following snippet -

> > The following commonly available crystal frequencies give you 0%
> > error on the common baud rates : 1.8432MHz, 2.4576 MHz, 3.6864 MHz, 4.9152
MHz,  11.0592 MHz

You may get away with BRGH = 1, but MicroChip advises that errors may
occur with most of their chips, the 66,67,76,77 series excepted.  I'd
say if you aren't familiar with serial comms, then try and avoid one
more potential problem.
MikeS
<mikesmith_oz@nosp*m.relaymail.net>
(remove the you know what before replying)


'RS-485'
1999\04\13@142424 by Jay Mielke
flavicon
face
Hello fellow bitheads!!!

Has anyone out there used the 16C74a with an RS-485 2-wire network?  If so,
how is it any different than using RS232 (except for levels, of course).  Am
I required to use addressing?  Would I decode the addressing in software or
hardware?

Thanx in advance,

Jay Mielke

RemoveMEjayTakeThisOuTspamticon.net

1999\04\13@143125 by Dave VanHorn

flavicon
face
> Has anyone out there used the 16C74a with an RS-485 2-wire network?  If
so,
> how is it any different than using RS232 (except for levels, of course).
Am
> I required to use addressing?  Would I decode the addressing in software
or
> hardware?


Generally, 485 nets use addressing, either some type of polling scheme, or
something like slotted aloha. AFAIk, there is no chip that handles
addressing for you, all they are is level converters, and drivers. You can
use a uart to talk over 485, but the start and stop bits are rather
redundant.

485 is a standard for the hardware level. The protocol and data structure
are all up to you.

1999\04\13@144053 by Wagner Lipnharski

picon face
RS485 is just a physical layer, as the RS232.

It only rules about how the electrical signal would exist on the wires,
nothing else, nothing related to addressing or something else.

RS232 is an unbalanced system, it uses Ground and a wire to carry the
signal. Any EMI (Electro Magnetic Interference) that "touch" the signal
wire (or ground) would be incorporated to the signal itself, and can
cause communication problems.

RS485 is a balanced system, there is no ground involved, except for the
cable shielding, but there is two wires for the signal (RS232 uses only
one).  Each wire transport a 180¡ rotate signal.  It means that if an
EMI touch the wires, it would generate a voltage with the same polarity
on both wires.  The RS485 receiver chip simple looks for differential
signals, not signal with the same polarity (0¡), so it is automatically
eliminated, and the valid signal is transfered with much more
reliability than RS232. Again, the signal itself has no relation to
ground, only related to the other wire, inverted signal polarity.

How you would use the RS485 is another story.  You can implement several
different protocols, using addressing, multi-drop or something else you
can invent by yourself. All of this can be done either in RS232 or
RS485, doesn't matter so much.

RS485 as you can see, is much more indicated for noisy and connections
with distances bigger than 2 to 3 meters.  It requires a two conductors
shielded cable.

Wagner

Jay Mielke wrote:
{Quote hidden}

1999\04\13@223528 by TrionicIan

picon face
> Has anyone out there used the 16C74a with an RS-485 2-wire network?  If so,
>  how is it any different than using RS232 (except for levels, of course).
Am
>  I required to use addressing?  Would I decode the addressing in software or
>  hardware?
>
Most significantly, RS485 is half duplex ... you need to control the Rx/Tx
mode of the buffer chip as well as the actual Rx & Tx signals (ie: three pins
from the PIC).
As to addressing or whatever ... totally dependant on what software protocol
you decide to write; typically you would have a master/slave type where all
devices except one are receiving, unless they receive a request for data from
the one master device.

Ian C.

1999\04\14@040608 by Dr. Imre Bartfai

flavicon
face
Hi,
one can  use the SN75176 for level conversion. Keep in mind, that RS-485
is simplex, so you MUST handle the DI/DO bits also (fortunately they can
be tied bcus one of them is inverted).
Imre


On Tue, 13 Apr 1999, Dave VanHorn wrote:

{Quote hidden}

1999\04\15@151910 by Isto Virtanen

picon face
At 13:24 13.4.1999 -0500, you wrote:

>Has anyone out there used the 16C74a with an RS-485 2-wire network?  If so,

You could check PICNET+ at http://www.picpoint.com.

Most of the documentation is in italian, but some has been translated
already.
I personally plan to use picnet for my house project.

isto

1999\04\19@082748 by Nigel Orr

flavicon
face
At 13:24 13/04/99 -0500, you wrote:
>Has anyone out there used the 16C74a with an RS-485 2-wire network?  If so,
>how is it any different than using RS232 (except for levels, of course).  Am
>I required to use addressing?  Would I decode the addressing in software or
>hardware?

As others have said, 485 is just an electrical spec- how you sort out
sending real data and handling the bus is up to you!  I'll give you a brief
description of a system I've just completed, which might be a place to start.

The system is a parallel to serial to parallel converter- we have some
equipment (DSP board) which needs a parallel port connection to a PC, but
the PC is on a boat and the DSP is on the sea bed, about 100m away- no good
for a parallel link...

The PIC reads data from the parallel port and sends it on the USART.  The
RS-485 hardware is a MAX-485 chip, with the transmit and receive enable
pins tied together, and connected to a PIC pin, and the transmit and
receive data pins connected to RC7 & RC6.  Each data byte is acknowledged
with an acknowledge byte, parity is not implemented for error checking, so
the parity bit is used as a data/status flag.

The driver is TX-enabled just before loading TXREG and RX-enabled once the
data has been sent.

The higher level protocols are already in the DSP, which makes things
easier, and avoids contention.

Hope that helps,

Nigel
--
Nigel Orr                  Research Associate   O   ______
       Underwater Acoustics Group,              o / o    \_/(
Dept of Electrical and Electronic Engineering     (_   <   _ (
    University of Newcastle Upon Tyne             \______/ \(


'RS-485'
1999\12\14@103022 by ali_goksu
flavicon
face
Hi All,

I have designed an RS-485 capable device with PIC16F877's and MAX485CPA's. PIC16F877 has a built-in USART. I used CCS C PCM compiler for programming. My intent was to built an RS-485 network with these devices and interface them to a PC. Device is working well except RS-485 side.

The connections between PIC and MAX485 is as follows :

1.RX pin on PIC connects to RO pin on MAX485.
2.TX pin on PIC connects to DI pin on MAX485.
3.RE pin on MAX485 connects to GND.
4.DE pin is driven by an output from PIC.
5.A termination resistor of 220 Ohm  is present between A and B pins of MAX485.

For the transmit of data, I am using built-in RS232 function of CCS C Compiler like, printf, putchar, etc.

I don't know what is wrong here. Any ideas are wellcome.

King Regards,

Ali GOKSU
Software Engineer
__________________________________________________________________
Make A Buck Or Two @ TheMail.com - Free Internet Email
Sign-up today at http://www.themail.com/ref.htm?ref=16449

1999\12\15@015811 by Dr. Imre Bartfai

flavicon
face
Hi,
I know only SN75176 but I guess it is virtually identical. Here is what I
suspect:

do not tie RE to gnd. As RS-485 is a half-duplex device, this idea is
definitely bad. At that chip I mentioned one of RE and DE is inverted, so
it is a good practice connect them together and so control them. Such way,
the device will either receive, or transmit.

I hope this helps.

Imre


On Tue, 14 Dec 1999, Ali GOKSU wrote:

{Quote hidden}

1999\12\15@134848 by Severson, Rob

flavicon
face
> -----Original Message-----
> From: Dr. Imre Bartfai [TakeThisOuTrootEraseMEspamspam_OUTPROF.PMMF.HU]
>
> Hi,
> I know only SN75176 but I guess it is virtually identical.
> Here is what I
> suspect:
>
> do not tie RE to gnd. As RS-485 is a half-duplex device, this idea is
> definitely bad.

Not bad. It just means that you receive everything that you transmit.
You can either ignore this, or use it as a bus integrity check.

{Quote hidden}

So does the "built-in RS232 functions of the CCS C Compiler" enable the
driver before transmit? I suspect not.

You need to turn on the driver, transmit all of your bits, and then turn
off the driver (to receive). This is more housework than the "typical"
RS232 routines do.

Have fun.

-Rob


{Quote hidden}

1999\12\15@143032 by King, Jonathan

flavicon
face
> > For the transmit of data, I am using built-in RS232
> function of CCS C Compiler like, printf, putchar, etc.
> >
> > I don't know what is wrong here. Any ideas are wellcome.

>So does the "built-in RS232 functions of the CCS C Compiler" enable the
>driver before transmit? I suspect not.

>You need to turn on the driver, transmit all of your bits, and then turn
>off the driver (to receive). This is more housework than the "typical"
>RS232 routines do.

The #USE RS232 directive in CCS C allows you to define a pin as an enable
output for use with RS-485.
An example would be:
#use rs232(baud=9600, xmit=PIN_B1, rcv=PIN_B2, enable=PIN_B3)
where PIN_B3 is set high during transmit.
I have not personally used the function, so I cannot verify that it actually
works as expected.

Hope this helps,
Jonathan King

1999\12\15@145532 by Severson, Rob

flavicon
face
{Quote hidden}

Formal: I stand corrected. Thank you for your information.

Informal: Coooool! This shows that someone at CCS has real-world
experience! ;-)



>
> Hope this helps,
> Jonathan King
>

1999\12\15@172937 by Stuart O'Reilly

flavicon
face
Also, in the pic there is a register that has a receive overflow bit.
You should have a routine to check this bit, if it is set, do to an
overflow(I think it's set) you'll need to read your rx register twice to
empty it and the clear the overflow bit. Your termination resistor
should be aprox 110 ohm at both ends of the cable. Also I think it would
be wise to put in 2 resistors for critical biasing (a aprox 600 ohm
between pin 5 and 7 and another between 6 and 8 of the max chip), alot
of people have said to me that they have had it working fine without
them but I am yet to be able to get my setup to work faultlessly without
them.
Regards
Stuart O'Reilly

Dr. Imre Bartfai wrote:
{Quote hidden}

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...