The FlexRay bus communication technology in the wire-controlled steering designed by μC / OS-Ⅱ FlexRaY is a time-triggered communication bus, which requires high real-time performance. Therefore, relying on an embedded program composed of simple loops and interrupt service routines will not meet the requirements. At the same time, during the startup and operation of FlexRay communication, it is necessary to use the loop to query the bus status, which not only wastes a lot of system resources, but also easily causes program deadlock, which becomes a difficult problem in the application. In recent years, with the continuous development of the automotive industry and the electronics industry, automotive steering by-wire technology has become a research hotspot, and many key issues including road simulation, steering stability, and bus technology have been proposed and studied. The bus technology has been actively researched and applied by many well-known automobile companies. Some car manufacturers currently plan to use the FlexRay bus, which is a network communication bus that is particularly suitable for next-generation automotive applications. It has fault tolerance and fixed message transmission time, and can meet the high-speed communication requirements of automotive control systems. Usb To Usb-C Cables,Fast Charging Usb C Data Cable,Customizable Type-C Data Cable,Premium Type-C Data Cable Dongguan Pinji Electronic Technology Limited , https://www.iqdatacable.com
The FlexRay bus communication technology in the wire-controlled steering designed by μC / OS-Ⅱ
Based on the above problems, this paper designs the communication part of the FlexRay bus in the wire steering based on the μC / OS-II real-time operating system. On the basis of meeting the real-time requirements, the use of its multi-tasking feature saves system resources, avoids the occurrence of deadlock problems, and adds communication failure detection and alarm functions, which lays the foundation for the future development of wire-controlled steering systems.
1 FlexRay bus technology
In order to meet the needs of automotive wire control technology, the FlexRay Alliance released the FlexRay bus protocol in 2005. Its main features are: dual-channel transmission, the transmission rate of each channel is up to 10 Mb / s; it has a flexible use mode, supports multiple network topologies; high load rate; and provides a redundancy mechanism.
From the perspective of the open system interconnection reference model, the FlexRay communication protocol defines a four-layer structure: physical layer, transport layer, presentation layer and application layer. The functional description of each layer is shown in Table 1. In the presentation layer, the communication state switching controls the operation process of the entire FlexRay communication, and plays a very important role.
FlexRay protocol operation control (Proposal OperaTIon Control, POC) divides the communication state into several states, namely: configuration state (default configuration, configuration); ready state; wake-up state; startup state; normal state (normally active, normally passive) ; Suspended state. The state transition diagram is shown in Figure 1. When the controller host interface (Controller Host InteRFace, CHI) sends a command to the communication controller (CC), the CC enters the default configuration state from the suspended state, enters the configuration state after the configuration conditions are met, and completes the network initialization and node communication task initialization; You can enter the ready state and complete the internal communication settings of the node. If the communication ready conditions are not met, return to the configuration state to continue the configuration; in the ready state, the CC can send a wake-up frame to wake up the nodes that are not in communication in the network, and can also get the CPU started Communication command, complete synchronization with the FlexRay network clock; enter the normal state after successful startup, complete data transmission and reception; when an error occurs, can enter the suspended state from the normal state, and wait for the CHI command again.
It can be seen that the controller needs to perform corresponding operations in accordance with the POC state, so there will be a loop detection of the POC state, which is easy to cause program deadlock and occupy a lot of system resources. According to the introduction of the operating system, its tasks exist in the form of a loop, so you can put the detected POC status into the task and execute it separately. Task scheduling through the operating system can avoid affecting the operation of programs in other tasks and improve the program Execution efficiency.
2 Based on MC9S12XF512 μC / OS-Ⅱ transplantation
μC / OS-Ⅱ is an operating system with open source code, which has the characteristics of high execution efficiency, small occupied space and excellent real-time performance. Using the task mechanism of the operating system, designing and implementing the Flex-Ray protocol can greatly improve the real-time and stability of the system, and can avoid the deadlock phenomenon when detecting the POC state.
At present, there are few MCUs supporting FlexRay communication on the market, and only Freescale's technology is relatively mature. Considering the cost issue, the 16-bit microcontroller MC9S12XF512 was selected as the system controller chip. The first problem to be solved when using the operating system is the migration problem. According to the file structure of μC / OS-Ⅱ, OS_CPU is needed when transplanting. H, (OS_CPU_A. ASM and OS_CPUC. C three files are modified to suit the needs of the MC9S12xF512 chip.
2.1 Modify OS_CPU. H file
OS_CPU. The H file defines the hardware information related to the CPU, including the storage length corresponding to various data types. For the stack in MC9S12xF512 is from the high address to the low address growth, so the constant OS_STK_GROWTH must be set to 1. At the same time, define the task scheduling function OS_TASK_SW () as the source of the soft interrupt.
2.2 Modify OS_CPU_A. ASM file
OS_CPU_A. The ASM file is to use assembly language to write the code related to the task scheduling part. Including the task-level task switching function OSCtxSw (), the interrupt-level task switching function OSIntCtxSw (), and the function OS-StartHighRdy () that allows the highest priority ready state task to start running.
MC9S12XF512 chip not only has FLASH page management register PPage, but also RAM page management register RPage, E2PROM page management register EPage and global register GPage. When the clock beat interrupt occurs, the chip will automatically push the CPU register onto the stack, but does not include the above registers, so in OS_CPU_A. In the three functions of the ASM file, you need to add statements to push and pop registers. Due to limited space, only take PPage code as an example:
The stacking of registers must follow the order of GPage, EPage, RPage, PPage, and the opposite of stacking.
2.3 Modify OS_CPUC. C file
OS_CPUC. The C file is written in the C language related to the task scheduling part of the code, including the task stack initialization function OSTaskStklnit () and clock beat interrupt service subroutine OSTIcklSR ().
2.3.1 Modify the task stack initialization function 0STaskStkInit ()
Because μC / OS-Ⅱ uses the interrupt mode to implement task scheduling, it is necessary to use the function OSTaskStklnit () to simulate the stack structure after an interrupt occurs, reserve the storage space of each register according to the stacking order after the interrupt, and the interrupt returns The address points to the starting address of the task code. When writing, you need to write the code according to the order of stacking of X, Y, A, B, SP and other registers after the interruption of the chip. First set a breakpoint at the routine OSTaskStkInit () function, and then step through the program, and observe whether the X, Y, A, B, SP and other register states correspond to the stored values ​​written by the program. It is found that the address of the storage area corresponding to the SP value of the stack pointer is the storage address that is pushed into the stack when the interrupt is simulated, and the content of the pointer address of the task program is wrong, that is, it is not the pointer address of the task, so every time the task needs to be called All entered the wrong address to execute, and did not find the task code. By stepping through the OSTaskStkI-nit () function, you can find that the original program only stored the upper 8 bits of the PC pointer when storing the PC value of the task code pointer, but the last 8 bits were not saved, resulting in a pointer pointing error. So modify the program to:
*-wstk = (INTl6U) ((INT32U) task);
2.3.2 Modify the clock beat interrupt service subroutine OSTIckISR ()
The clock tick interrupt service subroutine OSTIckISR () is responsible for handling all timing-related tasks, such as task delays and waiting operations. In the clock interruption, the task in the waiting state will be queried to determine whether the delay is over, otherwise the task scheduling will be restarted. You can call OSIntEnter (). OS_SAVE_SP (), OSTimeTick () and OSIntExit () are implemented. The OSintEnter () function informs μC / OS-Ⅱ to enter the interrupt service subroutine. The OS_SAVE_SP () function is used to save the stack pointer. The OSTimeTick () function decrements the task delay counter for tasks requiring a delay of several clock ticks. When the program is repeatedly run When the counter is 0, it indicates that the task has entered the ready state, and the OSintExit () function marks the end of the clock tick interrupt service subroutine.
The most important point after that is to add the interrupt service subroutine OSTickISR () and the task-level task switching function OSCtxSw () to the corresponding position of the system interrupt vector table. The real-time clock interrupt module (RTI) is used here to generate the clock interrupt, so OSTickISR () should be connected to the vector table RTI position. The OSCtxSw () function uses soft interrupts to implement the task switching function, so the vector address of the soft interrupt service subroutine must point to OSCtxSw ().
After writing the above program, download the code to the hardware, and μC / OS-Ⅱ can be run on this system.
3 Communication programming
Using the task form to solve the POC state detection problem can not only improve the efficiency of the program and avoid the endless loop phenomenon, but also can establish a communication fault detection and alarm task to provide the driver with fault information under different communication states for easy handling.
The steer-by-wire program structure includes four parts: system initialization, communication control, data acquisition and control algorithm. Only the system initialization and communication control part are designed here.
3.1 System initialization
In the main program main (), first initialize the MC9S12XF512 chip, including: clock initialization, I / O port initialization, A / D module initialization, PWM module initialization, and FlexRay protocol configuration initialization. After that, the OSInit () function is called to initialize the μC / OS-Ⅱ operating system. Then create three tasks, according to the priority order 9, 11 and 13, respectively for FlexRay communication start task, data receiving and sending task and fault detection and alarm task. These three tasks realize the communication part function of the wire steering system, and the other parts The function can be expanded by creating other tasks. Finally, OSStart () is called to start the kernel and let the task run under the management and scheduling of the operating system.
3.2 Communication task design
Based on the driver of FlexRay communication transmission layer and presentation layer developed by Freescale, the application layer is designed, that is, the communication task program is written to complete the protocol operation process.
3.2.1 Start task of FlexRay communication
According to the protocol operation process defined in the FlexRay protocol described above, after the initial configuration of FlexRay communication, the protocol will enter the ready state, and then send the start node command to wait for the protocol state to change from the startup state to the normal active state; in the normal active state In the process, first send key frames to start other nodes in the network, and then enter the node wake-up state after sending, and then start various interrupts of FlexRay communication, including: transmission interrupts, receive interrupts, storage area interrupts, and timer interrupts. Start a task and wake up when a communication failure is detected; the normal passive state of the protocol is to reconfigure the protocol and restart the protocol when the communication fails. It should be noted that the user must turn on the clock metronome after the multi-task system is started, that is, after calling Osatart (), the task with the highest task priority starts the RTI interrupt, otherwise the system is prone to deadlock. The program flow chart is shown in Figure 2.
3.2.2 Data receiving and sending tasks
FlexRay data is received and sent through an interrupt service program, so in this task, you only need to determine whether the POC state has entered the normal active state, if it is, then use global variables to receive the Fr_receive_da () and Fr_transmit_data () messages The buffer reads and updates data.
3.2.3 Fault detection task
In the communication process, when other nodes restart due to a fault or the communication line is interrupted, you can use the fault detection task to check the POC status. When the protocol is running in a normal passive state, it is determined that the communication line is faulty, and the fault LED indicator is set Set to the blinking state; when the protocol is running in the suspended state, it is determined that the node controller is faulty, the fault LED indicator is set to a constant light state, and the FlexRay communication startup task is unlinked, and the protocol is reconfigured to wait for the fault Solved, the system can automatically start the node to run. The program flow chart is shown in Figure 3.
4 Experimental verification
Using Vectoroe's CANoe software, you can easily observe the data flow on the FlexRay bus. In the experiment, the FlexRay interface board VN3600 provided by the CANoe software was connected to the bus network, and then the MicroTick of FlexRay communication in the MC9S12XF512 chip manual was defined as 25 ns. Therefore, in the initial definition of FlexRay, set the parameter P_MICRO_PER_M-ACRO_NOM to 40, then one MareroTick is equal to 40 MicroTicks, that is to say, the reference time slice of the FlexRay communication configuration is 1 μs. According to this, the configuration communication period is 5 000 μs; a static time slot length is 24 μs, a total of 91; a dynamic time slot is 5 μs, a total of 289; feature window and network idle time is 1 371 μs.
The time slot definitions for Node_A and Node_B in the program are shown in Table 2.
The experimental results are shown in Figure 4. The running time is 2 289 s, the time slot change and the number of cycles are consistent with the design, and the data transmission and reception are normal. It can be seen from FIG. 5 that the frame rate is 3 200 frames / s, and a total of 7 369 600 frames are transmitted. There are no invalid frames and error frames, which meets the requirements of real-time and stability.
In the communication process, the fault simulation experiments were conducted separately.
(1) Suddenly disconnect the bus to simulate the situation of a line failure at the application site. It can be found that the data stops updating, and the fault detection LED indicator flashes, indicating that the program has detected a line fault and issues an alarm. When the bus is connected again, the fault detection LED goes out and the data continues to be updated, indicating that the communication is automatically restarted.
(2) Power off any one of the controllers to simulate the failure of a single controller. It can be found that the data stops updating, and the fault detection LED indicator starts to illuminate constantly, indicating that the program has detected any node failure and caused communication interruption and alarmed. When the power-off controller is turned on again, the fault detection LED goes out and the data continues to be updated, indicating that the communication is automatically restarted. Through the above two experiments, it is verified that the fault detection alarm function is good.
5 Conclusion
Aiming at the problems in the FlexRay communication process of the wire steering system, the real-time operating system μC / OS-Ⅱ was applied to the system, and the code transplantation and communication task design were carried out. After the hardware experiment, the data results and fault detection were tested. From the experimental results, it can be seen that the system solves the complex problems of the FlexRay bus application, and the μC / OS-Ⅱ operating system is used to ensure the real-time and stability of the system. And the safety requirements have laid the foundation for the future implementation of the steering-by-wire system in automobile assisted driving and intelligent driving.