Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Serial port
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==Settings== {| class="wikitable floatright" style="width: 33%;" |+ Common serial port speeds ! style=max-width:5em | [[Bit rate|Bit rate (bit/s)]] !! style=max-width:5em | Time per bit (ΞΌs) !! style=max-width:6em | [[Windows]] predefined serial port speed<ref>{{Cite web |title=_SERIAL_COMMPROP (ntddser.h) - Windows drivers {{|}} Microsoft Learn |url=https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddser/ns-ntddser-_serial_commprop |work=Windows Hardware Developer |publisher=[[Microsoft]] |date=2022-09-01 |access-date=2025-02-08}}</ref><ref name="winbase.h">{{cite web |title=DCB (winbase.h) - Windows apps {{|}} Microsoft Learn |url=https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-dcb |work=Windows App Development |publisher=[[Microsoft]] |date=2021-04-01 |access-date=2025-02-08}}</ref> || Common applications |- | 75 || 13333.3 || {{yes}} || |- | 110 || 9090.9 || {{yes}} || [[Bell 101 modem]] |- | 134.5 || 7434.9 || {{yes}} || [[IBM 2741]] terminal |- | 150 || 6666.6 || {{yes}} || |- | 300 || 3333.3 || {{yes}} || [[Bell 103 modem]] or [[ITU-T V.21|V.21]] modem |- | 600 || 1666.7 || {{yes}} || |- | 1,200 || 833.3 || {{yes}} || [[Bell 202]], [[Bell 212A]], or [[ITU-T V.22|V.22]] modem |- | 1,800 || 555.6 || {{yes}} || |- | 2,400 || 416.7 || {{yes}} || [[V.22bis]] modem |- | 4,800 || 208.3 || {{yes}} || [[V.27ter]] modem |- | 7,200 || 138.9 || {{yes}} || |- | 9,600 || 104.2 || {{yes}} || [[ITU-T V.32|V.32]] modem |- | 14,400 || 69.4 || {{yes}} || [[V.32bis]] modem |- | 19,200 || 52.1 || {{yes}} || [[Modbus]] serial |- | 31,250 || 32 || {{no}} || [[MIDI]] port |- | 38,400 || 26.0 || {{yes}} || |- | 56,000 || 17.9 || {{yes}} || [[ITU-T V.90|V.90]]/[[V.92]] modem |- | 57,600 || 17.4 || {{yes}} || [[V.32bis]] modem with [[V.42bis]] compression |- | 76,800 || 13.0 || {{no}} || [[BACnet]] MS/TP networks<ref>{{Cite web | title = BACnet MS/TP Overview Manual | url = http://www.neptronic.com/Controls/PDF/EVC/BACnetModbus/BACnet%20MSTP%20Overview%20Manual-160405.pdf | publisher = Neptronic | access-date = September 26, 2019 | archive-url = https://web.archive.org/web/20200110133346/http://www.neptronic.com/Controls/PDF/EVC/BACnetModbus/BACnet%20MSTP%20Overview%20Manual-160405.pdf | archive-date = January 10, 2020 | url-status = live }}</ref> |- | 115,200 || 8.68 || {{yes}} || [[ITU-T V.34|V.34]] modem with [[V.42bis]] compression, low cost serial [[ITU-T V.90|V.90]]/[[V.92]] modem with [[V.42bis]] or [[ITU-T V.44|V.44]] compression |- | 125,000 || 8.00 || {{no}} || ISO 11898-3 CAN bus |- | 128,000 || 7.81 || {{yes}} || [[Basic Rate Interface]] [[ISDN]] [[terminal adapter]] |- | 230,400 || 4.34 || {{no}} || [[LocalTalk]], [[Econet]], high end serial [[ITU-T V.90|V.90]]/[[V.92]] modem with [[V.42bis]] or [[ITU-T V.44|V.44]] compression<ref>{{Cite web | url = https://www.multitech.com/documents/publications/data-sheets/86002093.pdf | title = MultiModem ZBA | publisher = Multi-Tech Systems, Inc | date = January 2019 | access-date = September 26, 2019 | archive-url = https://web.archive.org/web/20190303121617/https://www.multitech.com/documents/publications/data-sheets/86002093.pdf | archive-date = March 3, 2019 | url-status = dead }}</ref><ref>{{Cite web | url = https://unicom.usr.com/support/3453c/3453c-ug/control_data_rates.html | title = Courier 56K Business Modem: User Guide: Controlling Data Rates | publisher = [[USRobotics]] | date = 2007 | access-date = September 26, 2019 | archive-url = https://web.archive.org/web/20170804100605/http://unicom.usr.com/support/3453c/3453c-ug/control_data_rates.html | archive-date = August 4, 2017 | url-status = live }}</ref> |- | 250,000 || 4.0 || {{no}} || [[DMX512]], stage lighting and effects network |- | 256,000 || 3.91 || {{Yes}} || |} Serial standards provide for many different operating speeds as well as adjustments to the protocol to account for different operating conditions. The most well-known options are speed, number of data bits per character, parity, and number of stop bits per character. In modern serial ports using a UART integrated circuit, all these settings can be software-controlled. Hardware from the 1980s and earlier may require setting switches or jumpers on a circuit board. The configuration for serial ports designed to be connected to a PC has become a de facto standard, usually stated as 9600/8-N-1. ===Speed=== Serial ports use two-level (binary) signaling, so the data rate in bits per second is equal to the symbol rate in [[baud]]. The total speed includes bits for framing (stop bits, parity, etc.) and so the effective data rate is lower than the bit transmission rate. For example, with 8-N-1 character framing, only 80% of the bits are available for data; for every eight bits of data, two more framing bits are sent. A standard series of rates is based on multiples of the rates for electromechanical [[teleprinter]]s; some serial ports allow many arbitrary rates to be selected, but the speeds on both sides of the connection must match for data to be received correctly. Bit rates commonly supported include 75, 110, 300, 1200, 2400, 4800, 9600, 19200, 38400, 57600 and {{nowrap|115200 bit/s}}.<ref name="winbase.h"/> Many of these standard modem bit rates are multiples of either {{nowrap|1.2 kbit/s}} (e.g., 19200, 38400, 76800) or {{nowrap|0.9 kbit/s}} (e.g., 57600, 115200).<ref>{{cite web |url=https://cdn.hackaday.io/files/1614916909230944/SX1272_DS_V4.pdf |title=SX1272/73 - 860 MHz to 1020 MHz Low Power Long Range Transceiver Datasheet |publisher=[[Semtech]] |date=January 2019 }}</ref> [[Crystal oscillator]]s with a frequency of 1.843200 MHz are sold specifically for this purpose. This is 16 times the fastest bit rate, and the serial port circuit can easily divide this down to lower frequencies as required. The capability to set a bit rate does not imply that a working connection will result. Not all bit rates are possible with all serial ports. Some special-purpose protocols such as [[MIDI]] for musical instrument control, use serial data rates other than the teleprinter standards. Some serial port implementations can automatically choose a bit rate by observing what a connected device is sending and synchronizing to it. ===Data bits=== The number of data bits in each character can be 5 (for [[Baudot code]]), 6 (rarely used), 7 (for true [[ASCII]]), 8 (for most kinds of data, as this size matches the size of a [[byte]]), or 9 (rarely used). 8 data bits are almost universally used in newer applications. 5 or 7 bits generally only make sense with older equipment such as teleprinters. Most serial communications designs send the data bits within each byte [[least significant bit]] first. Also possible, but rarely used, is [[most significant bit]] first; this was used, for example, by the [[IBM 2741]] printing terminal. The order of bits is not usually configurable within the serial port interface but is defined by the host system. To communicate with systems that require a different bit ordering than the local default, local software can re-order the bits within each byte just before sending and just after receiving. ===Parity=== {{Main|Parity bit}} ''Parity'' is a method of detecting errors in transmission. When parity is used with a serial port, an extra data bit is sent with each data character, arranged so that the number of 1 bits in each character, including the parity bit, is always odd or always even. If a byte is received with the wrong number of 1s, then it must have been corrupted. Correct parity does not necessarily indicate absence of corruption as a corrupted transmission with an even number of errors will pass the parity check. A single parity bit does not allow implementation of [[error correction]] on each character, and [[communication protocol]]s working over serial data links will typically have higher-level mechanisms to ensure data validity and request retransmission of data that has been incorrectly received. The parity bit in each character can be set to one of the following: * '''None (N)''' means that no parity bit is sent and the transmission is shortened. * '''Odd (O)''' means that the parity bit is set so that the number of 1 bits is odd. * '''Even (E)''' means that the parity bit is set so that the number of 1 bits is even. * '''Mark (M)''' parity means that the parity bit is always set to the mark signal condition (1 bit value). * '''Space (S)''' parity always sends the parity bit in the space signal condition (0 bit value). Aside from uncommon applications that use the last bit (usually the 9th) for some form of addressing or special signaling, mark or space parity is uncommon, as it adds no error detection information. Odd parity is more useful than even parity since it ensures that at least one state transition occurs in each character, which makes it more reliable at detecting errors like those that could be caused by serial port speed mismatches. The most common parity setting, however, is ''none'', with error detection handled by a communication protocol. To allow detection of messages damaged by [[line noise]], electromechanical teleprinters were arranged to print a special character when received data contained a parity error. ===Stop bits=== Stop bits sent at the end of every character allow the receiving signal hardware to detect the end of a character and to resynchronize with the character stream. Electronic devices usually use one stop bit. If slow electromechanical [[teleprinter]]s are used, one-and-one-half or two stop bits may be required. ===Conventional notation=== [[File:Puerto serie Rs232.png|frame|In this diagram, two [[byte]]s are sent, each consisting of a start bit, followed by eight data bits (bits 0-7), and one stop bit, for a 10-bit character frame in 8N1 format. The line on a diagram staying up indicates an excited ("mark" or 1) state of the line, low β unasserted ("space" or 0) state. Both up and low lines drawn for a bit (forming a square) indicate a data bit with value that can be either 0 or 1]] The data/parity/stop (D/P/S) conventional notation specifies the framing of a serial connection. The most common configuration for the [[Personal computer|personal computing devices]] is '''8-N-1''' (also spelled as 8N1, 8-None-1<ref name="modemhelp"/>), in which there is one start bit, eight ("8") data bits, no ("N") parity bit, and one ("1") stop bit.<ref>{{cite web |title=Definition of N-8-1 |url=https://www.pcmag.com/encyclopedia/term/n-8-1 |website=PCMAG |language=en}}</ref> In this notation, the parity bit is not included into the count of the data bits. For example, 7/E/1 (7E1) means that an even parity bit is added to the 7 data bits for a total of 8 bits between the start and stop bits. The abbreviation is usually given together with the line speed in [[bits per second]], as in "9600β8-N-1". The speed (or [[baud rate]]) includes bits for [[Data frame|framing]] (stop bits, parity, etc.), thus the effective data rate is lower than the baud rate. For 8-N-1 encoding, only 80% of the bits are available for data (for every eight bits of data, ten bits are sent over the serial link — one start bit, the eight data bits, and the one stop bit).<ref name="modemhelp">{{cite web | url = http://www.modemhelp.net/faqs/8n1.shtml | title = What does 8-N-1 mean? | access-date = 2013-12-25 | publisher = modemhelp.net }}</ref> ===Flow control=== [[Flow control (data)|Flow control]] is used in circumstances where a transmitter might be able to send data faster than the receiver is able to process it. To cope with this, serial lines often incorporate a [[Handshake (computing)|handshaking]] method. There are ''hardware'' and ''software'' handshaking methods. '''Hardware handshaking''' is done with extra signals, often the RS-232 RTS/CTS or DTR/DSR signal circuits. RTS and CTS are used to control data flow, signaling, for instance, when a buffer is almost full. Per the RS-232 standard and its successors, DTR and DSR are used to signal that equipment is present and powered up so are usually asserted at all times. However, non-standard implementations exist, for example, printers that use DTR as flow control. '''Software handshaking''' is done for example with [[ASCII]] control characters [[XON/XOFF]] to control the flow of data. The XON and XOFF characters are sent by the receiver to the sender to control when the sender will send data, that is, these characters go in the opposite direction to the data being sent. The system starts in the ''sending allowed'' state. When the receiver's buffers approach capacity, the receiver sends the XOFF character to tell the sender to stop sending data. Later, after the receiver has emptied its buffers, it sends an XON character to tell the sender to resume transmission. It is an example of [[in-band signaling]], where control information is sent over the same channel as its data. The advantage of hardware handshaking is that it can be extremely fast, it works independently of imposed meaning such as ASCII on the transferred data and it is [[state (computer science)|stateless]]. Its disadvantage is that it requires more hardware and cabling, and both ends of the connection must support the hardware handshaking protocol used. The advantage of software handshaking is that it can be done with absent or incompatible hardware handshaking circuits and cabling. The disadvantage, common to all in-band control signaling, is that it introduces complexities in ensuring that control messages get through even when data messages are blocked, and data can never be mistaken for control signals. The former is normally dealt with by the operating system or device driver; the latter normally by ensuring that control codes are [[escape sequence|escaped]] (such as in the [[Kermit protocol]]) or omitted by design (such as in [[ANSI escape code|ANSI terminal control]]). If '''no handshaking''' is employed, an overrun receiver might simply fail to receive data from the transmitter. Approaches for preventing this include reducing the speed of the connection so that the receiver can always keep up, increasing the size of [[data buffer|buffers]] so it can keep up averaged over a longer time, using delays after time-consuming operations (e.g. in [[termcap]]) or employing a mechanism to resend data which has not been received correctly (e.g. [[Transmission Control Protocol|TCP]]).
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)