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. This is part 3 of the LIN protocol. Here we will discuss the communication process in detail.
LIN Communication Process
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).
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.
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.
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).
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.
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.
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.