UART / "RS232" I/O

1/ baud = bittime in seconds.

Paul B. Webster says:

Technically, there is *no* RS-232 standard showing [how data bits are related to signal levels], 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, [and which is typically associated with RS-232] it is asynchronous "teletype" protocol. You will find it described in UART datasheets.

The actual specification is at http://global.ihs.com/. $61 last I looked. Search for Document Number TIA/EIA-232 revision F. CCITT V.24 is the equivalent European version of the RS-232 rev E standard.

Rev C spec's a max cable length of 15m. Rev D & E changed that to a max capacitive load of 2500pF.

Rev D imposed a maximum risetime through the transition region of 5us or 4% of the bittime. Rev E just says 4% of the bittime. There is a 30V/us max slewrate.

The spec (up to & including E) limits datarate to 20kbps, but if you extrapolate the (Rev E) risetime limit to its intersection with the slewrate limit, you get a max datarate of 200kbps.

But when most people say RS232, they are thinking about asynchronous serial and so we will continue to discuss that here:

Steve Thackery of Suffolk, England. says:

A stop bit happens to be a mark, a start bit is a space. The duration of the bits is determined by the bits-per-second rate of the line (often, but not always correctly, called the baud rate). So, on a 1200 baud link each bit lasts 1/1200th of a second.  The thing about asynchronous comms is that there is, or can be, any amount of idle time between the characters transmitted. So the receiver can't synchronise itself to the incoming bit stream (hence "asynchronous"). When the line is idle, the transmitter sends out a continuous "marking" (negative) voltage. You might like to think of this as a continuous stream of stop bits. The receiver sits there drumming its fingers, having no idea when the next character is going to arrive.

Eventually a character is transmitted. Here is the crucial part: the start bit is of opposite polarity, so the first thing the receiver sees is a transition from a mark to a space. The receiver now knows the precise moment in time at which this transition - the leading edge of the start bit - arrived. It also knows how long each bit (including the start bit) should last (i.e. 1/1200th of a second). So, it waits for the duration of half a bit and samples the voltage on the line again.

This puts it right smack in the middle of the start bit. If it still sees a 'space' it knows the start bit is real (i.e. it wasn't just a noise blip on the line). It then waits 1/1200th of a second and samples the line yet again. This puts it smack in the middle of the first bit of the character. It continues to sample at 1/1200th of a second intervals thereafter until it gets to the stop bit(s). Once it has registered the stop bit it then goes into continuous monitoring mode in order to pick up the next transition to a start bit.

You will see that the receiver's internal clock (for measuring out the 1/1200th of a second sampling intervals) doesn't need to be particularly accurate. All that's required is that it stays within half a bit over the duration of the received character. In other words, an accuracy of a few percent if fine. This means that asynchronous comms are cheap and easy to implement.

Dan Michaels says:

[I made] an RS-232 network - ie, a bunch of PNP transistors with their collectors all tied together driving a single Tx line - ie, "wired-OR". Problem was, if one of the source ckts was "disconnected" from the line by simply turning it off, its PNP operated in the inverse mode to keep the ckt powered up - or at least partially powered up - and it loaded down the Tx buss. Solution was to put a diode between the collector and the common Tx bus.

PIC RS232@ Laser Serial Links

Detecting riseing and falling edge events (some PIC specific code, but a very interesting idea)

Manchester encoding

Books:

See also:

Questions:

Archive:

See: