Searching \ for 'rs232 works - should it?' 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=rs232
Search entire site for: 'rs232 works - should it?'.

Truncated match.
PICList Thread
'rs232 works - should it?'
2000\03\26@181812 by JB

flavicon
face
I have found numerous rs232 references on the voltages, cable lengths, connector pin-outs, etc., but nothing whatsoever on the actual signals on the wire going from one device to another. What does the actual waveform look like for instance, while transmitting the octet H'25' at 9600 baud, 8/n/1?

I have discovered through trial and error that this works when communicating to my PC at both 9600 and 4800 baud (logic levels indicated - actual levels inverted due to direct connection from 16F84 to PC):

high 1t
low     0.5t
bit 0 1t
bit 1 1t
bit 2 1t
bit 3 1t
bit 4 1t
bit 5 1t
bit 6 1t
bit 7 1t
high 1t

My question is: Should this work? Am I just lucky, or is this a sound implementation of the standard? I know the voltage levels are questionable from a portability standpoint - it's the logic states and timing I'm questioning.

Thanks,

JB

2000\03\26@183433 by David VanHorn

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>I have discovered through trial and error that this works when
communicating to my PC at both 9600 and 4800 baud (logic levels indicated -
actual levels inverted due to direct connection from 16F84 to PC):
>
>high 1t
>low     0.5t
>bit 0 1t
>bit 1 1t

You've discovered that a byte may have as many stop bits as you like, but
not less than one.

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>

iQA/AwUBON7IaIFlGDz1l6VWEQJmpACgleabn32hf1f1NJtEets5dkIaD4gAoPog
YK6NLhW0WHaRfHqXY00IQXE4
=DGld
-----END PGP SIGNATURE-----

2000\03\26@185130 by JB

flavicon
face
As a follow-up on this - I'm using Hyperterminal in W95 for the receiver terminal. I have noticed that about half the time when starting/stopping the connection I get garbage (like bits having been shifted). The rest of the time, it works great. I'm obviously not doing something right. The delays are not exact, but within about 5uS, which may or may not be good enough. FWIW, the code is below (W contains byte to be sent). Once again, the levels are inverted, configured for 9600 8/n/1.

JB

Sendbyte:
       movwf   MYBYTE
       bcf     PORTA,dataout   ;startbit 1t logic high
       call    Delay100uS
       bsf     PORTA,dataout   ;startbit 1/2t logic low
       call    Delay50uS
       movlw   D'8'
       movwf   BITCNT
bitlp:
       rrf     MYBYTE,f        ;lsb first
       btfss   STATUS,C
       goto    sendlow
sendhigh:
       bcf     PORTA,dataout   ;direct-connect so invert
       goto    bitset
sendlow:
       bsf     PORTA,dataout
       goto    bitset          ;this would fall through, but
                               ;keeps bit timing symmetrical
bitset:
       call    Delay100uS      ;1t each bit
       decfsz  BITCNT,f
       goto    bitlp
       bcf     PORTA,dataout   ;stop bit 1t logic high
       call    Delay100uS
       return

Delay100uS:
       movlw   D'32'
       movwf   AA
lpA:    decfsz  AA,f
       goto    lpA
       return

Delay50uS:
       movlw   D'16'
       movwf   AA
lpA1:   decfsz  AA,f
       goto    lpA1
       return


At 04:15 PM 3/26/00 -0700, you wrote:
{Quote hidden}

2000\03\26@190957 by rottosen

flavicon
face
I did not look at your program in detail. However, I did notice that your delays are 100us and 50us. At 9600 baud they should be 1/9600 = 104.2us and half that which is 52.08us. 104us and 52us are close enough. The total delay must be accurate. This includes the delay caused by the instructions sending or receiving the data. I hope this quick note helps.

-- Rich

JB wrote:

{Quote hidden}

2000\03\26@201028 by JB
flavicon
face
I was hoping that the delays were close enough - I read somewhere the timing was significant for a single transmission only, with the receiver re-syncing on every start bit. You are of course right though - never hurts to eliminate that as an issue. I did find that a stop bit of 5t totally eliminates the problem, which probably means my timing is off enough (like you noted) that back-back bytes don't sync properly. If the overall idea is right, then I can work that out.

Thanks - JB


At 05:08 PM 3/26/00 -0700, you wrote:
>I did not look at your program in detail. However, I did notice that your delays are 100us and 50us. At 9600 baud they should be 1/9600 = 104.2us and half that which is 52.08us. 104us and 52us are close enough. The total delay must be accurate. This includes the delay caused by the instructions sending or receiving the data. I hope this quick note helps.
>
>-- Rich
>

