On-board RS232 between devices

[Alex Collins]

Hi,

I presume that, with RS232, it's possible that a receiving device may miss
the first byte or two of data while trying to synch with the Tx?

I mean, if no handshaking is used, how can the receiving device tell the
start and stop bits from the character bits, if it joins the dataflow
halfway through. How exactly do they synchronize?

I presume bits can, indeed, be lost while both ends synchronize, and that's
why protocols like I2C, and three line (CLOCK / DATA / ENABLE) serial
systems exist for on-board communications between devices?

Many thanks,
Alex.

 

[Brian Gregory [UK]]

"Alex Collins" <me@privacy.net> wrote in message
news:dre5t3$kpf$1@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com...

I presume that, with RS232, it's possible that a receiving device may miss
the first byte or two of data while trying to synch with the Tx?

I mean, if no handshaking is used, how can the receiving device tell the
start and stop bits from the character bits, if it joins the dataflow
halfway through. How exactly do they synchronize?

I assume you are meaning asynchronous serial data such as transmitted by the
COM port of a PC.

Answer: you don't join half way through.
If you for some reason you do you are right, you will get some wrong
characters.

However if you join during an idle time when no characters are being
transmitted there will be no problem.

I presume bits can, indeed, be lost while both ends synchronize, and
that's
why protocols like I2C, and three line (CLOCK / DATA / ENABLE) serial
systems exist for on-board communications between devices?

No it's got nothing to do with it at all.

--

Brian Gregory. (In the UK)
ng@bgdsv.co.uk
To email me remove the letter vee.

 

[Alex Collins]

"Jasen Betts" <jasen@free.net.nz> wrote in message
/snip

It's still required that the receiver identify the start of the message
correctly.

--

Bye.
Jasen

Thanks guys. Of course, I didn't think of it like that Jasen (the latter
just handshakes by virtue of the protocol in any case). I'm designing a
circuit where on-board micorcontrllers need to occasionally talk to one
another - but most of the time they will be 'off doing their own thing' so
to speak. Therefore, hoping that RS232 is going to synchronise perfectly
from the very first bit may prove unreliable. I clearly need an 'ENABLE'
signal between the two devices so that they can synchronize first. I don't
see why this can't be implemented by the receiving device making its TX line
pulse high as a signal that it's ready to receive.

Thanks again,
Alex.

 

[Brian Gregory [UK]]

"Alex Collins" <me@privacy.net> wrote in message
news:drfh0b$2l8$1@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com...

Thanks guys. Of course, I didn't think of it like that Jasen (the latter
just handshakes by virtue of the protocol in any case). I'm designing a
circuit where on-board micorcontrllers need to occasionally talk to one
another - but most of the time they will be 'off doing their own thing' so
to speak. Therefore, hoping that RS232 is going to synchronise perfectly
from the very first bit may prove unreliable. I clearly need an 'ENABLE'
signal between the two devices so that they can synchronize first. I don't
see why this can't be implemented by the receiving device making its TX
line
pulse high as a signal that it's ready to receive.

No you're still not getting it.

Firstly you won't be using RS232 levels because RS232 involves using +12V
for a zero and -12V for a one. You'll be using something like 0V for a zero
and 5V for a one.

Secondly if the serial link is sitting idle most of the time there will be
no problem with corrupt bytes. The only problem will be making sure you
don't send too many characters before the receiving program has read them
from the receiver, in fact there is usually only a buffer for one whole
character and one partly received character. The usual way to avoid this
problem is to use an interrupt routine to read each character from the
receiver immediately after it arrives.

--

Brian Gregory. (In the UK)
ng@bgdsv.co.uk
To email me remove the letter vee.

 

[Brian Gregory [UK]]

"Jasen Betts" <jasen@free.net.nz> wrote in message
news:7fb.43dae870.ef87a@clunker.homenet...

with synchronous I think a clock signal is needed

Synchronous simply means that bits are being transmitted continuously. Start
bits and stop bits are not used; something more complex and usually more
efficient is used to identify the boundaries between characters. The clock
in the receiver doesn't synchronise instantly with each start bit on each
character but more slowing by watching all the logic level transitions.

--

Brian Gregory. (In the UK)
ng@bgdsv.co.uk
To email me remove the letter vee.

 

[Bob Monsen]

On Sat, 28 Jan 2006 14:08:12 +0000, Brian Gregory [UK] wrote:

"Jasen Betts" <jasen@free.net.nz> wrote in message
news:7fb.43dae870.ef87a@clunker.homenet...
with synchronous I think a clock signal is needed

Synchronous simply means that bits are being transmitted continuously. Start
bits and stop bits are not used; something more complex and usually more
efficient is used to identify the boundaries between characters. The clock
in the receiver doesn't synchronise instantly with each start bit on each
character but more slowing by watching all the logic level transitions.

With HDLC framing, idle patterns are used between frames. No clock is
required, since it is recovered from the datastream, often with a PLL.
Bit stuffing is used to ensure that this idle pattern can never be part of
a frame. So, you just wait for an idle pattern. Different encoding
schemes, such as NRZI, can be used to prevent the problems long streams
of ones or zeros can cause for clock recovery.

Async uses stop and start bits to determine start and end of bytes. It
also uses a break or idle stream, which just means all zeros (spaces) or
all ones (marks) for a while, usually several character times. It is
usually possible to detect end of byte by watching the length of the stop
bit. Here is a reasonably accurate description of things:

