Questions about reading decoders and decode box alignment

[Electro Fan]

Attached are a couple images showing protocol decoders.

One is from a Rigol DS2000.  The other is from an Intronix LogicPort.

On the Rigol image I've drawn some red lines that extend from the edges of the protocol decode boxes (this image is from a RS232 decode).  You can see there is a gap between where one box ends and the next begins.  Is this a convention that allows for a stop bit in between bytes?  Or something else?

On the Rigol image I've also inserted what I think are the 1s and 0s represented by the waveform.  This shows the 1s to be Low and the 0s to be High, which is the inverted polarity convention of ASCII?  This bit sequence corresponds to the binary value for the letter "a" (which according to the ASCII table is 110001 - but since ASCII is generally a 7 bit byte and the HyperTerminal program on the PC composed 8 bit bytes it inserted/padded a leading 0 as the Most Signficant Bit?).  The waveform presents this value in the opposite order; I guess this is because the ASCII bits are presented as LSB (Least Significant Bit) first?  Or perhaps it is due to the direction of the oscilloscope sweep (as opposed to human reading which is left to right)?

On the Intronix image there are two light blue lines toward the bottom that are from a RS232 signal.  In this case the decode boxes are tightly aligned end to end with no gap.  Is this because in this case the deocode boxes represent the inclusion of stop bits?

Is there a convention for aligning decode boxes tightly or leaving them spaced apart somewhat to account for start or stop bits or other non-data bits (parity, etc.)?

Along these lines, what is the demarcation between the end of the one bit and the beginning of the next bit?  Is it the first pixel on a horizontal line that follows a vertical line?  Does a bit start right at a leading or falling edge?   Or is it the mid section of a one bit long horizontal line?

Thanks, EF

[Electro Fan]

Ok, maybe too many questions in one post.   

How about just starting with these two?

(see post above for full context and images)

1. Is there a convention for aligning decode boxes tightly (as in the Intronix RS232 example), or leaving them spaced apart somewhat (as in the Rigol example) to account for start or stop bits or other non-data bits (parity, etc.)?

2. Along these lines, what is the demarcation between the end of the one bit and the beginning of the next bit?  Is it the first pixel on a horizontal line that follows a vertical line?  (Does a bit start right at a leading or falling edge?)   Or is it the mid section of a one bit long horizontal line?

Thanks

[baljemmett]

On the Rigol image I've also inserted what I think are the 1s and 0s represented by the waveform.  This shows the 1s to be Low and the 0s to be High, which is the inverted polarity convention of ASCII?  This bit sequence corresponds to the binary value for the letter "a" (which according to the ASCII table is 110001 - but since ASCII is generally a 7 bit byte and the HyperTerminal program on the PC composed 8 bit bytes it inserted/padded a leading 0 as the Most Signficant Bit?).  The waveform presents this value in the opposite order; I guess this is because the ASCII bits are presented as LSB (Least Significant Bit) first?  Or perhaps it is due to the direction of the oscilloscope sweep (as opposed to human reading which is left to right)?

You're almost right there, except you have your layers mixed up.  ASCII is a numeric code - it doesn't specify anything about the actual transmission of those numbers, just that a space is going to be 32, etc.  However, RS-232 specifies that bits should be transmitted least-significant first, and with a negative voltage representing a 1 or "mark" (hence appearing on a 'scope screen backwards and upside down from how we'd probably assume such a transmission might appear).  Note that this voltage specification applies to the data pins -- the control pins, confusingly, are specified to use the positive voltage to represent a logic high instead.

[codeboy2k]

The red box you have drawn on the Rigol display is the stop bit from the first transmission and the start bit of the second transmission.

The Intronix display just includes those stop and start bits as part of the decoded data, thus no gaps on the display.

There's no real standard.. Although I think the Intronix way is better, as those stop and start bits are indeed part of the transmitted 8-bit byte, making up 10 bits per transmitted byte.  The Rigol display doesn't help you to understand what those data transitions are.

