Is the difference between a TTL serial input or output on an Arduino board, and a common RS-232 serial port such as on an instrument or PC, merely the different voltage levels (with RS-232 being much higher voltage than TTL)? Or are there also differences in how each byte is surrounded with start and stop and parity and other such bits, or in timing details, or other stuff?
I think the RS-232 would have to be without hardware handshaking to be comparable, as TTL serial does not seem to imply hardware handshaking lines.
I am new to Arduino and am contemplating a project to process two incoming RS-232 data streams, plus some light digital and analog data acquisition, into a third outgoing RS-232 stream. I see RS-232 shields that seem to add one port, but was thinking of using an Arduino Mega which has 4 TTL serial ports. I hoped buying some simple RS-232 transcievers, which I haven’t used before but believe are essentially analog devices that rescale voltages and change impedances.
RS-232 operates on different voltages than TTL, and has (optional) CTS/RTS flow control lines. The timing, stop/start/parity bits, are determined by the software interface, and should be the same whether you are using TTL or RS232 signaling levels. You should be able to just use any standard RS232 port drivers for your project, but you may have to write some custom code to read and drive the flow control lines.
The only difference is signaling levels.
True RS232 is ± 25v, and the signal levels are inverted with respect to their TTL levels (a “1” is -25v). Most “RS232” devices these days used very relaxed definitions of what is a “1” and what is a “0” - they will usually accept 0v as a “1” and 5v as a “0.”
The timing (start/stop and bit times) for both standards is identical.
“TTL” simply defines legal voltage levels and hardware interfacing details (sink currents, use of pull-up resistors, etc.). It says nothing about handshaking or how 1s and 0s will represent data. RS-232 is more encompassing; it defines voltage levels, timing, handshaking, and a protocol for how 1s and 0s represent data.
True, except that the signaling voltages aren’t as simple as ±25v.
Mark (“1”) is any negative voltage between -3 and -25 volts. Space (“0”) is any positive voltage between +3 and +25 volts. Voltages in “no man’s land” (between -3 and +3 volts) is “undefined”.
±12v used to be very common for RS-232 signalling, because most old computers already had power supplies and rails for ±12v (for other uses; some old logic IC families and CPUs needed these voltages for their own operations), and the voltage is high enough to support long runs without sagging into the “undefined” levels.
However, nowadays most RS-232-voltage signals are created with single-chip transceivers which accept +5v and internally pumps it to ±7.5v or so. Example.
There are some USB-RS232 converters that do not work correctly with all RS232 devices. I beat my head against this problem for a long time until I determined that they were outputting slightly more than 0 volts for a “1.” This meant that it would work with many, but not all, RS232 receivers. My experience is that FTDI chipsets work better than Prolific ones.
Not all USB-RS232 converters implement all the handshaking lines correctly. Once again, the FTDI chipsets seem to be better.
TTL level serial is actually pretty common. Back in the days when everything was done with discrete chips you would start with TTL level serial and then would use a dedicated chip to convert the voltage levels. Those chips are still available if you want to do the same thing with your Arduino. BTW, the logic inversion from TTL to RS-232 is intentional, and it allows the driver to be little more than a single transistor.
There is more to the RS-232 standard than just the logic inversion and voltage difference. RS-232 also specifies that you can short any pin to any other pin and that you can apply up to +/- 25 volts on any pin without damage. That protection is usually provided by the driver chip. I don’t know about the Arduino but the TTL level input/output of many microcontrollers is not protected and can be damaged by a short or an overvoltage.
Note that there are a lot of serial ports that don’t quite comply to the standard. One common one I used to run into a lot was the serial port on old laptops (back when laptops had serial ports). A regular PC serial port would usually put out +/- 12 volts but laptop serial ports often used +12 and 0 volts, lacking the -12. There are cheap and small chips that will provide the +/- 12 from a single +5 volt supply these days so you don’t tend to run into this sort of thing on modern serial ports. Then again, most laptops don’t even have serial ports these days. Some modern serial ports will accept +12 and 0. Others won’t. The RS-232 spec does say +3 to +25 and -3 to -25, so +12 and 0 is definitely not to spec. You do run into it from time to time though.
One thing I run into a lot with modern USB serial ports is that they often “stutter” when sending data. In other words, if you send the ASCII characters 123456789 what often comes out the port is something like 12345 (slight pause) 6789. Most serial protocols don’t really care about the slight pause, but some older industrial control protocols have character timeouts and will fail the packets if there is a pause in the middle of them.
Handshaking on RS-232 is optional. Some things use it, some things don’t. It is very common to see RTS-CTS jumpered together in the RS-232 cable, as well as DSR, DTR, and DCD jumpered together. This ends up faking out the serial port so that even if it uses the handshaking signals it will still communicate. Effectively though, once you do this you are only using TX and RX (and GND of course) and no handshaking.
If you have any control over the protocol, make sure you use checksums or some other method of verifying data integrity. It is very easy for data to get garbled on RS-232.
Everything I do is ASCII and, occasionally, serial data bytes, and it actually never occurred to me to think about packet data on RS-232. Is packet used there? What sort of applications? I realize USB converters are packet data on the USB side - you’re saying packet RS-232, right? It would make sense, for applications where error recovery is needed, I just never contemplated it.
The old serial RS-232 mouse protocol was a 3 byte packet, using 7 data bits:
Byte 1: 1 LB RB Y Y X X
Byte 2: 0 X X X X X X
Byte 3: 0 Y Y Y Y Y Y
Where LB and RB are the left button and right button, and XXXXXX and YYYYYY are the displacement in the X and Y directions respectively.
There was no checksum or any other data checking (no parity bit either). When they switched to 3 button mice they added another byte to the protocol.
I personally work in the field of industrial control. Fifteen to twenty years ago, serial protocols were extremely common. The most widely used was the Modbus protocol used by Modicon industrial controllers, because Modicon intentionally released it as an open spec to encourage other people to interface to their controllers.
The basic data format of a Modbus packet ls:
Station address: 1 byte
Function code: 1 byte
Data: (variable length, depended on function code)
CRC check: 2 bytes
There were two basic formats of Modbus. The first, called Modbus RTU, sent the data exactly as above, using 8 bit bytes (the default was usually 8 data bits, even parity, one stop bit). The alternate version, called Modbus ASCII, took each byte and converted into two 7 bit ASCII bits. In other words, if the function code was 03, it would send two bytes for the function code, an ASCII 0 followed by an ASCII 3. ASCII therefore took twice as many bytes to transmit data as RTU.
Modbus has evolved into Modbus TCP, which is basically the same data format (minus the CRC check at the end) with an added header, converted into TCP/IP ethernet packets.
If you want details or just want to see exactly how complicated the Modbus spec is, there is much more info here:
Note that many devices only implement a very small subset of the available function codes.
SLIP and PPP were common serial line protocols that folks used to connect to the internet back in the days when everyone had modems connected to RS-232 serial ports.
These are just a few examples. There are many more.