The LIN Association released the first version of the LIN protocol in 1999, and it has been more than ten years since then. During these ten years, the LIN bus has continued to develop and has been used in many occasions mainly for body control. There are a total of 7 versions of the LIN bus so far, among which the LIN2.1 protocol was released in November 2006 and is currently the newest version. It is almost the same as the latest LIN2.2 protocol, but it has obvious improvements over its predecessor LIN2.0 protocol, mainly reflected in the addition of event-triggered frame competition processing, the improvement of node configuration functions, and the diagnosis classification. These improvements enable users to organize LIN networks more conveniently and quickly, and can reset LIN networks according to their own needs, which not only ensures the stability of the product, but also meets the personalized needs of users. It is a very meaningful step in the development of the LIN bus itself.
1 New features of LIN2.1 protocol
1.1 Competition handling of event-triggered frames
If more than one slave node responds to the frame header in the same frame time slot, it will cause competition, and the competition processing is completed by the master node. The event-triggered frame competition processing mechanism of LIN2.0 is shown in Figure 1. The schedule of a master node contains unconditional frame A, event-triggered frame and unconditional frame B. When competition occurs, the master node will continue to follow the previous schedule and send the event-triggered frame header after receiving all unconditional frames related to the event-triggered frame. LIN2.1 has made improvements to this. It introduces a competition processing schedule. The event-triggered frame competition processing mechanism of LIN2.1 is shown in Figure 2. Each event-triggered frame has a corresponding competition processing schedule. After the master node handles the competition in the competition processing schedule, it returns to execute the normal schedule. Obviously, the competition processing mechanism of LIN2.1 takes a shorter time.
Figure 1 LIN2.0 event-triggered frame contention processing mechanismFigure 2 LIN2.1 event-triggered frame contention processing mechanism
1.2 Improvement of node configuration function
1.2.1 Added the ability to assign a series of frame IDs
The configuration function assigns frame IDs to a series of frame IDs. The format of assigning frame IDs in LIN2.0 and LIN2.1 protocols is shown in Figure 3. In LIN2.0, the assignment is successful only when both NAD and Supplier ID match, but only one frame ID can be assigned at a time. In LIN2.1, only NAD matching is required, and up to 4 frame IDs can be assigned at a time, while the Message ID in LIN2.0 has been cancelled in LIN2.1. The purpose of this improvement is to improve the efficiency of LIN network configuration. After the change, the speed of assigning frame IDs can be up to 4 times faster than before.
Figure 3 Format of frame ID assignment in LIN2.0 and LIN2.1 protocols
1.2.2 Added the function of saving configuration
The LIN2.1 protocol adds a function to save the configuration information of slave nodes, which stores the configuration information of slave nodes in a non-volatile storage space. In this way, the configuration of the slave nodes by the master node will not be lost after reset.
1.3 Diagnostic classification
Another major new feature of LIN2.1 is that slave nodes are divided into three levels according to diagnostic functions.
(1) Diagnosis level 1
Diagnostic level 1 is generally used for devices such as smart sensors or actuators that do not require or require very little diagnostic functionality. Diagnostic level 1 supports all node configuration functions and only requires a single frame transmission.
(2) Diagnosis Level 2
Compared with the first level of diagnosis, the nodes of the second level of diagnosis have the function of node identification. For example, users can obtain the software and hardware version numbers of the product. In addition, the second level of diagnosis also supports reading and writing parameters inside the software, such as temperature, vehicle speed, etc. The second level of diagnosis supports multi-frame transmission.
(3) Diagnosis level 3
The nodes of the third level of diagnosis not only include all the functions of the first two levels, but also support the erasing and writing of the internal Flash. Users can burn programs through the LIN bus. The third level of diagnosis supports multi-frame transmission.
2 Node configuration function of LIN2.1 protocol
(1) Allocation of NAD
To avoid a NAD being reused, the user may need to allocate a new NAD to the slave node.
(2) Conditional allocation of NAD
When a user replaces or adds a slave node, two situations may occur:
① One is that the user does not know the initial NAD of the newly added slave node, so it is necessary to find all slave nodes in a "broadcast" manner and assign a valid NAD ("broadcast" means sending a request to all slave nodes in the network, which has a dedicated NAD of 0x7F). However, if this is done directly, all slave nodes will obtain the same NAD, which is obviously not allowed. To avoid this situation, restrictions can be added.
② Another situation is that the user knows the initial NAD of the newly added node, but it overlaps with the NAD of the existing slave node in the LIN network. If the user only assigns a new NAD according to the original NAD, the NAD of both slave nodes will be modified. Therefore, a restriction must be added.
When a slave node receives a request for conditional allocation of NAD, it will determine whether to modify the NAD according to the following steps:
① Read the relevant information of the slave node according to the ID.
② Extract an 8-bit data from the related information according to Byte. For example, if Byte=1, extract D1.
③ Perform XOR operation with Invert.
④ Perform AND operation with Mask.
⑤ If the result is 0, modify NAD.
For example: this product is added to a LIN network, and the initial NAD is 0x06, but there is already a slave node with NAD 0x06 in the network. Therefore, the user can use the Function ID of this product, assuming it is 0x0000, to assign a new NAD of 0x08. Here, it is assumed that the Function ID of the existing slave node is not 0x0000. In this way, only the NAD of the newly added node will be modified, while the NAD of the existing slave node will remain unchanged at 0x06.
(3) Save the configuration
Saving configuration is a new function added to LIN2.1, which is used to store the current configuration of the slave node into non-volatile storage space. The configuration data can be read out at the next power-on. Here, NAD and frame ID are mainly saved.
(4) Assign a series of frame IDs
This function can configure up to 4 frame IDs. Note that the diagnostic frame ID and reserved frame ID cannot be configured.
The request frame of the master node gives the sequence number of the first frame in the frame array that needs to be assigned a frame ID in D1. Generally speaking, the IDs of all frames used by the slave node will be arranged into a frame array. If a frame ID is to be assigned, a new frame ID is given through D2 to D5; if a frame is to be disabled, the PID corresponding to this frame is set to 0x00; if the current frame ID is to be continued, the PID corresponding to this frame is set to 0xFF.
(5) Read slave node information
Reading node information Depending on the value of ID in D1, different slave node information can be read. Currently, only the cases of ID 0 and ID 1 are specified, and the others can be reserved or determined by the user.
3 Implementation of LIN Communication
3.1 LIN module of TLE9832
TLE9832 is an 8-bit power-level microcontroller produced by Infineon Technologies, which is specially used for car window control. The LIN bus module supports LIN2.1 and LIN2.0, and is backward compatible with LIN1.3. The module can work in normal mode, receiving mode and prohibition mode. The characteristics of each mode are listed in Table 1.
Table 1 Features of each mode of the TLE9832 LIN module
Among them, the normal mode can be divided into low-speed mode, medium-speed mode, high-speed mode and Flash mode according to the size of the transmission rate. The maximum transmission rate of the low-speed mode is 10.4 kbps; the medium-speed mode is a common LIN transmission mode with a maximum transmission rate of 20 kbps; the maximum transmission rate of the high-speed mode is 40 kbps; the maximum transmission rate of the Flash mode is 115 kbps. In order to avoid interrupting the transmission process, changing the transmission rate is prohibited in the normal mode. The correct approach is to first prohibit the sending function, then change the transmission rate, and finally allow the sending function.
The LIN module also has an automatic power saving mechanism in normal mode. When there is no data in the transmission queue, the transmission function will be automatically disabled; when there is a transmission request, the transmission function will be automatically enabled.
3.2 Window Anti-pinch Control System Based on TLE9832
The anti-pinch window control system based on TLE9832 is the latest research result of Infineon Tongji Microcontroller and Embedded System Laboratory. Users can control the rise and fall of the window through buttons or LIN bus. The schematic diagram of the anti-pinch window system based on TLE9832 is shown in Figure 4. The speed of the motor can be controlled by controlling the PWM signal, and the Hall sensor TLE4966 will collect the speed of the motor and transmit it to TLE9832, thus forming a closed-loop control. In addition, the armature current of the motor is converted into a voltage signal and transmitted to the ADC module of TLE9832. If the window encounters abnormal resistance during the rise process, the armature current and motor speed will change abnormally. TLE9832 can judge whether to execute the anti-pinch algorithm based on this change to avoid hurting passengers. [page]
Figure 4 Schematic diagram of the anti-pinch window system based on TLE9832
3.3 Software Design of LIN Communication Part
The program flow of the LIN communication part is shown in Figure 5. The program of the LIN communication part in the window controller can be divided into two parts:
Figure 5 LIN communication part of the program flow
① The first part is initialization. After each power-on, the program will first read the data in the Flash. If the data in 0x8000 is 0x78, it is determined that the product has executed the function of saving the configuration after leaving the factory. Therefore, the program will read the NAD and frame ID stored in the Flash as the current NAD and frame ID. Next is to initialize the LIN module, including setting the timer and UART and other peripherals related to LIN communication, setting various parameters of the slave node, baud rate, etc.
② The second part is placed in the timer interrupt, and node configuration, data sending and receiving are performed at each interrupt. First, it is determined whether there is a node configuration task based on the frame ID. If there is, various node configuration tasks are performed according to the SID; then the automatic raising and lowering of the window is controlled according to the content of the received data frame; finally, the window information, including armature current, window position, etc., is sent to the master node.
4 LIN communication test results
This test was completed with the help of Leaf Professional LIN, a LIN communication test tool produced by Kvaser, and its supporting software CANLab. During the test, the test tool was set as the master node, the TLE9832 microcontroller was set as the slave node, and the bit rate was set to 19 200 bps. The initial NAD was set to 0x06, the initial frame ID was the unconditional frame 0x00, 0x01 and the diagnostic configuration frame 0x3C, 0x3D, and the SupplierID and Function ID were both 0x0000.
First, test each function of the node configuration: first test the NAD allocation function, modify NAD to 0x03; then test the conditional NAD allocation function, modify NAD to 0x08; then test the allocation of a series of frame IDs function, and save the settings; finally, power on again and read the slave node information. The test results of the node configuration function are shown in Figure 6.
Figure 6 Test results of node configuration function
Then the car window is controlled to automatically rise and fall through the LIN bus. The test results are shown in Figure 7.
Figure 7 Test results of the automatic window up and down function
Finally, the data of the armature current during the window raising process is obtained through the LIN bus and converted into a graph, as shown in Figure 8. The current value is the result after A/D conversion.
Figure 8 Armature current value during window raising
Conclusion
This paper designs a communication module in the anti-pinch window control system based on the LIN2.1 protocol. It can be seen that this module can well meet the needs of users in terms of data transmission and diagnosis. The development of the LIN bus itself will surely promote further development in the field of body control.
Previous article:Implementation of Flexray Steer-by-Wire System Based on μC/OS-Ⅱ
Next article:Automobile ASR system ECU development and hardware-in-the-loop testing
Professor at Beihang University, dedicated to promoting microcontrollers and embedded systems for over 20 years.
- Innolux's intelligent steer-by-wire solution makes cars smarter and safer
- 8051 MCU - Parity Check
- How to efficiently balance the sensitivity of tactile sensing interfaces
- What should I do if the servo motor shakes? What causes the servo motor to shake quickly?
- 【Brushless Motor】Analysis of three-phase BLDC motor and sharing of two popular development boards
- Midea Industrial Technology's subsidiaries Clou Electronics and Hekang New Energy jointly appeared at the Munich Battery Energy Storage Exhibition and Solar Energy Exhibition
- Guoxin Sichen | Application of ferroelectric memory PB85RS2MC in power battery management, with a capacity of 2M
- Analysis of common faults of frequency converter
- In a head-on competition with Qualcomm, what kind of cockpit products has Intel come up with?
- Dalian Rongke's all-vanadium liquid flow battery energy storage equipment industrialization project has entered the sprint stage before production
- Allegro MicroSystems Introduces Advanced Magnetic and Inductive Position Sensing Solutions at Electronica 2024
- Car key in the left hand, liveness detection radar in the right hand, UWB is imperative for cars!
- After a decade of rapid development, domestic CIS has entered the market
- Aegis Dagger Battery + Thor EM-i Super Hybrid, Geely New Energy has thrown out two "king bombs"
- A brief discussion on functional safety - fault, error, and failure
- In the smart car 2.0 cycle, these core industry chains are facing major opportunities!
- Rambus Launches Industry's First HBM 4 Controller IP: What Are the Technical Details Behind It?
- The United States and Japan are developing new batteries. CATL faces challenges? How should China's new energy battery industry respond?
- Murata launches high-precision 6-axis inertial sensor for automobiles
- Ford patents pre-charge alarm to help save costs and respond to emergencies
- 2021 ON Semiconductor Avnet RSL10 Bluetooth SoC Development and Design Competition Third Post (Revised Routine)
- Frequency Converter Application in Baosteel
- Today at 10:00 AM, live broadcast with prizes: ams projection lighting (MLA) enhances communication between cars and roads
- MSP430F5529 clock multiplier setting is effective
- [RVB2601 Creative Application Development] + Unboxing
- MSP430F5538A watchdog
- I also shared the books I bought with E coins.
- [Qinheng Trial] 1. CH549EVT Product Display
- Linear relationship, linear region
- What are the necessary instructions for SIM800C transparent transmission mode?