However, it's also useful for a logic analyzer to be able to hide the extraneous information.  Some synchronous protocols have 64 bits or more of leader and also have interblock gaps of unspecified sizes, that you really don't *need* to see, but when I want to see them, I want to be able to turn them on, and I don't want to be forced to view them all the time. In that case, the Rigol way would be better, and if the Intronix style was followed with such a data stream as I described, it might be showing too much information and I'd like to cut it down for easier analysis.  So in summary, whichever way helps you to understand the data stream best, and perhaps has the options available to change the way you see it, then that's a good analyzer with a good way to view the data.

[Electro Fan]

On the Rigol image I've also inserted what I think are the 1s and 0s represented by the waveform.  This shows the 1s to be Low and the 0s to be High, which is the inverted polarity convention of ASCII?  This bit sequence corresponds to the binary value for the letter "a" (which according to the ASCII table is 110001 - but since ASCII is generally a 7 bit byte and the HyperTerminal program on the PC composed 8 bit bytes it inserted/padded a leading 0 as the Most Signficant Bit?).  The waveform presents this value in the opposite order; I guess this is because the ASCII bits are presented as LSB (Least Significant Bit) first?  Or perhaps it is due to the direction of the oscilloscope sweep (as opposed to human reading which is left to right)?

You're almost right there, except you have your layers mixed up.  ASCII is a numeric code - it doesn't specify anything about the actual transmission of those numbers, just that a space is going to be 32, etc.  However, RS-232 specifies that bits should be transmitted least-significant first, and with a negative voltage representing a 1 or "mark" (hence appearing on a 'scope screen backwards and upside down from how we'd probably assume such a transmission might appear).  Note that this voltage specification applies to the data pins -- the control pins, confusingly, are specified to use the positive voltage to represent a logic high instead.

Thanks - that is something I need to keep straight - what is convention by virtue of the ASCII code and what is convention by virtue of the RS232 spec.  And thanks for pointing out the difference between the data pins and the control pins.  I'm on the lookout for how to examine the controls signals next.  Thx again 

[Electro Fan]

The red box you have drawn on the Rigol display is the stop bit from the first transmission and the start bit of the second transmission.

The Intronix display just includes those stop and start bits as part of the decoded data, thus no gaps on the display.

There's no real standard.. Although I think the Intronix way is better, as those stop and start bits are indeed part of the transmitted 8-bit byte, making up 10 bits per transmitted byte.  The Rigol display doesn't help you to understand what those data transitions are.

However, it's also useful for a logic analyzer to be able to hide the extraneous information.  Some synchronous protocols have 64 bits or more of leader and also have interblock gaps of unspecified sizes, that you really don't *need* to see, but when I want to see them, I want to be able to turn them on, and I don't want to be forced to view them all the time. In that case, the Rigol way would be better, and if the Intronix style was followed with such a data stream as I described, it might be showing too much information and I'd like to cut it down for easier analysis.  So in summary, whichever way helps you to understand the data stream best, and perhaps has the options available to change the way you see it, then that's a good analyzer with a good way to view the data.

codeboy2k, Thanks!  It is very helpful to know there is no standard and that different decoders employ different representations - that will help keep me from doing even more of this:    

