LIN (Local Interconnect Network) bus is a low-cost serial communication protocol defined for automotive distributed systems.

Compared to CAN bus, LIN bus protocol is relatively simple and does not require high requirements for microcontrollers. Basic serial ports can be implemented, so the cost is lower.

As an auxiliary bus of CAN bus, LIN bus is a supplement to existing bus technology and is widely used in vehicle control fields such as doors, windows, headlights, and central locking.

1. Scheduling the transmission order of frames on the bus

2. Monitor data and handle errors

3. As a standard clock reference

4. Receive bus wake-up commands from slave nodes

5. The slave task cannot directly send data to the bus, and needs to receive the frame header sent by the master node and judge based on the information contained in the frame header.

(1) Master node and slave node

The LIN message frame consists of two parts: the header and the response.

During the transmission process, the host node is responsible for sending frame headers; The slave node is responsible for receiving the frame header and making parsing decisions on whether to send a response, receive a response, or not to reply. Nodes cannot actively send data outward.

(2) Schedule Table

The scheduling table (or schedule) of frames specifies the transmission order and time of frames on the bus, determines the direct interval time and order of each message, and therefore LIN bus communication is predictable. The scheduling table is located at the host node, and the host node determines the time interval order for sending each message based on the scheduling table. There can be multiple scheduling tables. In general, when it is the turn of a scheduling table to execute, the execution starts at the entrance of the scheduling table. When it reaches the last frame of the scheduling table, if no new scheduling table is started, it returns to the first frame of the current scheduling table for execution; It is also possible for an interrupt to occur when executing to a certain schedule, jumping to another schedule and then returning, such as event trigger frames being a typical example.

The slave nodes in LIN bus have three states: initialization state, sleep state, and working state.

① Synchronization interval segment (interval field)

The slave node can use a clock with relatively low precision and cost, such as an on-chip oscillator, instead of a high-precision clock. The resulting deviation from the master node clock needs to be adjusted through a synchronization segment, and the result of the adjustment is to make the bit rate of the slave node data consistent with that of the master node. The reference clock used for synchronization in the synchronization segment is the clock of the host node. The slave node calculates the bit rate of the host node by receiving the synchronization segment sent by the host node, and adjusts its own bit rate based on the calculation result.

③ PID field

Unlike CAN bus, LIN protocol does not specify the information of data length, and the data content and length are set in advance based on the frame ID. The data on the bus is broadcasted and can be received by any node, but it is not useful for every node. The specific node responsible for publishing and answering depends on the configuration of the application layer.

Normally, for frame responses, there is only one publishing node on the bus, otherwise errors may occur. Exception for event triggered frames, which may have 0, 1, and multiple publishing nodes.

⑤ Effectiveness and Field

Validation and field verification are used to validate the content of frame transmission, in order to improve data reliability.

According to the LIN2.1 specification, there are several frame types for LIN:

Unconditional frames, event triggered frames, sporadic frames, diagnostic frames, reserved frames

The frame ID range varies for different frames:

(1) Unconditional frame (0-0 × 3B)

An unconditional frame is a frame with a single publishing node, and regardless of whether the signal changes, the frame header will be unconditionally responded to.

Unconditional frames are transmitted in the fixed frame time slots assigned to them by the host task. Once a frame head is sent out on the bus, there must be a slave task to respond (i.e. unconditionally send a response).

① The publishing node of the response part with frame ID=0x30 is slave node 1, and the listening node is the host node. A typical application is to report the status of a certain signal from slave node 1 to the host node.

② The publishing node of the response part with frame ID=0x31 is the host node, and the listening nodes are slave node 1 and slave node 2. Typical applications include the host node publishing information to the slave node.

③ The publishing node of the response part with frame ID=0x32 is slave node 2, and the listening node is slave node 1. Typical applications include communication between slave nodes.

(2) Event trigger frame (0-0 × 3B)

The event triggered frame must have an independent ID that can be associated with multiple unconditional frames. Send a frame header within the event triggered frame time slot, and only send a frame response when there is a signal updated within the associated unconditional frame. If there is no frame response, the frame header is ignored. Frame responses can be sent by multiple nodes, and when a conflict occurs, they switch to the 'Conflict Resolution Schedule' and then switch back to the original schedule.

The event trigger frame is a frame used by the host node to query whether the signals of each slave node have changed in a frame gap. When there are multiple publishing nodes, resolve conflicts through a conflict resolution schedule.

When the frequency of signal changes in the slave node is low, the host task repeatedly queries the information of each node, which will occupy a certain bandwidth. In order to reduce bandwidth usage, the concept of event triggered frames has been introduced.

The main principle is that when the information status of the slave node has not changed, the slave node can not respond to the frame header sent by the host; When multiple node information changes simultaneously, triggering frame headers in response to events can cause bus conflicts. When the host node detects a conflict, it will query the conflict resolution progress table to send unconditional frames to each node in sequence (unconditional frames can only be responded by one node) to determine the information status of the slave node.

Multiple unconditional frames associated with event triggered frames need to meet the condition that the number of data bytes contained in the data field is equal, and the same validation and type are used. The first byte of the data field is the protected ID of the unconditional frame in order to know which associated unconditional frame the response is sent from. It cannot be published by different slave nodes in the same schedule as the time triggered frame.

(3) Occasional frames (0-0 × 3B)

Occasional frames refer to a set of regular frames that share a time slot and are only sent when needed. Occasional frames are frames sent by the host node to the bus during the same frame slot when its own signal changes.

When there are multiple associated response signals changing, arbitration is carried out through pre-set priorities. Similar to event triggered frames, incidental frames also define a set of unconditional frames. It is stipulated that occasional frames can only be published by the host node.

The transmission of occasional frames may occur in three situations:

1) When there is no signal change in the associated unconditional frame, the host does not need to send the frame header.

2) When an unconditional frame signal associated with it changes, send the frame.

3) When multiple unconditional frames undergo signal changes, they are sent in sequence according to the predetermined priority.