SLLA383A February   2018  – August 2022 SN65HVDA100-Q1 , SN65HVDA195-Q1 , TLIN1022-Q1 , TLIN1029-Q1 , TLIN2022-Q1 , TLIN2029-Q1 , TMS320F28P550SJ , TMS320F28P559SJ-Q1

 

  1.   Abstract
  2.   Trademarks
  3. 1Introduction
    1. 1.1 LIN Specification Progression
    2. 1.2 Workflow Concept
  4. 2Network Architecture
    1. 2.1 General Layout of the LIN Bus
    2. 2.2 Serial Communication Principles
    3. 2.3 Commander-Responder Principle
    4. 2.4 Message Frame Format
  5. 3Physical Layer Requirements
    1. 3.1 Bus Signaling Fundamentals
    2. 3.2 Pullup Values
    3. 3.3 Threshold Values
    4. 3.4 Bit-Rate Tolerance and Timing Requirements
    5. 3.5 Synchronization and Bit Sampling
    6. 3.6 Duty Cycle
  6. 4Filtering, Distance Limitations, Nodes on Bus
    1. 4.1 EMI and Signal Conditioning
    2. 4.2 ESD and Transients
    3. 4.3 Distance and Node Limitations
  7. 5LIN Transceiver Special Functions
    1. 5.1 Low-Power Modes
      1. 5.1.1 Sleep Mode
      2. 5.1.2 Standby Mode
    2. 5.2 Wakeup
      1. 5.2.1 Pin Wakeup
      2. 5.2.2 LIN Wakeup
      3. 5.2.3 Dominant Timeout
  8. 6Advantages and Disadvantages
  9. 7Conclusion
  10. 8Revision History

2.3 Commander-Responder Principle

In every cluster, there is one commander node and up to 16 responder nodes. The commander node controls all communication on the bus and contains both the commander and responder task to be delivered. The responder nodes cannot communicate with each other, contain only the responder task, and are only capable of responding to the commander if the message is directed at them. The commander sends out a request to a designated responder as a header (beginning of the frame), and the responder responds to the commander, as a response frame. There is also a case where the commander sends the responder the header and response frame, and the responder only listens but with no response. Both situations guarantee predictable yet defined bus traffic, disallowing collisions for the most part because the commander is always initiating the communication. This predictable nature allows for scheduling of messages.

If the developer of the LIN cluster does a proper job planning messages and calculating their lengths, a schedule can be developed and no collisions will occur. A schedule is the organization of messages frames into slots, and is what sets the send time of all the messages to be sent at any given time. The tokens (also referred to as requests) are sent by the commander at these given times set by the schedule. These tokens are sent to responders, and the responder can either ignore, respond, or just receive the data. The token and the data (header and response) are what make up the LIN messages, and up to 64 messages can be defined per cluster.

The problem with the commander-responder system is that the commander controls all communication, and if the commander fails the whole cluster fails. In schemes where all nodes can act as a commander and responder, this does not happen and this quality is ultimately what keeps LIN from being used in safety-related applications (that, and the slow message rate). The LIN cluster is also not inherently capable of event-driven communication, because the LIN responders can only communicate with the bus if they are requested to do so.