Searching \ for '[PIC]: RS485 code?' 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/microchip/ios.htm?key=rs485
Search entire site for: 'RS485 code?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: RS485 code?'
2001\02\24@200953 by James Newton

face picon face
Does anyone have any RS485 code they would be willing to share? The archive
seems to be a bit bare. There is only one code sample since the beginning of
the list in December of 1993.
www.piclist.com/techref/postbot.asp?by=time&id=piclist/1999/11/02/101
717a

Is it true RS232 and RS485 are both just signal specifications? They both
use standard async serial protocols? I know that the practical differences
of 232 vs 485 are:
- single-ended versus differential
- sender-receiver only versus multidrop possible
but doesn't RS485 typically use a 9bit address byte protocol for multidrop
communications?

I have a few references:

'The Art and Science of RS-485'
http://www.chipcenter.com/circuitcellar/july99/c79bppdf.pdf

"Controlling the Transmit Enable Line on RS-485 Transceivers" Aug'99
Embedded Systems Programming
http://www.embedded.com/1999/9908/

But no book recommendations.

Any information appreciated. I'm trying to fill out the page at
http://www.piclist.com/microchip/rs485.htm


James Newton, PICList Admin #3
spam_OUTjamesnewtonTakeThisOuTspampiclist.com
1-619-652-0593 phone
http://www.piclist.com

----- Original Message -----
From: Kyodo Comunicaciones <.....kyodolabKILLspamspam@spam@infonegocio.com>
To: <jamesnewtonspamKILLspampiclist.com>
Sent: Friday, February 23, 2001 10:45
Subject: Form posted from Mozilla


input=
output=
desc=RS-485 serial communications software
cpu=16F871

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body


2001\02\24@212150 by severson

flavicon
face
James:

Take a look at http://www.lvr.com and the book by Jan Axelson called "Serial Port
Complete".

-Robert Severson
http://usbsimm.home.att.net
http://www.jged.com
http://www.annatechnology.com

> {Original Message removed}

2001\02\24@222702 by steve

flavicon
face
> Is it true RS232 and RS485 are both just signal specifications? They both
> use standard async serial protocols?

RS-485 is purely a hardware spec and goes as far as saying that
the signal rate can be up to 10Mbit/sec so you better be able to
cope with the rise times. After that it is up to you.
It says that you must be able to cope with contention and not blow
up and that a driver must be able to drive the appropriate levels into
32 unit loads*.

RS-232 describes the hardware to the same extent as RS-485
(voltages, impedances, etc). It also defines the function of the
interface signals. ie. RI - when on, the phone is ringing, DTR - when
on, the device is powered on and ready to do things.
It describes the handshake signals for both full and half duplex
arrangements but other than that, what you send down the Rx and
Tx lines is outside the spec. It doesn't care if it is synchronous or
async (there are pins defined for sync clocks), bit rate (other than
the max signalling rate), number of bits, parity, start and stop bits.
They are all outside of the RS-232 standard.

*The standard refers to unit loads for RS-485. These are not nodes.
Nearly all RS485 transceivers available are 0.1-0.2 unit loads so
you can have many more than 32 nodes.

Another misconception is that you can listen while you send and
determine if the message got through without collision. Not so.
If you get different data back, you can say that there was a
collision but if get the same data back, you can't say that there
was no collision with any certainty as a high signal vs. a low signal
results in an undefined value.Therefore, the technique serves no
useful purpose but you see a lot of people proclaim this as error
checking.

> but doesn't RS485 typically use a 9bit address byte protocol for multidrop
> communications?

That's outside the RS485 spec, but it is a bus best suited to a
Master/Slave protocol (or extended to a token based system)
rather than a collision detection.
One way to do that is to use the 9-bit protocol. The advantage is
that you only have to deal with data that is addressed to you.
This can be useful if there is a lot of data going up and down the
bus that your node isn't interested in. OTOH, depending on the
implementation, you may not be able have addresses for multiple
functions and/or broadcast addresses.


Steve.
======================================================
Steve Baldwin                Electronic Product Design
TLA Microsystems Ltd         Microcontroller Specialists
PO Box 15-680, New Lynn      http://www.tla.co.nz
Auckland, New Zealand        ph  +64 9 820-2221
email: EraseMEstevebspam_OUTspamTakeThisOuTtla.co.nz      fax +64 9 820-1929
======================================================

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2001\02\25@113704 by Olin Lathrop

face picon face
> Is it true RS232 and RS485 are both just signal specifications? They both
> use standard async serial protocols? I know that the practical differences
> of 232 vs 485 are:
> - single-ended versus differential
> - sender-receiver only versus multidrop possible
> but doesn't RS485 typically use a 9bit address byte protocol for multidrop
> communications?