I think I can now better visualize on the Rigol where the start and stop bits are located between the data bytes.  (I plan to test my understanding by changing the number of stop bits in HyperTerminal and then seeing how it looks on the scope; I'll set the scope decoder to correspond to the HyperTerminal setting.)

But just to make sure I have it really dialed-in, I have read that in ASCII the convention is generally to have a 0 for a start bit and a 1 for a stop bit.  Right?  So the one key question I still wanted to pin down is that the demarcation between all bits is on the clock cycle - which would correpond to a rising or falling edge - but in the case of repeating bits (multiple 1s or multiple 0s in row) there would be no rising or falling leading edge,  so the demarcation is effectively the clock cycle.  Yes, no?  (But if there is a rising or falling edge then the next pixel over would be the graphical depiction of the beginning of the bit, right?)

I like the the idea of a logic analyzer that could both hide or reveal the extra bits beyond the data bits - that would be a helpful feature.  Do you have a favorite scope or LA that provides such flexibility or know of one?

Thanks again, EF

[Hideki]

ASCII has no direct connection to start or stop bits. All it is, is a table that maps a number to a certain character.
And watch out when you use the term RS-232. That's more about the actual voltages, connectors and signals used. In RS-232 a "0" is actually a voltage between 3 and 15 volts and "1" is a voltage between -3 and -15 volts. Signals going in or out of a microcontroller are NOT RS-232.

In asynchronous serial (UART-style) transmission the signal is normally 1 when no data is being sent. Then to signal the start of the transmission, it goes to 0 (the start bit). This falling edge is where the new data begins. This can happen at any time after a stop bit, so the start bit edge itself may not be exactly aligned with any previous bits. It will be the reference point for the coming data bits and stop bit.

Then comes a number of data bits, and while this is most usually 8 bits, it doesn't have to be exactly 8. It can in less common cases be, say, 5 or 9 bits. The receiver/decoder needs to know how many bits to expect and how long they should last. The edges no longer matter at this point, only the logic level. It will be sampled by the receiver in the middle of each bit (at the very least), so the receiver checks the state of the line 1.5 clocks after the start bit, then 2.5 clocks after the start bit etc. More advanced implementations will check the state multiple times in each bit period to attempt to filter out noise or other spurious transitions.

After the data, there is at least one stop bit, which is always 1. The reason for this is that regardless of what the data between the start and stops bits are, a new byte will always begin at the falling edge of the start bit, where it goes from 1 to 0.

It is possible to use more than one stop bit, even 1.5 stops bits. The effect of that is much the same as simply idling between each transmission.

Now, if you have a long transmission with no real pauses in between, and start looking at it from somewhere in the middle, it may not be possible to figure out where the data starts. Only when no data has been sent for a while (line has been 1 for long enough) can you be certain that the first 1 to 0 transition is an actual start bit and not one of the data bits.

[Electro Fan]

ASCII has no direct connection to start or stop bits. All it is, is a table that maps a number to a certain character.
And watch out when you use the term RS-232. That's more about the actual voltages, connectors and signals used. In RS-232 a "0" is actually a voltage between 3 and 15 volts and "1" is a voltage between -3 and -15 volts. Signals going in or out of a microcontroller are NOT RS-232.

In asynchronous serial (UART-style) transmission the signal is normally 1 when no data is being sent. Then to signal the start of the transmission, it goes to 0 (the start bit). This falling edge is where the new data begins. This can happen at any time after a stop bit, so the start bit edge itself may not be exactly aligned with any previous bits. It will be the reference point for the coming data bits and stop bit.

Then comes a number of data bits, and while this is most usually 8 bits, it doesn't have to be exactly 8. It can in less common cases be, say, 5 or 9 bits. The receiver/decoder needs to know how many bits to expect and how long they should last. The edges no longer matter at this point, only the logic level. It will be sampled by the receiver in the middle of each bit (at the very least), so the receiver checks the state of the line 1.5 clocks after the start bit, then 2.5 clocks after the start bit etc. More advanced implementations will check the state multiple times in each bit period to attempt to filter out noise or other spurious transitions.

After the data, there is at least one stop bit, which is always 1. The reason for this is that regardless of what the data between the start and stops bits are, a new byte will always begin at the falling edge of the start bit, where it goes from 1 to 0.

It is possible to use more than one stop bit, even 1.5 stops bits. The effect of that is much the same as simply idling between each transmission.

Now, if you have a long transmission with no real pauses in between, and start looking at it from somewhere in the middle, it may not be possible to figure out where the data starts. Only when no data has been sent for a while (line has been 1 for long enough) can you be certain that the first 1 to 0 transition is an actual start bit and not one of the data bits.

Hi Hideki - Thank you.

The reason for mentioning I read that in ASCII the convention is generally to have a 0 for a start bit and a 1 for a stop bit was based on this:  "Normal ASCII is transmitted using a zero start-bit, data bits, optional parity bits, and a one for a stop bit." http://www.csci.csusb.edu/dick/samples/comp.text.ASCII.html

However, per your advice (and similar advice from others here) I will better separate ASCII from RS232 (I have definitely seen ASCII tables and I have not seen any references in those tables to start and stop bits, just the translation between ASCII, Hex, Decimal, and Binary - at least in the tables I've seen).

I will study your reply further but one initial question regarding this:

"In asynchronous serial (UART-style) transmission the signal is normally 1 when no data is being sent. Then to signal the start of the transmission, it goes to 0 (the start bit)."

Given that the signal is normally 1 when no data is being sent (which on all the RS232 waveforms I've seen would be a low signal) then at the start of the transmission if the signal goes to 0 (the start bit), that would imply the start bit must be high - which it generally seems to be.  So far, so good (I think).  But in your post you go on to say "This falling edge is where the new data begins."  If the waveform was high for the start bit, then the falling edge would seem to need to be the end of the start bit and the beginning of the first data bit, no?  (Sorry, this is kind of hard to do without a chalk board.)

What I did understand (I think) is that "the start bit edge itself may not be exactly aligned with any previous bits. It will be the reference point for the coming data bits and stop bit."  I recently measured three consecutive byte durations and was happy to find that each byte lasted exactly (within a microsecond) the same amount of time from the beginning to the end of the byte - but I didn't measure the gaps between bytes and I will now go back and do that with the understanding that interval between bytes might vary, correct?

I understand from our post that the decoder is not looking for the start of a bit - rather it is looking for the middle of a bit and it is looking just for the logic (voltage) level - which makes sense as the system is now relatively more impervious to minor variations.  Cool!

I'm getting there - slowly, but surely (I think / I hope).  Thanks again, and thanks in advance for any more info and course corrections 

EF

[codeboy2k]

"This falling edge is where the new data begins."

Hideki is referring to the UART data signal here.  The signal pin (at the MCU or UART output ) is high ('1') during idle (no transmission). This is also called "MARK", and during idle the signal pin at the UART is "MARKING". When it falls to low ('0') at the UART pin, that is the beginning of the start bit. The start bit is always '0', or logic low, also called "SPACE". So the beginning of a start bit is a high to low, MARK to SPACE transition.  However, on the RS232 data stream on the wire, the TX and RX data signals are inverted.  MARK ('1') is at a low voltage level, in the range -15V to -3V, and SPACE ('0') is at a high voltage level, in the range +3V to +15V.  So when the line is idle, it is MARKING, so the voltage level is low voltage, somewhere between -15V to -3V. This is still called MARKING, just the voltage level for MARK is inverted on the RS-232 TXD and RXD wires. When the start bit begins, the signal will transition from continuous MARKING to SPACE, and this is a falling edge at the UART output, or a corresponding rising edge at the RS-232 wire data stream.

Getting your head wrapped around what's on the signal (at the UART) and what's on the line (at the wire) is crucial to debugging RS-232. Good on you for trying to get a deeper understanding of it here.

[Electro Fan]

"This falling edge is where the new data begins."

Hideki is referring to the UART data signal here.  The signal pin (at the MCU or UART output ) is high ('1') during idle (no transmission). This is also called "MARK", and during idle the signal pin at the UART is "MARKING". When it falls to low ('0') at the UART pin, that is the beginning of the start bit. The start bit is always '0', or logic low, also called "SPACE". So the beginning of a start bit is a high to low, MARK to SPACE transition.  However, on the RS232 data stream on the wire, the TX and RX data signals are inverted.  MARK ('1') is at a low voltage level, in the range -15V to -3V, and SPACE ('0') is at a high voltage level, in the range +3V to +15V.  So when the line is idle, it is MARKING, so the voltage level is low voltage, somewhere between -15V to -3V. This is still called MARKING, just the voltage level for MARK is inverted on the RS-232 TXD and RXD wires. When the start bit begins, the signal will transition from continuous MARKING to SPACE, and this is a falling edge at the UART output, or a corresponding rising edge at the RS-232 wire data stream.

Getting your head wrapped around what's on the signal (at the UART) and what's on the line (at the wire) is crucial to debugging RS-232. Good on you for trying to get a deeper understanding of it here.

Wow, this is great info.  I am pouring over it and trying to absorb it.

What I think I just got from your post is that where I have been focused on the "line" or "wire" side of things, you have introduced the UART "signal" part of the system architecture.  On the transmit side, the UART drives the timing as it is taking the parallel data out of the MCU and putting it into the serial stream.  Correct?

To recite:  In an idle state the UART is high (1) which is a Mark (Marking).  When it falls to low (0) we get the beginning of the start bit.  Start bits are 0s, known as Spaces.  The Mark to Space transition is the beginning of a start bit.

But the RS232 data (TX and RX) on the "wire" is inverted so now we call a low a Mark – yet we continue to associate the Mark with a 1 even though it is low voltage.  As such we have inverted polarity?  And likewise we continue to associate a Space with a 0 even though it is now high voltage? 

"When the start bit begins, the signal will transition from continuous MARKING to SPACE, and this is a falling edge at the UART output, or a corresponding rising edge at the RS-232 wire data stream."  This part of this sentence has me confused. 

In a possibly related area of confusion, I don’t yet know why these naming/descriptive conventions (Mark and Space) came about such that we have the inversion (inverted polarity I get but the seemingly inverted use of the terms Mark and Space I don't get) - but I’m betting there is a good reason and I’m guessing perhaps it has something to do with either how the UART buffers/paces/synchronizes between the MCU and the communications link and/or it has something to do with the fact that the transmit end must talk to the receive end in both directions – just some guesses.  Any further insight on this would be very interesting.

What I am (also still) confused/uncertain about are the pin assignments, especially as they relate to the terms “signal” and “line”.

Is it possible that on a male DB9 connector that pins 2 (RD) and 3 (TD) and maybe 5 (GND) are “line” pins and pins 1 (CD), 4 (DTR), 6 (DSR), 7 (RTS), 8 (CTS), and 9 (RI) are the “signal” pins?

If this is correct (maybe a long shot), is it possible that the signal pins are carrying their information in the inverted polarity relative to the data pins, but that all the pins are effectively synchronized (timing-wise) relative to one another by the UART?  Does there need to be a UART on both ends of a communications link?  It would seem both ends (two UARTs) need to be handshaking with each other?  If so, when a UART in a computer sends a text file to a scope (which decodes the text file), does that mean that inside the scope (within the decode function) there is a UART?

Sorry for the zillion questions (and no doubt still plenty of confusion) but it’s all pretty fascinating.  If you guys get tired of explaining I’ll understand, no worries.  But if you want to keep going I’m all in.  Thanks!

[codeboy2k]

To recite:  In an idle state the UART is high (1) which is a Mark (Marking).  When it falls to low (0) we get the beginning of the start bit.  Start bits are 0s, known as Spaces.  The Mark to Space transition is the beginning of a start bit.

But the RS232 data (TX and RX) on the "wire" is inverted so now we call a low a Mark – yet we continue to associate the Mark with a 1 even though it is low voltage.  As such we have inverted polarity?  And likewise we continue to associate a Space with a 0 even though it is now high voltage? 

Yes, exactly. You have it right.

"When the start bit begins, the signal will transition from continuous MARKING to SPACE, and this is a falling edge at the UART output, or a corresponding rising edge at the RS-232 wire data stream."  This part of this sentence has me confused.

It shouldn't confuse you, it's the same as what I said above, and you seemed to understand that part OK.  A MARKING idle line ('1') transitioning to SPACE ('0') is a falling edge at the UART output pin, and it is a rising edge at the line (on the wire) for the TXD and RXD lines only. These TXD and RXD are the only inverted lines.  The other signals from the UART are not inverted like this.

I don’t yet know why these naming/descriptive conventions (Mark and Space) came about such that we have the inversion (inverted polarity I get but the seemingly inverted use of the terms Mark and Space I don't get)

The naming has not inverted, only the voltages did. MARK is always '1'. SPACE is always '0'.   At the UART, MARK is logic high, might be 3.3V, or might be 5V. A SPACE is logic 0, let's say it's 0 volts.  These are the values of MARK and SPACE at the UART pins.  However, at the RS232 wire, these are inverted voltage levels, but not inverted meaning.  So, MARK is still always '1', logic high, but logic high is inverted voltage now, and is defined as between -3 and -15V. The voltage changes, the meaning does not. Same with the SPACE , logic 0, which on the RS232 line is defined to be a higher voltage, between +3 and +15V.  And again, these inverted voltages only apply to the TXD and RXD RS232 lines.  For all the other UART signals, such as CTS or DTR, a logic 1 would be +3 to +15V and logic 0 would be -3 to -15V. These are so called 'normal' voltage levels, not inverted.

What I am (also still) confused/uncertain about are the pin assignments, especially as they relate to the terms “signal” and “line”.

Is it possible that on a male DB9 connector that pins 2 (RD) and 3 (TD) and maybe 5 (GND) are “line” pins and pins 1 (CD), 4 (DTR), 6 (DSR), 7 (RTS), 8 (CTS), and 9 (RI) are the “signal” pins?

most people, myself included, are using the terms signal, line, data rather loosely, and not so specifically as you are trying to connect them. Perhaps we should be better at it. They are all 'signals', of one sort or another.  I tend to call the UART pins the 'signals', and the RS232 wires as the 'line'. I think others might use different terms, and this is what easily leads to confusion when talking about RS232. So you just need to think "are we talking about a data signal? and if so, are we talking about at the UART side or on the wire side?" because only those are the inverted ones and need special attention.

If this is correct (maybe a long shot), is it possible that the signal pins are carrying their information in the inverted polarity relative to the data pins, but that all the pins are effectively synchronized (timing-wise) relative to one another by the UART?  Does there need to be a UART on both ends of a communications link?  It would seem both ends (two UARTs) need to be handshaking with each other?  If so, when a UART in a computer sends a text file to a scope (which decodes the text file), does that mean that inside the scope (within the decode function) there is a UART?

Yes, the synchronization is done only by the start bit. Normally two pieces of equipment sending RS232 data to each other would need a UART at both ends, and both ends are using the control signals (transmitted at line voltages) to do the handshaking, as well as using the start bits to synchronize one frame of RS232 data.  However, in the case of the scope receiving the and decoding the RS232 data for display on the screen, the scope is not using a UART.  Since the data is sampled with an ADC inside the scope just like any other scope trace, they just use the sampled data in memory and analyze it after the sample has been captured. They analyze it for the start/data/parity/stop bits and display the decoded data on the screen. There is no need for a UART, but their software decoder is acting like a UART in order to decode the bits.

[Electro Fan]

codeboy2k - Thanks again!

I think I understand better now what is happening.  The UART signal pins (everything other than TXD and RXD data pins?) are working in a synchronized but parallel manner with the data pins.  (I was previously erroneously trying to reconcile the notion of somehow the UART signal functions came before the data line functions.)  What is really happening, I think, is that the UART signals are moving in an inverted manner (polarity-wise) relative to the data lines, but in parallel with the data lines.

When we talked about the "UART side" and the "wire side" I was thinking about side by side as in first one function (UART) and then the second function (data), ie, sequential rather than parallel - and it had me confused.  But now when I think of the UART function as being the UART signal pins along with the contribution of the start, stop, and polarity bits to the data pins it becomes much more clear.

Thought of this way, this sentence is now clear:  "When the start bit begins, the signal will transition from continuous MARKING to SPACE, and this is a falling edge at the UART output, or a corresponding rising edge at the RS-232 wire data stream."

Said another way, I think the UART is generally managing the signal pins but it also contributes the start bit timing to the TXD data pin (and probably also inserts the stop bit and any polarity bits – since those bits can’t come from the data signal path itself - unless perhaps the UART designates the timing of the start bit but the RS232 setup function, maybe separate from the UART function, dictates the start, stop, and polarity bits?).

Please feel free to straighten me out.  Thanks!  EF

[Hideki]

What you call the "RS232 setup function" doesn't exist. The UART does "everything" except handling the voltages used on the cable. I'm not sure what you mean by "the UART signal pins along with the contribution of the start, stop, and polarity bits to the data pins". It's all sequential, serial to me. There is no separate "data" and "start/stop/parity" path. RX and TX contains all you need.

The RS-232 part of your mystery is really only about converting from one set of voltages to another (and using standardized connectors and pinouts). The conversion is often done using a chip like this: http://en.wikipedia.org/wiki/MAX232

Yes, there are other signals apart from TxD/RxD, but you can ignore them if no data flow or modem control is required.

RS-232 was introduced in the early 60's and is slowly getting more and more outdated as time goes by. Very few recent products even use it, and those that do often do because of a need to communicate with old equipment. Yes, it's still useful basic knowledge but is definitely getting less relevant.

USB has taken over the role - at least for shorter distances. Chips from FTDI or Prolific convert the UART data to and from USB packages instead.

[Electro Fan]

What you call the "RS232 setup function" doesn't exist. The UART does "everything" except handling the voltages used on the cable. I'm not sure what you mean by "the UART signal pins along with the contribution of the start, stop, and polarity bits to the data pins". It's all sequential, serial to me. There is no separate "data" and "start/stop/parity" path. RX and TX contains all you need.

Ok, UART does everything but handle voltages on the cable, Thanks. Seems to me that the UART originates all the signals that go on all the pins except for the RX and TX data bits (which originate from deeper within a computer or other device).  The control signals (on their various assigned pins) are running on lines in parallel with the data signals (which are carried on the TX and RX data pins and lines).  The actual transmission of information on all the lines is of course serial but the serially transmitted control signals (on the pins other than TX and RX) run parallel to the serially transmitted data signals (hence the reference to the term "parallel" which admittedly seems of out of place in a method of communications that is referred to as "serial"). 

Moving on, the UART sets the time of the start bit which happens to be on the TX data pin (so the UART contributes some bits to the pin that is assigned to transmit data).  And of course the stop and parity bits in addition to the start bits are transmitted on the same pin as the data bits and bytes.  I'm pretty sure I have this right now (but could still be somewhat wrong); it's a little hard to express this stuff clearly in writing; thanks for the patience and persistence with your teaching.     

[codeboy2k]

you're getting it, but you need some minor clarifications. When you say the control signals are in parallel with the data signals, which are transmitted serially, I think you get it... but you are just wording it awkwardly.  The control signals originate from the UART (at either end) and are converted to the RS232 line voltages (logic 0: -3 to -15V, logic 1:  +3 to +15V) by a level convertor device like Hideki mentions, the MAX232.  The TXD and RXD also originate from the UART, at each end, and are also converted to the RS232 line voltages by the MAX232 chip, where (logic 0: +3 to +15V, logic 1: -3 to -15V) <<-- inverted.

all these lines are on the RS232 connector "in parallel" as you say, but you should not think of it that way.  All these lines just form the complete set of required data and control lines for an RS232 connection. And there might be 8 wires, or 3 wires or 25 wires... depending on the complexity of the implementation, but we don't need to get into that. The reason we don't need to get into that is because it is indeed an aging standard, as Hideko says, and the control signals can almost always be ignored with todays high speed, deep memory, fast processor computers.  Those control signals that we can ignore are useful for handshaking, when the receiving ends are too slow. That almost never happens these days, and most people who use RS232 nowadays take a shortcut and ignore the control lines, and only use a 3-wire connection of TXD, RXD and GND.

Now, that said... the TXD and RXD signal lines are bit asynchronous, meaning that they include the start bit, data bits, any parity and the stop bits in one frame, that is asynchronous (out of sync) with any other frame. The timing of one entire frame, and one frame only, consisting of [start/data/parity/stop] is defined by the transition of the start bit from MARK to SPACE, and all these [start/data/parity/stop] bits are sent sequentially on the TX data line by the UART (and received on the RXD line by the other UART).  It does not come from anywhere "deeper" as you wrote, the UART sends it.  However, and this is where I think you need some clarification, the data bits that are in between those start and stop bits comes "from deeper" for example from your terminal program and from the CPU. Those data bits (which are usually 8-bit ASCII, without any start/stop information) come from the terminal program, via the CPU , and arrive at the UART. The UART then dutifully frames them with a start and stop bit and sequentially sends it out the TX data line. It does the same with the next 8-bit data byte that arrives at the UART "from deeper" within the computer. I am using your wording here, because I think that's how you understand it, but just know that the UART is a parallel to serial convertor at the transmitting end, and a serial to parallel converter at the receiving end.  The serial conversion is done with start/stop framing bits, and the receiving end looks for those extra start/stop bits and removes them. So an 8-bit byte sent from one side ends up across the communications link and is recovered and turned back into an 8-bit parallel byte at the receiving end. 

And remember, the communications link is not part of the UART, or part of ASCII-- it is just the medium through which the bits travel. There are many different communications links, and many different ways that the actual meaningful data bytes are represented on that link. RS232 uses asynchronous framing with start and stop bits around each data byte. Other communications links will use other, often more complex, methods.

[Electro Fan]

Thanks codeboy2k - yes I understand that the data originates upstream of the UART (I've been using HyperTerminal to transmit data I created in Notepad).  I also realize the data is managed by the CPU (which is what I meant by deeper into the computer) relative to the UART; I consider the UART to be a part of the port at the exterior of the computer.  And I get that the UART converts parallel data into serial data streams on the TX end and serial data streams into parallel data on the RX end (and I probably added confusion by trying to say that the various pins and their associated lines run in parallel with one another, sorry).  And I also get the notion that RS232 is somewhat ancient and has largely been replaced by USB almost everywhere in the modern world.  The only reason I even mess around with RS232 DB9 connectors (vs USB) is that it gives me a fairly easy/elementary way to probe individual pins and observe the voltage changes that represent data (and associated control information).  I also get the Max232 chip; I have a variant here that does RS232 to TTL level conversions.  At my level of curiosity I looked to see if TTL would support ASCII code at the lower voltage than the levels supported by RS232   It's one thing to read about this stuff but it's another to actually plug cables and jumper wires together on correct pins, operate an oscilloscope, figure out triggering, figure out decoding, figure out how to store and retrieve frames, navigate among frames, measure stuff in the horizontal axis and vertical axis, etc.  I realize this is so junior as to be "why bother?" but everyone has to start somewhere.

I still might be somewhat confused (although I think to your point I'm mostly just wording some things awkwardly), but I think with your help and the help of others here I'm almost at the 100 level if not quite yet the 101 level of understanding.  Mostly what it took me a while to understand, if I have it correct, is that the control lines (I guess everything other than TXD, RXD, and GND) are using a polarity opposite of the of the TXD and RXD lines.  There was one line written in one of the posts that threw me off the trail but I think I'm almost back on track.  (Writing is difficult in part because even with plenty of emoticons it's hard to convey inflexion.) 

Even though almost no one seems to use the control lines anymore (or RS232 overall for that matter) I'd like to find a way to have two computers talk to each other via serial ports in a way that I could invoke some of the control commands and then be able to observe the two-way data communications and the associated control commands (especially the sequences and timing of the frames) on my scope.  Long story short, I'm strictly in educational mode and I use the theory to help me learn to use the scope and I use the scope to help me learn the theory.  I realize this is all very basic and not too exciting for the guys out there who are actually designing, fixing, and building stuff but for whatever reason I find it too be a lot of fun.

I've got several more such exercises in mind.  One goal is to be able to create some circults - maybe with pull up and pull down resistors, and also use some basic software to effectively create my own bits and bytes and prove that I can transmit and receive simple data streams in a way that I can "read"/decode the data on the scope.  In any event, thanks again very much for your very clear and and helpful writings.  It's much appreciated.  EF