2000\03\26@202719 by Andrew Warren

face
flavicon
face
JB <spam_OUTPICLISTTakeThisOuTspamMITVMA.MIT.EDU> wrote:

> I have noticed that about half the time .... I get garbage (like
> bits having been shifted). .... I'm obviously not doing something
> right. The delays are not exact, but within about 5uS, which may or
> may not be good enough.

JB:

Your start bit is currently half a bit-time long; make it a full bit-
time (in other words, replace the "call Delay50uS" with a "call
Delay100uS") and everything will work MUCH better.

-Andy


=== Andrew Warren - .....fastfwdKILLspamspam@spam@ix.netcom.com
=== Fast Forward Engineering - San Diego, California
=== http://www.geocities.com/SiliconValley/2499

2000\03\26@222256 by JB

flavicon
face
>Your start bit is currently half a bit-time long; make it a full bit-
>time (in other words, replace the "call Delay50uS" with a "call
>Delay100uS") and everything will work MUCH better.
>
>-Andy

Well, this is confusing - your suggestion doesn't work.

The frustrating part for me is that I still don't have a definitive reference for whether the start bit is 1.5t, 1t or 0.5t, and of what polarity relative to the stop bit. Does anyone have a pointer to an actual rs232 standard that shows these relationships? I know the voltages and pinouts - but what *exactly* is supposed to take place from the start of transmission to the very end? Even an ugly ASCII art diagram would be great.

Is this supposed to be right for sending H'28' at 9600/n/8/1?

1       156uS <start bit
0       104uS <bit0
1       104uS
0       104uS
0       104uS
0       104uS
0       104uS
0       104uS
1       104uS <bit7
0       104uS <stop bit

The above doesn't seem to work in my case. Reversing start/stop polarity also doesn't work. Only when I shorten the start bit to 50uS does it work somewhat reliably, and only when I lengthen the stop bit 3x-5x does it seem solid. Like so:

0 52uS ;start bit
bit0 104uS
bit1 104uS
...
bit7 104uS
0 104uS ;stop bit
0 104uS ;stop bit
0 104uS ;stop bit
0 104uS ;stop bit

Code follows (delays are properly adjusted to give very close to correct bit times in this routine):

Sendbyte:
       movwf   MYBYTE
       bsf     PORTA,dataout   ;startbit 1/2t logic low
       call    Delay50uS
       movlw   D'8'
       movwf   BITCNT
bitlp:
       rrf     MYBYTE,f        ;lsb first
       btfss   STATUS,C
       goto    sendlow
sendhigh:
       bcf     PORTA,dataout   ;direct-connect so invert
       goto    bitset
sendlow:
       bsf     PORTA,dataout
       goto    bitset          ;this would fall through, but
                               ;keeps bit timing symmetrical
bitset:
       call    Delay100uS      ;1t each bit
       decfsz  BITCNT,f
       goto    bitlp
       bcf     PORTA,dataout   ;stop bit 1t logic high
       call    Delay100uS
       call    Delay100uS
       call    Delay100uS
       call    Delay100uS
       call    Delay100uS
       return

2000\03\26@223334 by Andrew Warren

face
flavicon
face
JB <PICLISTspamKILLspamMITVMA.MIT.EDU> wrote:

> The frustrating part for me is that I still don't have a definitive
> reference for whether the start bit is 1.5t, 1t or 0.5t, and of what
> polarity relative to the stop bit.

   JB:

   It's 1t, and of opposite polarity relative to the stop bit.

{Quote hidden}

   No, that's not right; it should look like this:

       1       104uS <start bit
       0       104uS <bit0
       0       104uS
       0       104uS
       1       104uS
       0       104uS
       1       104uS
       0       104uS
       0       104uS <bit7
       0       104+uS <stop bit

   Note that the start bit is 104 uS, I've moved the "1" bits around
   so you're actually sending 28 (your table would've sent 82), and
   the stop bit can be any length longer than 104 uS.  It's
   probably best to make your stop bit 208 uS or longer; that'll
   give your receiver a little more time to buffer the data and
   prepare to re-sync on the next start bit.

   Also... Before the very first start bit taht you send after
   power-up, your transmit line should be in the "stop" state,
   preferably for at least 1 bit-time (104 uS).

   -Andy


=== Andrew Warren - .....fastfwdKILLspamspam.....ix.netcom.com
=== Fast Forward Engineering - San Diego, California
=== http://www.geocities.com/SiliconValley/2499

2000\03\27@000637 by paulb

flavicon
face
JB wrote:

> The frustrating part for me is that I still don't have a definitive
> reference for whether the start bit is 1.5t, 1t or 0.5t, and of what
> polarity relative to the stop bit.  Does anyone have a pointer to an
> actual rs232 standard that shows these relationships?

 Technically, there is *no* RS-232 standard showing such relationships,
and never will be because RS-232 is a level-zero = "physical" level
standard.  It defines wires, voltages and pins.  What travels on that
layer, the level-one or "transport" layer, is something else again.

 And asynchronous serial at a given baudrate is only *one possible*
transport layer.  Others are Bi-Sync, Manchester, HDLC/ NRZI etc.  So,
it is not RS-232 that we are discussing, it is asynchronous "teletype"
protocol.  You will find it described in UART datasheets.

> I know the voltages and pinouts - but what *exactly* is supposed to
> take place from the start of transmission to the very end?

 It is what Andy described.  The "resting" state of the line is "mark",
originally corresponding to current *on* and a solenoid holding a pen
against a tape.  On RS-232 this is negative voltage, but in TTL/ CMOS
logic it corresponds to +5V or logic "1" (interface chips are
inverters).

 The start bit is always *one* bit time, and is a "space" state or
logic zero.  Eight (in most cases) data bits follow in order from least
significant to most significant, each is again *one* bit time.
Thereafter, a *minimum* stop bit is *one* bit time in the marking state
(logic one) and the line *must* remain marking until the next start bit
as any spacing (zero) state following completion of a character will be
considered a new start bit.

 To facilitate synchronisation, particularly following an error due to
noise, a longer minimum stop bit may be used, either 1¸ or 2 bit times,
even longer if speed is not critical.  A "bit-banged" software receiver
will frequently use this time to process the character just received,
another reason do do so.

 Do pay attention to the exact timing.  The reason you have heard of
half-bit timings relates to the receiver, which on detecting the start
bit as a zero state, waits a half-bit delay then checks the *middle* of
the start bit to see if it still asserted.  (Why the middle?  To allow
for transient settling and baudrate variations.)  If indeed it is, then
it samples eight successive bit-times later to read the data bits, then
once again to verify the correct stop bit.  Having verified the stop bit
(must be mark) halfway through, many implementations then immediately
become ready to see another start bit as soon as the line goes to space.

 The general rule then is that you send one or two stop bits, but allow
to receive only a half stop bit.

 If the data bits are sampled in the middle, then the last data bit,
being the ninth bit in the series, will be read incorrectly if the stop
bit occurs half a bit early (or indeed, if the second-last data bit is
half a bit late).  This error threshold is thus (+/-) one-half a bit in
nine bits or 5.5% either way, the figure you will often see quoted.

 It follows that you must keep timing errors to a quarter of this
figure allowing a 2 times safety margin and half the inaccuracy each in
sender and receiver.  That's 1.4% or better, so if you need a bit time
of 104µs at 9600 baud, you can only afford just over 1µs either way, and
this is quite possibly the reason your interpretation of what Andy said
did not work.
--
 Cheers,
       Paul B.

2000\03\27@004610 by Russell McMahon

picon face
>I have found numerous rs232 references on the voltages, cable lengths,
connector pin-outs, etc., but nothing whatsoever on the actual signals on
the wire going from one device to another. What does the actual waveform
look like for instance, while transmitting the octet H'25' at 9600 baud,
8/n/1?
>I have discovered through trial and error that this works when
communicating to my PC at both 9600 and 4800 baud (logic levels indicated -
actual levels inverted due to direct connection from 16F84 to PC):
snip
>My question is: Should this work? Am I just lucky, or is this a sound
implementation of the standard? I know the voltage levels are questionable
from a portability standpoint - it's the logic states and timing I'm
questioning.
>
>Thanks,

AND

>>The frustrating part for me is that I still don't have a definitive
reference for whether the start bit is 1.5t, 1t or 0.5t, and of what
polarity relative to the stop bit. Does anyone have a pointer to an actual
rs232 standard that shows these relationships? I know the voltages and
pinouts - but what *exactly* is supposed to take place from the start of
transmission to the very end? Even an ugly ASCII art diagram would be great.

++++++++++++++++++++++++

JB,



Consider line idle condition to be a "1" (this is -12v for true RS232)
Idle condition wiull depend on YOU for a TTL system (could be +5 or ground
or ... .
The important thing is to consider that "!" is the idle state.

Then -

- A start bit is ALWAYS a "0"
- A STOP bit is always a "1"
- A START bit is ALWAYS 1 bit long
- A STOP bit is ALWAYS    * AT LEAST * 1 bit long and may be longer. It can
be 2 bits long but any length over 1 bit is OK unless you have a system in
which you have defined a longer minimum time as necessary.
- You must have a predefined number of data bits, each exactly 1 bit time
long.
- You may have a polarity bit following the data bits and before the stop
bit(s) IF you have defu=ined this as part of your protocol.

The 1.5 bits confusion may have come from several sources.

As defined above the MIDDLE of the 1st data bit occurs 1.5 bits after the
start of the START bit (all the start bit plus the first data bit).
Therefore the first data sample is taken 1.5 bit times after the LEADING
EDGE of the first edge of the START bit. Subsequent data samples are taken
at 1 bit intervals (at 1.5, 2.5, 3.5, 4.5 ... bit times after the 1dst edge
of the START bit.) Draw a picture - it makes sense.

X = line idle condition
S = START
0-7 = data
s = STOP

S is opposite of X
s is same polarity as X

Each bit here is shown by TWO characters.

XXXXSS0011223344556677ssXXXXXX

Sampling should ideally occur in the middle of the bit.
Data bit 0's middle occurs after SS0 = 1.5 bits
Data bit 1'2 middle occurs after SS001 = 2.5 bits etc.

Bit 0 is always sent (and received) first.
Some formats only use 7 data bits (with or without parity).
Systems with parity usually don't use 8 data bits.
SOME systems effectively use 9 bits with the 9th bit used to indicate an
address word.

An additional thing to be aware of -

You can drift by no more than 1/2 a bit across the whole word when sampling.
If you DO drift by more than 1/2 a bit you will drift into the edge of the
next bit which will give you an error. (Actually MAY give you an error but
if it doesn't it's only by luck).






     Russell McMahon
_____________________________

>From other worlds - http://www.easttimor.com
                               http://www.sudan.com

What can one man* do?
Help the hungry at no cost to yourself!
at  http://www.thehungersite.com/

(* - or woman, child or internet enabled intelligent entity :-))


{Original Message removed}

2000\03\27@005229 by William Chops Westfield

face picon face
   The frustrating part for me is that I still don't have a definitive
   reference for whether the start bit is 1.5t, 1t or 0.5t, and of what
   polarity relative to the stop bit.

The "start bit" is a bit, and needs to be one bit long.

The "stop bit" is also a bit, but you can "stretch" it, since the stop bit
is at the same voltage level as the inter-character condition ("mark",
usually.)  Since the inter-character time is not based on the bit clocks
(the definition of "asynchronous", more or less), a stop bit can be any
length of time like 1.1 bit times or 3.1416 bit times, or whatever (but it
has to be at least ONE bit time.)


   Does anyone have a pointer to an actual rs232 standard that shows these
   relationships?

This is NOT part of rs232, which is a signaling/voltage/etc sort of
standard (physical layer rather than link layer.)  You can send
non-asynchronous data using rs232 just fine (and many people do.)  What you
want is the full description of "asynchronous serial" - I suppose that
somewhere there is a spec for this (V.24, maybe?), but the usual place to
find the nitty-gritty description is in the full datasheets for some
manufacturers uart, or the app note describing a SW implementation.
Although I couldn't find one with a quick look around - the EXAR
16450-clone datasheet has a relatively nice picture in the "timing
diagrams" for receive and transmit data...

BillW

2000\03\27@074856 by Byron A Jeff

face picon face
>
> >Your start bit is currently half a bit-time long; make it a full bit-
> >time (in other words, replace the "call Delay50uS" with a "call
> >Delay100uS") and everything will work MUCH better.
> >
> >-Andy
>
> Well, this is confusing - your suggestion doesn't work.
>
> The frustrating part for me is that I still don't have a definitive
>reference for whether the start bit is 1.5t, 1t or 0.5t,

It's 1t, the same size as every other bit in the serial stream.

> and of what polarity
>relative to the stop bit.

The opposite of the stop bit.

> Does anyone have a pointer to an actual rs232
>standard that shows these relationships? I know the voltages and pinouts -
>but what *exactly* is supposed to take place from the start of transmission
>to the very end? Even an ugly ASCII art diagram would be great.

Instead of ASCII art I'll use letters L for low and H for high. Say you wanted
to send an ASCII 'A' (01000001). This would be the sequence:

HHHHLHLLLLLHLHHHH
1   23       4

Notes:
1. The serial line idles in a high state and must be in a high state
for at least 1 bit time before the start bit.
2. The start bit. Note that that it must be the opposite polarity of the idle
state. It is one bit time. Not 1.5 bit times.
3. This is the least significant bit. the other bits follow in sequence.
4. This is the stop bit. Note that it just idles the line but must be present
because the line must be idle for at least 1 bit time before a start bit.

>
> Is this supposed to be right for sending H'28' at 9600/n/8/1?
>
> 1       156uS <start bit

Nope. First of all a start bit is a 0, not a 1. Also it's the same length as
all the other bits.

> 0       104uS <bit0
> 1       104uS
> 0       104uS
> 0       104uS
> 0       104uS
> 0       104uS
> 0       104uS
> 1       104uS <bit7

This sequence sends a H'82', not H'28'. For H'28' it would be

0
0
1
0
0
1
0
0


> 0       104uS <stop bit

Stop bit is a 1. Same length as all the others.

>
> The above doesn't seem to work in my case. Reversing start/stop polarity also
> doesn't work. Only when I shorten the start bit to 50uS does it work
>somewhat reliably,

It's 104uS, just like all other others.

> and only when I lengthen the stop bit 3x-5x does it seem solid.

Now that's possible depending on the receiver. However nothing should require
more than 2 stop bits.

> Like so:
>
> 0 52uS ;start bit

Nope. Still 104uS. The start bit is the same length as all the others.

> bit0 104uS
> bit1 104uS
> ...
> bit7 104uS
> 0 104uS ;stop bit
> 0 104uS ;stop bit
> 0 104uS ;stop bit
> 0 104uS ;stop bit

What's the receiver. It's probably getting confused by the 0.5 length start
bit. Many implementations will check the start (and every other bit) in the
middle of the cell. In both these instances above you've set the start bit
so that it changes in the middle of the cell, making all subsequent bits
spurious. The start bit is the same length as every other bit. Once you do
this then it should stabilize.

>
> Code follows (delays are properly adjusted to give very close to correct bit times in this routine):
>
> Sendbyte:
>         movwf   MYBYTE
>         bsf     PORTA,dataout   ;startbit 1/2t logic low
>         call    Delay50uS

         call    Delay104uS

{Quote hidden}

Should need two at the max once you set the start bit correctly.

BAJ

2000\03\27@093332 by Michael Rigby-Jones

flavicon
face
part 0 17671 bytes
<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">I think someone is getting confused with sending and receiving serial data.&nbsp; When you send, you send the start bit, wait one bit period, send the lsb, wait one bit period etc...</FONT></P>
<BR>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">When you use a simple software uart to receive, you should sample the serial data in the middle of a bit period.&nbsp; So after detecting the start bit, then you wait 1 1/2 bit periods so that you sample in the middle of the first bit, then wait one bit period to sample the next bit etc.&nbsp; The 1 1/2 bit period is only valid as the first delay after receiving the start bit.</FONT></P>

<P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">Mike</FONT>
<UL>
<P><FONT SIZE=1 FACE="Arial">{Original Message removed}

2000\03\27@101031 by Alan B Pearce

face picon face
>When you use a simple software uart to receive, you should sample the serial
data in the middle of a bit period.  So after detecting the start >bit, then you
wait 1 1/2 bit periods so that you sample in the middle of the first bit, then
wait one bit period to sample the next bit etc.  The 1 1/2 >bit period is only
valid as the first delay after receiving the start bit.

Not quite. it should be done as follows

detect start bit.
wait 1/2 bit period - start bit still valid? no noise glitch ignore this  and
wait for next start bit,
else wait 1 bit period - clock in LSB
wait 1 bit period, clock in next bit, repeat for total number of bits, then wait
1 bit time
sense state of stop bit, if not correct, then framing error (could be noisy
line, incorrect baud rate)

2000\03\27@120057 by Byron A Jeff

face picon face
>
> I think someone is getting confused with sending and receiving serial data.
> When you send, you send the start bit, wait one bit period, send the lsb,
> wait one bit period etc...

Absolutely.

>
>
> When you use a simple software uart to receive, you should sample the serial
> data in the middle of a bit period.  So after detecting the start bit, then
> you wait 1 1/2 bit periods so that you sample in the middle of the first
> bit, then wait one bit period to sample the next bit etc.  The 1 1/2 bit
> period is only valid as the first delay after receiving the start bit.

And those of us who are paranoid actually sample the start bit too to make
sure that it's a real character and not just a spurious glitch. So my routines
typically will wait a 1/2 bit period, make sure that the start bit is valid,
then proceed to sample the data bits by waiting 1 bit period for each bit
thereafter.

BAJ

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