The architectural difference between RS-232 and RS-485 is that 232 is a
bi-directional point to point link, whereas 485 is a single channel bus.
RS-232 can also carry additional signals used for flow control and modem
control.

Electrically, each 232 signal uses a single wire with symmetric voltages
about a common ground wire.  485 uses two wires to carry the single signal
differentially.  Both wires use 0 to 5 volts, with the two wires being
driven opposite.  The purpose of this is to provide noise immunity, because
much of the common mode signal can be rejected by the receiver.

Both 232 and 485 use the same asynchronous encoding of individual bytes.
This is the familiar start bit, followed by data bits (usually 8), followed
by stop bits (usually 1 nowadays).  Both the transmitter and receiver have
to agree on the bit rate in advance.  All timing within a byte is relative
to the leading edge of the start bit.  The PIC USART module was deliberately
designed to support this encoding in its asynchronous (UART) mode.  The low
level PIC code is the same for both 232 and 485 because it is transmitting
and receiving bytes via the UART (or a software UART).

The big difference to the software is that only one device on a 485 bus can
transmit at a time, whereas there are separate dedicated transmit and
receive channels for the single device at the other end of a 232 link.
There must also be external hardware that enables driving the bus when
transmitting.  This hardware is usually controlled from a separate PIC pin,
but there are also some "automatic" schemes.

The RS-485 standard (well sortof, "RS" actually stands for "recommended
standard") defines how to transmit and receive bytes to/from the bus
electrically.  Issues like flow control, collision avoidance, and data
reliability are left completely as an exercise to the implementer.  In a
pure RS-485 system, these have to be dealt with in the protocol.  As you can
imagine, there are lots of ways of dealing with this, and the right choice
depends on the particular system.  The solution often envolves wrapping data
into packets, each with a checksum, and some kind of ACK/retry scheme.  So
far I've dealt with collision avoidance by having a single master with all
other bus devices being slaves that only talk when asked to by the master.
Note that this can still give the appearance to upper levels of slaves
initiating data transfer if the master polls each slave often enough (this
is also how USB works, by the way).

Each RS-485 system is different, and therefore probably requires a different
protocol.  You inquiry to the PIC list has prompted me to put some RS-485
information on my PIC development resources web page.  This includes an
excerpt of the protocol specification for one real-world system, provided as
an example.  See http://www.embedinc.com/pic.

> Does anyone have any RS485 code they would be willing to share? The
archive
> seems to be a bit bare.

I've got RS-485 code, but it would take too much effort to remove the
proprietary parts that my customers don't want to tell the world about their
systems.  I also think that this is a pretty large chunk of code to expect
to get for free.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, @spam@olinKILLspamspamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestKILLspamspammitvma.mit.edu


2001\02\25@141455 by Byron A Jeff

face picon face
{Quote hidden}

Which is a primary difference between the two. The other difference is that
RS-485 only defines a single balanced pair, while RS-232 (EIA-232C is the
official standard name IIRC) defines signalling functions beween the DTE and
DCE. This is where RS-485 is somewhat incomplete.

Think of RS-485 as a multidrop 3 wire RS-232 interface. No signalling, no
flow control, compounded by adding multidrop and contention.

>
> Another misconception is that you can listen while you send and
> determine if the message got through without collision. Not so.
> If you get different data back, you can say that there was a
> collision but if get the same data back, you can't say that there
> was no collision with any certainty as a high signal vs. a low signal
> results in an undefined value.Therefore, the technique serves no
> useful purpose but you see a lot of people proclaim this as error
> checking.

Absolutely. It's not Ethernet where collision detection is built into the
spec. And of course EIA-232C doesn't have collision problems because it's
point to point and full duplex.

>
> > but doesn't RS485 typically use a 9bit address byte protocol for multidrop
> > communications?
>
> That's outside the RS485 spec, but it is a bus best suited to a
> Master/Slave protocol (or extended to a token based system)
> rather than a collision detection.

That's right. But it's a slow mechanism for contention resolution especially
if you have a lot of nodes and they in fact need to do constant or near
constant communication. This is compounded by the fact that 9 bit signalling
is limited to the async speed of the nodes. Even at 230kbits/S it takes
48 uS to address a node.

I've been thinking about a design for RS-485 signalling for a while. It
requires a couple of things:

1) Add a second pair for signalling.
2) High resolution timing for the nodes.