http://en.wikipedia.org/wiki/Stop_bit

Obviously, for continuous streams of data, HDLC is preferable to async.
The penalty is more complex software, and higher line overhead for
very short messages. Each frame has 5 or 8 bytes of overhead, and there
are usually internal 'protocol headers' can take 40 or more bytes for each
message. However, for longer messages, the balance tips the other way, due
to the more compact encoding for each byte. Thus, HDLC encoding is often
used on high speed T1 or T3 links to bridge ethernet frames.

--
Regards,
Bob Monsen

"I am turned into a sort of machine for observing facts and grinding
out conclusions."
-- Charles Darwin

 

[Rich Grise]

On Sat, 28 Jan 2006 14:00:56 +0000, Brian Gregory [UK] wrote:

"Alex Collins" <me@privacy.net> wrote in message
news:drfh0b$2l8$1@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com...
Thanks guys. Of course, I didn't think of it like that Jasen (the latter
just handshakes by virtue of the protocol in any case). I'm designing a
circuit where on-board micorcontrllers need to occasionally talk to one
another - but most of the time they will be 'off doing their own thing'
so to speak. Therefore, hoping that RS232 is going to synchronise
perfectly from the very first bit may prove unreliable. I clearly need
an 'ENABLE' signal between the two devices so that they can synchronize
first. I don't see why this can't be implemented by the receiving device
making its TX line
pulse high as a signal that it's ready to receive.

No you're still not getting it.

Firstly you won't be using RS232 levels because RS232 involves using +12V
for a zero and -12V for a one. You'll be using something like 0V for a
zero and 5V for a one.

Secondly if the serial link is sitting idle most of the time there will be
no problem with corrupt bytes. The only problem will be making sure you
don't send too many characters before the receiving program has read them
from the receiver, in fact there is usually only a buffer for one whole
character and one partly received character. The usual way to avoid this
problem is to use an interrupt routine to read each character from the
receiver immediately after it arrives.

There's also hardware handshaking, but if you're going to add lines just
to sync them up, you might as well use IIC or SPI.

Cheers!
Rich

 

[Jasen Betts]

On 2006-01-27, Alex Collins <me@privacy.net> wrote:

Hi,

I presume that, with RS232, it's possible that a receiving device may miss
the first byte or two of data while trying to synch with the Tx?

I mean, if no handshaking is used, how can the receiving device tell the
start and stop bits from the character bits, if it joins the dataflow
halfway through. How exactly do they synchronize?

yes with asynchronous, it's not always possible to get the correct sync unless
you start listening when the channel is idle. or encounter a bit pattern that's
unmistakable.

with synchronous I think a clock signal is needed

If the asynchronous device must also identify the correct bit rate it gets
even more difficult.

I presume bits can, indeed, be lost while both ends synchronize,

bytes can be garbled until the receiver correctly identifies a start bit.

and that's why protocols like I2C, and three line (CLOCK / DATA / ENABLE) serial
systems exist for on-board communications between devices?

no. with asynchronous RS232 both ends need to bave a clock running at
approximately the same speed with those synchronous protocols the clock
is shared explicitly so that bits can be easily recognised.
It's still required that the receiver identify the start of the message
correctly.

--

Bye.
Jasen

 

[Bob Monsen]

On Sat, 28 Jan 2006 10:28:28 +0000, Alex Collins wrote:

"Jasen Betts" <jasen@free.net.nz> wrote in message
/snip


It's still required that the receiver identify the start of the message
correctly.

--

Bye.
Jasen

Thanks guys. Of course, I didn't think of it like that Jasen (the latter
just handshakes by virtue of the protocol in any case). I'm designing a
circuit where on-board micorcontrllers need to occasionally talk to one
another - but most of the time they will be 'off doing their own thing' so
to speak. Therefore, hoping that RS232 is going to synchronise perfectly
from the very first bit may prove unreliable. I clearly need an 'ENABLE'
signal between the two devices so that they can synchronize first. I don't
see why this can't be implemented by the receiving device making its TX line
pulse high as a signal that it's ready to receive.

Thanks again,
Alex.

Rather than using RS232, why not look at SPI or I2C? Microcontrollers
often have hardware support for these, so you just need to poke it with
software, and it goes off and sends or receives by itself (like a UART).

If you have many microcontrollers that all need to talk over the same
wires, I2C is preferable, because multiple masters can be on the same
'bus', which consists of a clock line and a data line. Each device has its
own address, and a collision detection protocol is used so multiple
masters can take control of the bus.

SPI can also be used for multiple devices, but requires an additional
higher level protocol, and for one of the devices to always act as master
and clock the data. SPI is usually easier to get going than I2C, which can
be a nightmare, due to its 'pullup' architecture.

One nice thing about I2C and SPI is that many hardware devices, such as
port expanders and eeproms, are designed to talk these protocols.
For example, PCs often use I2C for their internal temperature
monitoring hardware.

RS232 can be used for this application, but is is really designed
to be a protocol to go over cables. You can use the async signaling
protocols without the goofy voltage levels, but again, one device needs to
act as master. Look up "SDLC", which is a protocol for communication over
an RS232 link. A master "polls" the slaves, who then can respond. Thus, a
single master must act as broker for data between slaves.

--
Regards,
Bob Monsen

"I am turned into a sort of machine for observing facts and grinding
out conclusions."
-- Charles Darwin