Application of car window control system based on LIN2.1 protocol

Publisher:心想的45号Latest update time:2013-12-31 Source: elecfans Reading articles on mobile phones Scan QR code
Read articles on your mobile phone anytime, anywhere

  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.

Reference address:Application of car window control system based on LIN2.1 protocol

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

Latest Microcontroller Articles
  • Download from the Internet--ARM Getting Started Notes
    A brief introduction: From today on, the ARM notebook of the rookie is open, and it can be regarded as a place to store these notes. Why publish it? Maybe you are interested in it. In fact, the reason for these notes is ...
  • Learn ARM development(22)
    Turning off and on interrupts Interrupts are an efficient dialogue mechanism, but sometimes you don't want to interrupt the program while it is running. For example, when you are printing something, the program suddenly interrupts and another ...
  • Learn ARM development(21)
    First, declare the task pointer, because it will be used later. Task pointer volatile TASK_TCB* volatile g_pCurrentTask = NULL;volatile TASK_TCB* vol ...
  • Learn ARM development(20)
    With the previous Tick interrupt, the basic task switching conditions are ready. However, this "easterly" is also difficult to understand. Only through continuous practice can we understand it. ...
  • Learn ARM development(19)
    After many days of hard work, I finally got the interrupt working. But in order to allow RTOS to use timer interrupts, what kind of interrupts can be implemented in S3C44B0? There are two methods in S3C44B0. ...
  • Learn ARM development(14)
  • Learn ARM development(15)
  • Learn ARM development(16)
  • Learn ARM development(17)
Change More Related Popular Components

EEWorld
subscription
account

EEWorld
service
account

Automotive
development
circle

About Us Customer Service Contact Information Datasheet Sitemap LatestNews


Room 1530, 15th Floor, Building B, No.18 Zhongguancun Street, Haidian District, Beijing, Postal Code: 100190 China Telephone: 008610 8235 0740

Copyright © 2005-2024 EEWORLD.com.cn, Inc. All rights reserved 京ICP证060456号 京ICP备10001474号-1 电信业务审批[2006]字第258号函 京公网安备 11010802033920号