Essentially each cycle would have a negotiation phase followed by no contention
data transfer. Each node would be assigned a negotiation time slot. The
preceeding node would start the negotiation phase by blinking the signal
channel. Each node would then wait until its negotiation slot comes up.
If the signal channel is clear and the node wishes the transmit, it locks up
the signalling channel indication to all who follow that the the channel is
occupied. The winner can then go on to transmit on the data channel with
a gurantee of no contention.

To prevent starvation, after transmitting, the winner moves to a secondary
slot which comes after the normal slots. The transmitter will stay in that
secondary slot as long as there are primaries that want to transmit. If no
primary takes the channel (because either they don't need to transmit or
because they've all moved to secondary time slots), then all the secondaries
get to move back to their primary slot. In this way it's fair even if
everyone is busy and wants to transmit all the time.

Since it's high resolution timing, the slots can be as small as one timer
tick on the slowest node (1 uS for 4 Mhz nodes) and can be independant of
the transmit speed (so even 9600 BPS nodes can be selected really quickly
instead of 1.1 ms using 9 bit addressing). The signalling change and the
slot timeout can be interrupt driven for low overhead.

Implementing this is on my list of things to do, but it probably will be
later this year before I get a chance to implement.

BAJ

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


2001\02\25@145155 by Douglas Wood

picon face
It's a simple matter to build collision detection into a RS-485 bus. Also,
while most Rs-485 buses are half-duplex, it is fairly straight forward to
implement a full-duplex RS-485 bus. I could provide schematics for this if
anyone is interested.

Douglas Wood
Software Enigneer
spamBeGonedbwoodspamBeGonespamkc.rr.com

Home of the EPICIS Development System for the PIC and SX
http://www.piclist.com/techref/member/DW--RA4

{Original Message removed}

2001\02\25@160053 by Olin Lathrop

face picon face
> Think of RS-485 as a multidrop 3 wire RS-232 interface.

RS-485 is a two-wire interface.  The two wires carry one signal
differentially, which eliminates the need for a ground or other reference
wire.  Also, the voltage levels are quite different from RS-232.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, TakeThisOuTolinEraseMEspamspam_OUTembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspamTakeThisOuTmitvma.mit.edu


2001\02\25@170046 by Spehro Pefhany

picon face
At 03:58 PM 2/25/01 -0500, you wrote:
>> Think of RS-485 as a multidrop 3 wire RS-232 interface.
>
>RS-485 is a two-wire interface.  The two wires carry one signal
>differentially, which eliminates the need for a ground or other reference
>wire.  Also, the voltage levels are quite different from RS-232.

You really do need a ground. And there is a limited common mode voltage
range.
Without a ground you'll get high EMI emissions as one problem.

There are some good application notes out there, e-mail if there is any
interest and I can dig one or two up.

One issue with the RS485 drivers is the relatively high supply current they
draw, especially with heavily loaded or shorted outputs.. something like
200mA.

Best regards,



=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..."            "The Journey is the reward"
speffEraseMEspam.....interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspammitvma.mit.edu


2001\02\25@175253 by Byron A Jeff

face picon face
>
> > Think of RS-485 as a multidrop 3 wire RS-232 interface.
>
> RS-485 is a two-wire interface.  The two wires carry one signal
> differentially, which eliminates the need for a ground or other reference
> wire.  Also, the voltage levels are quite different from RS-232.

Olin,

You missed the point I was trying to make. I wasn't trying to describe
them as equal electrical interfaces. I was trying to point out that
unlike EIA-232C, RS-485 only defines a data transmission interface without
benefit of signalling nor flow control.

BTW there's supposed to be a shared ground between nodes. So electrically
it's supposed to be a three wire interface.

But again that wasn't the point I was trying to make.

BAJ

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestEraseMEspamEraseMEmitvma.mit.edu


2001\02\25@201432 by steve

flavicon
face
> It's a simple matter to build collision detection into a RS-485 bus. Also,
> while most Rs-485 buses are half-duplex, it is fairly straight forward to
> implement a full-duplex RS-485 bus. I could provide schematics for this if
> anyone is interested.

That depends on whether you are using the term RS-485 to mean
the RS-485 standard or to mean a bus that uses RS-485 drivers to
implement a pseudo differential, open collector type bus.

Steve.
(Always prepared to be amazed, though).


======================================================
Steve Baldwin                Electronic Product Design
TLA Microsystems Ltd         Microcontroller Specialists
PO Box 15-680, New Lynn      http://www.tla.co.nz
Auckland, New Zealand        ph  +64 9 820-2221
email: RemoveMEstevebspam_OUTspamKILLspamtla.co.nz      fax +64 9 820-1929
======================================================

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspamspammitvma.mit.edu


2001\02\25@210503 by Olin Lathrop

face picon face
> >RS-485 is a two-wire interface.  The two wires carry one signal
> >differentially, which eliminates the need for a ground or other reference
> >wire.  Also, the voltage levels are quite different from RS-232.
>
> You really do need a ground. And there is a limited common mode voltage
> range.
> Without a ground you'll get high EMI emissions as one problem.

While is can be a good idea to run an additional third wire for ground, it
is not necessary in many cases.  You don't want the receiver totally
floating, but you also want to avoid ground loops.  The common mode range of
reasonable receivers is usually sufficient to cover the difference in ground
potential between receiver and transmitter.  The assumption is that both are
connected to their local grounds, but those grounds may have a small (a few
volts) difference due return currents in different paths.  In those cases,
you do NOT want to connect the grounds via the RS-485 cable to avoid a
ground loop.  It is better to have the receivers tolerate the common mode
range.  Note that the circuitry that disables the transmitter when receiving
must also tolerate the same common mode range.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, EraseMEolinspamspamspamBeGoneembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestKILLspamspammitvma.mit.edu


2001\02\25@211733 by Bob Ammerman

picon face
Olin,

I am _shocked_.

I always thought you were a stickler for following the spec.

A 485 link without a ground reference is certainly way out of spec.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

{Original Message removed}

2001\02\26@052729 by Simon Nield

flavicon
face
olin:
>The big difference to the software is that only one device on a 485 bus can
>transmit at a time, whereas there are separate dedicated transmit and
>receive channels for the single device at the other end of a 232 link.

this assumes you are using 2 wire rs485, which gives one datapath & is therefor half-duplex.
4 wire rs485 gives 2 datapaths and can be full duplex.

james: if you are designing a new system then you may well want to think about 4 wire 485, it'll can
be a lot more like 232 from a software point of view, which can make things a lot easier - also
means your slaves don't have to spend time listening to each others packets, which can give you a
nice code boost. (you use one pair from master to slaves and one pair from slaves to master - so
each link is unidirectional). cat5 may be a good choice for cabling; you have plenty of twisted
pairs, it's cheap, and its often in the walls already. if you do use cat5 then do check the pairing
of the wires as they are a little odd. if you can limit the baud rate then using slew rate limited
drivers will make emissions testing a lot easier.

one final point in favour of 4 wire 485 - trying to change direction with the serial ports on a pc
with windows is slow as slow can be (assuming you are using an rts controlled converter) as in 20ms
or so dead time. this makes polling multiple units a good way to waste loads of bandwidth. one
solution if you really do want 2 wire is to use a decent rs485 PCI card. the ones I have tried (from
oxford semi) were loads faster at turn around in half duplex (practically instantaneous turnaround
at 115200)..... could be that this is due to better optimised drivers for the oxsemi board, or it
could be hardware.

docs to look at:
circuit cellar have an article called the art & science of rs485.
Jan Axelson's has a good guide.
TI have a good overview of the standard such as it is.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\02\26@084432 by Olin Lathrop

face picon face
> I am _shocked_.
>
> I always thought you were a stickler for following the spec.
>
> A 485 link without a ground reference is certainly way out of spec.

I didn't know that.  The ones I've done have had the third wire and I've had
to deal with breaking the ground loop in the RS-485 interface.  However, I
know of one system in particular that uses just a twisted pair that is
probably about 50 meters long, with a total of 5 (I think) devices on the
bus.

It's been a while since I looked at the spec.  Sorry for creating a
confusion.


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, olinSTOPspamspamspam_OUTembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\02\26@093934 by Francois Robbertze

flavicon
face
I got stuck at the basics, can you please direct me to information on how to
connect a rs-485 chip to a pic in practice (two wire system - master and
slaves). I have download lots of information about the rs-485, but I want to
know what is the best way to connect this chip to my pic 16f628 with
protection etc.

What rs-485 manufacturer or type?

Regards

Francois

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\02\26@113826 by Bob Ammerman

picon face
----- Original Message -----
From: Olin Lathrop <spamBeGoneolin_piclistSTOPspamspamEraseMEEMBEDINC.COM>
To: <KILLspamPICLISTspamBeGonespamMITVMA.MIT.EDU>
Sent: Monday, February 26, 2001 8:32 AM
Subject: Re: [PIC]: RS485 code?


> > I am _shocked_.
> >
> > I always thought you were a stickler for following the spec.
> >
> > A 485 link without a ground reference is certainly way out of spec.
>
> I didn't know that.  The ones I've done have had the third wire and I've
had
> to deal with breaking the ground loop in the RS-485 interface.  However, I
> know of one system in particular that uses just a twisted pair that is
> probably about 50 meters long, with a total of 5 (I think) devices on the
> bus.
>
> It's been a while since I looked at the spec.  Sorry for creating a
> confusion.

It is out of spec, IIRC, only because the receivers have a limited common
mode range specified. You have to have some way of ensuring that range is
met.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\02\26@142330 by John Patrick

flavicon
face
Let's drop the RS- part of the bus interface, shall we?

RS-232. RS-422, and RS-485 are old names for these bus protocols.

TIA/EIA-232-F
TIA/EIA-422-B
TIA/EIA-485-A

Also, for more info on 485 and 422, check out National Seminconductor's
application notes 216, 759, 979, 1031, and 1057.  Excellent stuff there.

John

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\02\26@150830 by Dwayne Reid

flavicon
face
At 08:32 AM 2/26/01 -0500, Olin Lathrop wrote:

>I didn't know that.  The ones I've done have had the third wire and I've had
>to deal with breaking the ground loop in the RS-485 interface.  However, I
>know of one system in particular that uses just a twisted pair that is
>probably about 50 meters long, with a total of 5 (I think) devices on the
>bus.

I use two different techniques when implementing RS-485 and RS-422:

hazardous stuff uses optical isolation - power for the interface is usually
supplied in another pair along with the data.  All my Pryo equipment uses
this - the newest generation works reliably to about 3000 feet with 22 AWG
cable and 25Kbit/s data rates.  The distance limiting factor in that system
is the power supply pair, not data rate.

non-hazardous systems simply place a 100R 1/2W resistor in series with the
ground line.  I will also often bypass the resistor with a small (10n) cap.

Most ground loop currents are at line frequency - 50 or 60 Hz and usually
have fairly low open circuit voltage (much less than the common mode
voltage range of the driver and receiver chips).  Intentionally increasing
the resistance of the ground circuit keeps those ground loop currents
reasonable while ensuring that the remote units stay within common mode
range if the remote units are floating with respect to external earth.

Finally, something to keep in mind is that using shielded cable often
limits either distance or bit rate because of increased
capacitance.  Shielded cables are the only option if the system is used in
an industrial or other electrically noisy environment but are often not
required for home or office use.

dwayne



Dwayne Reid   <EraseMEdwaynerspamEraseMEplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 17 years of Engineering Innovation (1984 - 2001)

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\02\27@081559 by uter van ooijen & floortje hanneman

picon face
> Both 232 and 485 use the same asynchronous encoding of individual bytes.
> This is the familiar start bit, followed by data bits (usually 8),
followed
> by stop bits (usually 1 nowadays).

Slight misconception: neither RS-232 nor RS-485 (nor
RS-422,423,V.28,V.24,V.11 etc..) define a data format. As far as these
standards are concerend it is fine to use for instance 11 bits bytes with
machester encoding. As far as I know there isn't even a standard that
describes synchronous or asynchronous data format (idem for SPI!). An
indication of this curious omission is the fact that nearly every
manuafuacturer of an UART gives full specs of what the UART produces /
requires, instead of referring to a standard. But if anyone knows of such a
standard let me know!

Wouter

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\02\27@223707 by Lee Jones

flavicon
face
>> Both 232 and 485 use the same asynchronous encoding of individual
>> bytes.  This is the familiar start bit, followed by data bits
>> (usually 8), followed by stop bits (usually 1 nowadays).

> Slight misconception: neither RS-232 nor RS-485 (nor RS-422,
> 423, V.28, V.24, V.11 etc..) define a data format.

Right, they define an electrical interface and some use of
signal lines for control purposes.

> As far as these standards are concerend it is fine to use for
> instance 11 bits bytes with machester encoding.

Yep.

> As far as I know there isn't even a standard that describes
> synchronous or asynchronous data format (idem for SPI!)

My at-home copy of various ANSI standards are kind of old,
but in the US this seems to be addressed by:

   Bit Sequencing of the American National Standard Code
   for Information Interchange [aka ASCII] in Serial-by-Bit
   Data Transmission, ANSI X3.15-1976

   Character Structure and Character Parity Sense for
   Serial-by-Bit Data Communication in the American National
   Standard Code for Information Interchange, ANSI X3.16-1976

There are probably later revisions of these from the ANSI X3
committee.

There are almost certainly equivalent ISO/ITU specs, but I don't
have a copy of the multi-volume ISO standards here at home.

                                               Lee Jones

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


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