LIN (Local Interconnect Network) is a low-cost, single-wire serial communication protocol designed for short-distance, low-bandwidth communication in automotive and industrial applications, typically between a master node and one or more slave nodes. It operates at bit rates up to 20 kbps and is commonly used for body control functions where the overhead of CAN is not justified.
In practice
LIN appears most often in automotive body electronics: window lifters, mirror adjusters, seat position controllers, HVAC actuators, rain sensors, and interior lighting. A single master (usually a body control module or ECU) schedules all traffic by issuing frame headers; slaves respond only when addressed. Because the bus uses a single wire plus ground, wiring harness cost and weight are kept low compared to CAN or FlexRay.
A LIN cluster typically supports up to 16 slave nodes, though actual cluster sizes depend on system design. The physical layer uses a single-wire bus with voltage levels defined by the transceiver (nominally 12 V in automotive systems), with a dominant low state and a recessive high state. Many automotive-grade MCUs and SoCs include dedicated LIN controllers or UART-compatible LIN peripherals on-chip, and some also integrate the LIN transceiver, though the transceiver is often a separate external component (examples include NXP S32K, STM32 with USART LIN mode, Infineon AURIX, and Renesas RL78). On MCUs that lack a hardware LIN controller, the UART peripheral is often used directly since LIN frames are byte-oriented and compatible with standard async framing, though the break field and sync byte must be handled carefully.
LIN uses a master-controlled schedule defined in a LIN Description File (LDF), a text-based configuration file that describes nodes, frames, signals, and schedule tables and is generated by tooling and loaded into the master. The master issues a break field followed by a sync byte (0x55) and a protected identifier byte; depending on the frame type, the addressed slave transmits the data field, the master transmits it, or the behavior is event-triggered. This deterministic scheduling gives bounded latency but leaves no room for event-driven arbitration as in CAN. Sleep and wake-up modes are defined in the protocol, making LIN suitable for low-power body domains that need to wake on bus activity.
Common pitfalls include incorrect baud rate detection (the sync byte allows autobaud, but tolerance is tight at the 20 kbps maximum), missing break field length requirements (at least 13 bit times), and checksum version mismatches between LIN 1.x classic checksum and LIN 2.x enhanced checksum, which covers the identifier byte in addition to data bytes.
Frequently asked
How does LIN differ from CAN?
LIN uses a single wire, runs at up to 20 kbps, typically supports up to 16 slaves, and uses a master-only scheduling model with no arbitration.
CAN uses a differential two-wire bus, runs at up to 1 Mbps (Classic CAN) or up to 8 Mbps in the data phase (CAN FD, versus a lower arbitration-phase rate), supports many nodes, and uses non-destructive bitwise arbitration. LIN is significantly cheaper and simpler but offers lower speed and limited fault tolerance compared to CAN. In automotive designs, LIN and CAN are often used together: CAN for powertrain and safety systems, LIN for lower-priority body functions.
Can I implement LIN using a standard UART peripheral?
Often yes. LIN frames use standard 8-N-1 async framing, so a
UART can transmit and receive data bytes. However, the break field (at least 13 dominant bit times) is longer than a normal UART break, and you must also generate the sync byte (0x55) and compute the protected identifier and
checksum. Some MCUs, such as the STM32 series, add a dedicated LIN mode to their
USART peripheral that handles break generation and detection in hardware. Without hardware support, these must be handled in software with careful timing.
What is a LDF file and why does it matter?
A LIN Description File (LDF) is a text-based configuration file that defines the entire LIN cluster: node names, frame identifiers, signal mappings, schedule tables, and encoding information. Tools like Vector LINdb or open-source alternatives parse the LDF to generate code for both master and slave nodes. In practice, embedded developers receive an LDF from the system integrator and use it to configure their LIN
stack rather than writing frame schedules manually.
What is the difference between LIN 1.x and LIN 2.x checksums?
LIN 1.x uses a 'classic'
checksum computed over the data bytes only. LIN 2.x introduced an 'enhanced' checksum that also includes the protected identifier byte, providing slightly better error coverage. The two methods are incompatible; a mismatch between master and slave checksum versions is a common integration bug that causes otherwise well-formed frames to be rejected, though the exact failure mode (silent discard, timeout, or flagged error) depends on the LIN
stack and device implementation.
What physical layer hardware does LIN require?
LIN requires a dedicated transceiver IC (or integrated transceiver) that shifts between the
MCU's logic levels (typically 3.3 V or 5 V) and the single-wire bus voltage (nominally 12 V in automotive). Examples include the TJA1020, MCP2003, and TLE7259. The transceiver also handles the dominant/recessive
pull-up behavior and bus wake-up detection. Some automotive MCUs integrate the LIN transceiver on-chip, but external transceivers remain common in designs where the MCU is not co-located with the bus wiring.
Differentiators vs similar concepts
LIN is most often compared to
CAN. Both are used in automotive networks, but they serve different roles. LIN is single-wire, master-slave, up to 20 kbps, and suited for low-cost body electronics. CAN is differential two-wire, multi-master with arbitration, up to 1 Mbps (Classic) or 8 Mbps data phase (CAN FD), and used where higher speed, fault tolerance, or event-driven messaging is needed. LIN is also occasionally compared to
UART/
RS-232; while the physical framing is similar and a UART peripheral can be reused, LIN adds a defined break/sync header, a master scheduling model, a protected identifier byte, and a specified physical layer voltage range, making it a distinct protocol rather than simply a variant of raw UART.
