Analysis of LIN Bus Protocol in Automotive Network

The LIN protocol is suitable for low-cost, short-distance, low-speed network communication in automobiles. Its purpose is to transmit switch setting status and respond to switch changes. This article analyzes in detail the characteristics of the LIN bus protocol, the composition of the message protocol, the error detection mechanism, etc., and introduces how to implement a LIN bus slave node based on PICmicro devices.

The LIN protocol was developed by the European Vehicle Manufacturers Association for low-cost, short-distance, low-speed network communication. Its purpose is to transmit switch setting status and respond to switch changes, so communication events occur in more than 100 milliseconds, unlike other much faster automotive applications such as engine management. This protocol supports two-way communication on a single line, using a low-cost microcontroller driven by an RC oscillator, which can save the cost of crystal oscillators or ceramic oscillators. In addition, this protocol actually saves hardware costs at the expense of time and software. Each message of the LIN protocol contains data for automatic baud rate stepping, and can support a baud rate of up to 20k. At the same time, the low-power sleep mode can shut down the bus to avoid unnecessary power consumption. The bus can be powered by any node.

LIN bus characteristics

The LIN bus combines the characteristics of I2C and RS232: like the I2C bus, the LIN bus is pulled up to a high level through a resistor, and each node can pull the bus low through an open collector driver; like RS232, each byte is identified by a start bit and a stop bit, and each bit is transmitted asynchronously on the clock.

Figure 1 shows a typical LIN protocol configuration. When any node pulls the bus down, the bus is at a low level, indicating that the bus is in an occupied state; when all nodes float the bus, the bus is at the battery voltage (9-18V), which means that the bus is in a recessive state; in the idle state, the floating bus is pulled up to a high level through a resistor.

The bus operates at 9 to 18 volts, but all devices connected to the bus must be able to withstand 40V. Typically, the microcontroller is isolated from the bus by a line driver or receiver. The bus is terminated to Vbat at each node, the master node is terminated by a 1kΩ resistor and the slave node is terminated by a 20kΩ to 47kΩ resistor. The maximum bus length is 40 meters.

Each byte transmitted on the bus is framed with a start bit and a stop bit. The state of the start bit is the opposite of the idle state (that is, 0), while the stop bit is the same as the idle state, 1. In each byte, the least significant bit is transmitted first.

Message Protocol

The master node controls the bus by polling each slave node and sharing the slave node's data with the rest of the bus. The slave node only transmits data when it receives a command from the master node, so that bidirectional transmission is possible and no further arbitration is required. The message transmission begins with a synchronization interrupt from the master node, followed by the synchronization field and message field of the message. The synchronization field transmitted at the beginning of each message also sets the clock of the entire bus, and each slave node uses this byte to adjust its baud rate.

The synchronous interruption puts the bus into an occupied state, which lasts for the transmission time of 13 bits of data, followed by a stop bit (non-occupied state), which informs the slave node that a message is about to be transmitted. The maximum allowed clock drift between the master node and the slave node is 15%, so the synchronous interruption received by the slave node may only have the transmission time of 11 bits or as long as 15 bits of data.

The second byte of each message is the identification byte, which is used to tell the bus what data is transmitted after this byte and which node should respond, as well as the length of the response (the identification field is shown in Figure 2). Only one slave node will respond to a command, and the slave node will only send data under the instruction of the master node. As long as the data appears on the bus, every node can receive it. Therefore, there is no need for the master node to specifically control the communication between slave nodes.

Since a cheap RC oscillator is used in the design, the slave node must detect the baud rate of the master node and adjust its own current baud rate every time it transmits. Therefore, each communication starts with a synchronization byte consisting of alternating "0" and "1". The identification field follows the synchronization field, which tells the bus what is transmitted later. The identification field is divided into three subfields. The lowest 4 bits (0-3 bits) are used to address the device on the bus, the middle two bits (4-5 bits) are the length of the message transmitted later, and the highest two bits (6-7) are used as parity bits.

Except for the sleep command, the LIN protocol does not define the content of each message. Other commands are defined by specific applications.

Error detection mechanism

The errors described below must be detected and counted within each node.

Bit Error - The transmitting node must compare the data bit it thinks it should transmit with the data bit that actually appears on the bus. Because the bus requires response time, the controller must wait long enough before detecting the data bit. Assuming the minimum voltage flip rate is 1V/μs and the bus maximum voltage is 18V, the transmitter must wait 18μs to detect whether the data bit on the bus is correct.

Checksum Errors - The content of each message is protected by a checksum byte.

Parity error - The 6 data bits of the command byte are protected by two parity bits, which need to be recalculated and compared. If an error occurs, the current command should be ignored and the error should be recorded. There is no direct error reporting mechanism in the LIN protocol, but each slave node should track its own errors, and the master node can require the slave node to transmit the error status as part of the normal message protocol.

LIN bus and CAN bus

The LIN protocol is not directly compatible with the CAN bus, but it is expected that the two will interoperate. The CAN bus may be used throughout the car to achieve communication, while the LIN bus is only used in local circuits of the car, such as the doors. In order to connect the two buses, a CAN-LIN protocol interface node is required, which collects information from the LIN bus nodes and then transmits it to the CAN bus.

Low power sleep mode

The master node instructs all nodes to enter sleep mode by sending the identification code 0x80. The content of the data byte following the sleep command is undefined. The slave node that receives the sleep command should set itself up so that it can wake up when the bus changes and turn off its own voltage to minimize current consumption. When in sleep mode, the bus will be at a high level and no current will be consumed.

Any node can wake up the bus by sending a wake-up signal. After receiving the wake-up signal, all nodes should generally be activated and wait for the master node to start bus polling.

Hardware Example

Figure 3 shows an example of hardware consisting of two buttons and three LEDs. For every ten presses of button 1, LED1 changes state. Similarly, for every ten presses of button 2, LED2 changes state. As a response to ID1, the number of button presses is transmitted to the bus. As a response to ID4, an update of the number of button presses is transmitted to the bus.

Software Operation

The LIN protocol program works under the interrupt triggered by RB0 to realize the sleep/wake-up of the bus. When the interrupt is triggered, the program counts the length of the low-level data bit, then reads the synchronization byte and determines the data bit time, and finally compares it with the initial data bit time to determine whether the initial low-level time is greater than 10 data bits. If it is greater than 10, it is a synchronization interrupt, and if it is less than 10, it is a wake-up signal. If it is a wake-up signal, the program exits and continues to wait for the synchronization interrupt; if it is a synchronization interrupt, the program reads the command byte, checks the parity bit and checks the action table to determine the next action. The action table defines the source or destination of the data on the bus.

To initialize the slave handle of the LIN protocol, the user must call the InitLinSlave program, which initializes the RB0 interrupt pin and the TMR0 register. The TMR0 register is used to measure the length of the data bits and generate the baud rate. After the initialization is completed, the user can execute his own program. Once a falling edge is detected on the RB0 pin, the user program will be interrupted. When a falling edge is detected, the program jumps to the interrupt service routine. All interrupt sources except TMR0 and RB0 interrupts must be disabled to allow accurate measurement of the synchronization field. After the baud rate is calculated, the interrupt service routine exits execution.

When the next RB0 interrupt occurs, the LIN protocol slavehandler automatically enters the receive mode to receive the identification field or data byte. If the start bit of the identification field is detected, the identification field is received and decoded. Then, the corresponding code is executed according to the received identification, such as storing data or lighting an LED. After a frame transmission on the bus is completed, the flag FCOMPLETE is set. This flag indicates that all data has been received correctly and can be processed subsequently. This flag is cleared by the user firmware.