Understanding LIN Communication: Master-Slave Process.
Tags: tutorial, career, lin, automation
Published: 2023-10-06 10:50:00

Hello Readers, 👋😍
My name is Aravind B N, and I work at "Luxoft India" as a Junar Software Developer. Luxoft has given me several opportunity to work on various projects, which has inspired me to discuss the important processes involved in developing a LIN (Local Interconnect Network) protocol in Application Layer and Data Link Layer [part 2](https://dev.to/arvind_b_n_luxoft/understanding-the-lin-protocol-comprehensive-examination-of-communication-procedures-2kml). This is part 3 of the LIN protocol. Here we will discuss the communication process in detail.

**LIN Communication Process**

**_LIN Communication_**
Communication in a cluster is based totally on a master-slave structure. This method means that there's always one node that, as master, controls all conversation between the diverse slaves. The manage is applied by simplest allowing the subordinate slaves to transmit information when they're asked to accomplish that with the aid of the privileged master. The master does this by sending a request (frame header) to the bus, which the respective slave supplements with a response (frame response). This aggregate of requests and reactions is referred to as a body (see figure: Frame).

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9czzb401vtzvy97rnct9.png)

**_Bus Access_**
The bus has access to the method because the master delegates send each answer in a group, which is known as the delegates token. Its advantage is that communication is basically collision-free, allowing for reliable record transfer. This is because using the grab only allows specified answers to individual requests, which enables the building of a sending plan (Schedule). The authorized token method is therefore classed as a predictable bus get-in-to method.

**_Restrictions_**
The disadvantage of using a grasp for primary control is that the grasp can fail, resulting in the failure of all communication. As a result, the bus device is unsuitable for safety-critical packages requiring guaranteed functionality. Another shortcoming is that it is not designed for event-driven communication. Because a request from the master is always required, slaves cannot access the bus autonomously to send messages.

**_Message Types_**
LIN was expanded with additional messages to make up for the drawback of event-driven verbal exchange. These messages enable sending actions that depart from the delegated oken's fundamental principles. There are four different message types—the unconditional frame, sporadic frame, event-triggered frame, and diagnostic frame (I'll explain these frames in detail in an upcoming article.)

**Master Task / Slave Task**
Since there may be no communication controller, the protocol is applied inside the shape of software components on the microcontroller. It is through these that the unique node gets a master task or slave challenge, which is wanted to carry out the preferred communication. In principle, every node has a slave mission that serves to receive and ship out facts. The grasp has the additional grasp undertaking, which delegates the sending proper and controls the bus to get admission to (Figure: Master and Slave Task).

**Master Characteristics**
As quickly as a community begins to perform, the master project is started in the grasp. It then begins to periodically method the Schedule that represents the desired sending scheme. In the Schedule, slots are defined for the man or woman messages. These slots must be as a minimum massive enough so that the Frame Header and Frame Response may be sent out (Figure: Frame). A complete body is continually transmittable in a slot.

**Slave Characteristics**
Response behaviors are described for the slave tasks. Exactly how a slave mission must react to a acquired header is described, as an instance. Sending, receiving, or not responding to a response are all possible response behaviours. A sent reaction is in precept to be had for any slave venture to obtain (see figure: Communication Process). The favored response behaviors of the man or woman nodes are defined inside the LDF.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/oriscig6ap89cpc15xgj.png)
Figure: Communication Process Bus control.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zvq7hcon5btroqxvrnar.png)
Figure: Example Communication Process Matrix Table

The master controls statistics communique in a cluster by means of a schedule (ref: matrix table). The agenda depicted right here includes six body slots. An unconditional frame is assigned to every frame. The communique matrix describes the verbal exchange relationships (sender and receiver of the specific frame response).

**Communication Process Bus control**

_Step 1_: The master starts communicative operation at time point t1 by transmitting the frame header with ID = 0X10

_Step 2_: The frame header is evaluated by every slave. A slave reacts either by sending the frame response, receiving the frame response or else it does not react at all.

_Step 3_: Slave B sends the frame response corresponding to the frame header with ID = 0x10 via its slave task.

_Step 4_: Via its slave task, slave A receives the frame response belonging to the frame header with ID = 0x10 The master has no interest in this frame response.

_Step 5_: The master transmits the frame header with ID = 0X12 at time point t2.

_Step 6_: The frame header is evaluated by every slave. A slave reacts either by sending the frame response, receiving the frame response or else it does not react at all.

_Step 7_: Via its slave task, slave A sends the frame response belonging to the frame header with ID = 0X12

_Step 8_: Via its slave task, slave B receives the frame response belonging to the frame header with ID = 0X12 The master has no interest in this frame response.

_Step 9_: The master transmits the frame header with ID = 0X18 at time point t3.

_Step 10_: Repeat the Step 6.

_Step 11_: Via its slave task, slave B sends the frame response belonging to the frame header with ID = 0X18.

_Step 12_: Via its slave task, the master receives the frame response belonging to the frame header with ID = 0X18 Slave A has no interest in this frame response.

_Step 13_: The master transmits the frame header with ID = 0X1C at time point t4.

_Step 14_: Repeat the Step 6.

_Step 15_: Via its slave task, slave A sends the frame response belonging to the frame header with ID = 0X1C.

_Step 16_: Via their slave tasks, the master and slave B receive the frame response belonging to the frame header with ID = 0X1C.

This is Third part of the LIN Protocol next article based on Communcation process of LIN protocol alone with example.

Do let me know if you have any queries in the comments below.

Thanks for reading.