Multi-processor communication method based on AUTOSAR CP complex drive

Abstract

The invention discloses a multiprocessor communication method based on AUTOSAR CP complex driving, and relates to the technical field of processor communication. The method comprises the step of designing a communication interface, a communication protocol and each layer in the AUTOSAR CP. On the basis of the AUTOSAR CP architecture, the communication interface, the communication protocol, the Appl, the RTE, the BSW and other layers are designed in detail, complex drive control tasks can be processed, efficient communication between different ECUs is ensured, the integration of the whole system and the expansibility of the platform are improved, and the number of the ECUs, the wiring harness cost and the complexity are further reduced.

Description

Technical Field

[0001] The invention belongs to the technical field of processor communication, and in particular relates to a multi-processor communication method based on AUTOSAR CP complex driver. Background Art

[0002] In the past period of time, the distributed architecture of traditional automobiles has dominated; however, with the increase in the number of ECUs (Electronic Control Units) inside the car, the wiring harness has become increasingly complex, and the complexity of the control logic between them has also increased exponentially. To solve the above problems, the development of semiconductors has improved the computing power of a single chip, and the integrated domain control architecture was born. The domain controller adopts an integrated domain control architecture, which can better manage sensors without the need for ECUs to participate in sensor data processing; at the same time, it can also improve the overall integration of the system, further reduce the number of ECUs, and reduce the cost and complexity of the wiring harness; at the same time, the platform scalability of the integrated domain control architecture will be much better than the distributed electronic architecture.

[0003] Domain controllers currently mostly use multi-processor designs to meet different functional requirements. Multi-processor designs use multiple homogeneous / heterogeneous processors, which can not only form a distributed computing hardware architecture, but also use MCUs with functional safety to monitor and detect failures and achieve system-level reset recovery, thereby making the existing platform meet functional safety requirements. Of course, there must be a need for communication between multiple processors. Therefore, how to achieve communication between multiple processors based on the complex driver of AUTOSAR CP (Automotive Open System Architecture Classic Platform) has become an urgent problem to be solved. Summary of the invention

[0004] The object of the present invention is to provide a multi-processor communication method based on AUTOSAR CP complex driver, which can be implemented by the following technical solutions:

[0005] The embodiment of the present application provides a multi-processor communication method based on AUTOSAR CP complex driver, comprising the following steps:

[0006] Design the communication interface;

[0007] Design the communication protocol;

[0008] Designing AUTOSAR CP;

[0009] Among them, the communication interface design includes the communication interface hardware design, specifically:

[0010] An IRQ pin is introduced in SPI communication. When the Slave node transmits data to the Master node, an IRQ signal is generated on the IRQ pin to notify the Master node that the Slave node has data to send.

[0011] Preferably, the communication interface hardware design specifically includes the following contents:

[0012] Sending data: When the Master node sends data to the Slave node, the corresponding Slave node is selected through the CS pin, the CLK pin provides the clock signal for communication, and the MOSI pin is used as the data line for sending data;

[0013] Requesting data: When the Master node requests data from the Slave node, the corresponding Slave node is selected through the CS pin, the CLK pin provides the clock signal for communication, the MOSI pin sends a command to ask the Slave node whether it has data transmission, and the MISO sends a response to the command; if the Slave node has data transmission, the Master node re-initiates the data request operation.

[0014] Preferably, the communication protocol design includes a detailed definition of the communication protocol, specifically including the following:

[0015] Magic ID: length 1, used for starting marker;

[0016] Sequence number: length is 1, used for the cumulative sequence number of the sent frame;

[0017] Reserved: The length is 1, reserved for future use;

[0018] Checksum: length is 1, checksum of data content;

[0019] Data length: length is 1, the data length of the data content;

[0020] Channel number: length is 1, different functional channel labels;

[0021] Data content: The length is 0 to 255, data content payload.

[0022] Preferably, in the design of the communication protocol, the communication channels are divided according to their types, including a communication control channel, a heartbeat monitoring channel, a firmware upgrade channel and an information exchange channel.

[0023] Preferably, the communication control channel includes an IPC control channel; the heartbeat monitoring channel includes a heartbeat monitoring channel; the firmware upgrade channel includes a reserved channel, an upgrade channel, a power management channel and a system channel; the information exchange channel includes a radio channel, a body channel, an instrument channel, a voice control channel, a DSP audio control channel, a physical button channel and a navigation channel.

[0024] Preferably, in the AUTOSAR CP design, the AUTOSAR CP architecture includes an application layer module, a runtime environment module and a basic software module;

[0025] The application layer module includes three software components, namely, an SPI data receiving software component, an SPI data processing software component and an SPI data sending software component;

[0026] The runtime environment module includes three threads, namely a data receiving thread, a data processing thread and a data sending thread;

[0027] The basic software modules include system services and complex drivers;

[0028] Wherein, the system service includes an operating system application; the complex driver includes an extended SPI driver;

[0029] The operating system application includes an interrupt service program, a counter, a scheduling table and tasks; the tasks include a data sending task, a data processing task and a data receiving task;

[0030] The extended SPI driver includes an SPI user protocol, an SPI state management, an SPI driver and an I / O driver.

[0031] Preferably, in the application layer module, the three software components are specifically:

[0032] The SPI data receiving software component is used to receive data from the SPI interface, including protocol parsing, and pass the data to the SPI data processing software component through the runtime environment module;

[0033] The SPI data processing software component is used to process the data transmitted by the SPI data receiving software component, including processing the data and completing necessary tasks, and transmit the processing results to the SPI data sending software component;

[0034] The SPI data sending software component is used to send the processing results through the SPI interface, including parsing the processing results, and sending the corresponding results through the SPI interface according to the protocol requirements;

[0035] Among them, data is transmitted between the three software components through SR-Port.

[0036] Preferably, in the runtime environment module, the three threads are specifically:

[0037] The data receiving thread is used to provide a running entity for data reception;

[0038] The data processing thread is used to provide a running entity for data processing;

[0039] The data sending thread is used to provide a running entity for data sending.

[0040] Preferably, in the system service, the operating system application is a cohesive functional unit consisting of a collection of OS objects;

[0041] The tasks of the operating system application program specifically include:

[0042] The data sending task is used to call the data sending thread to send SPI data;

[0043] The data processing task is used to call the data processing thread to process the SPI data;

[0044] The data receiving task is used to call the data receiving thread to receive SPI data.

[0045] The beneficial effects of the present invention are as follows: based on the AUTOSAR CP architecture, the present invention carries out detailed designs of the communication interface, the communication protocol, and the Appl, RTE, BSW and other layers in the AUTOSAR CP architecture, which is helpful to handle complex drive control tasks and ensure efficient communication and coordination between different ECUs; realizes communication between multiple processors in a domain controller, improves the overall integration of the system and the scalability of the platform, and further reduces the number of ECUs and the cost and complexity of wiring harnesses; thereby, the communication requirements between multiple processors are met while the platform meets the functional safety requirements. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] For better understanding and implementation, the technical solution of the present application is described in detail below with reference to the accompanying drawings.

[0047] Figure 1 A flowchart of a multi-processor communication method based on AUTOSAR CP complex driver provided in an embodiment of the present application;

[0048] Figure 2 A schematic diagram of the design of the communication interface hardware provided in the embodiment of the present application;

[0049] Figure 3A schematic diagram of the architecture of the AUTOSAR CP design provided in the embodiment of the present application;

[0050] Figure 4 A flowchart of the steps of the data receiving thread provided in an embodiment of the present application;

[0051] Figure 5 A flowchart of the steps of the data processing thread provided in the embodiment of the present application;

[0052] Figure 6 A step flow chart of a data sending thread provided in an embodiment of the present application. DETAILED DESCRIPTION

[0053] In order to further explain the technical means and effects taken by the present invention to achieve the predetermined invention purpose, exemplary embodiments will be described in detail here, and examples thereof are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are only examples of methods and systems consistent with some aspects of the present application as detailed in the attached claims.

[0054] The terms used in this application are only for the purpose of describing specific embodiments and are not intended to limit this application. The singular forms of "a", "said" and "the" used in this application and the appended claims are also intended to include plural forms unless the context clearly indicates other meanings. It should also be understood that the term "and / or" used in this article refers to any or all possible combinations of one or more associated listed items.

[0055] The specific implementation methods, features and effects of the present invention are described in detail below in conjunction with the accompanying drawings and preferred embodiments.

[0056] Since the existing architecture of AUTOSAR CP does not include communication between multiple processors, it only includes bus communication (CAN, LIN, ETH, etc.). Among them, CAN (Controller Area Network): used for real-time data transmission, suitable for applications with high reliability and high real-time requirements, such as engine control and body electronics; LIN (Local Interconnect Network): used for low-speed, low-cost communication, often used in non-critical systems in the car, such as window control and seat adjustment; ETH (Ethernet): provides high-bandwidth data transmission and supports more complex applications, such as in-vehicle infotainment systems and advanced driver assistance systems (ADAS). Therefore, to realize multi-processor communication based on the AUTOSAR CP architecture, it is necessary to use complex drivers. This application is described through three aspects: communication interface design, communication protocol design, and AUTOSAR CP design. Among them, the communication interface design only includes the communication interface hardware design plan; the communication protocol design only includes the detailed definition of the communication protocol; the AUTOSAR CP design includes ASW (Application Software Components), CDD (Complex Driver), BSW (Basic Software) and MCAL (Microcontroller Abstraction Layer) related detailed design.

[0057] See also Figure 1 The embodiment of the present application provides a multi-processor communication method based on AUTOSAR CP complex driver, comprising the following steps:

[0058] Design the communication interface;

[0059] Design the communication protocol;

[0060] Designing AUTOSAR CP.

[0061] Specifically, most of the existing domain controllers currently use multi-processor designs to meet different functional requirements. The multi-processor design uses multiple homogeneous / heterogeneous processors, which can not only form a distributed computing hardware architecture; it can also monitor and detect failures and implement system-level reset recovery by using MCUs with functional safety, so that the existing platform meets the functional safety requirements. Of course, there must be a need for communication between multiple processors, so this embodiment proposes a multi-processor communication method based on AUTOSAR CP complex driver, and its implementation covers the Appl, RTE, BSW and other layers of AUTOSAR. Because the existing architecture of AUTOSAR CP does not include communication between multiple processors, but only bus communication (CAN, LIN, ETH, etc.), if multi-processor communication is to be implemented based on the AUTOSAR CP architecture, it must be assisted by complex device drivers.

[0062] Therefore, this embodiment is described through three aspects: communication interface design, communication protocol design, and AUTOSAR CP design. The communication interface design only includes the communication interface hardware design scheme; the communication protocol design only includes the detailed definition of the communication protocol; the AUTOSAR CP design includes the detailed design of ASW (Application Software Components), CDD (Complex Device Driver), BSW (Basic Software), and MCAL (Microcontroller Abstraction Layer).

[0063] In summary, this application carries out detailed design of the communication interface, communication protocol, and Appl, RTE, BSW and other layers in the AUTOSARCP architecture based on the AUTOSARCP architecture, which is helpful to handle complex drive control tasks and ensure efficient communication and coordination between different ECUs; it realizes the communication between multiple processors in the domain controller, improves the overall integration of the system and the scalability of the platform, and further reduces the number of ECUs and the cost and complexity of wiring harnesses; thereby meeting the communication needs between multiple processors and making the platform meet the functional safety requirements.

[0064] In an embodiment provided in the present application, the communication interface design includes the communication interface hardware design, specifically: introducing an IRQ pin in the SPI communication, when the Slave node transmits data to the Master node, an IRQ signal is generated on the IRQ pin to notify the Master node that the Slave node has data to send.

[0065] like Figure 2As shown, in one embodiment provided in the present application, the communication interface hardware design specifically includes the following contents:

[0066] Sending data: When the Master node sends data to the Slave node, the corresponding Slave node is selected through the CS pin, the CLK pin provides the clock signal for communication, and the MOSI pin is used as the data line for sending data;

[0067] Requesting data: When the Master node requests data from the Slave node, the corresponding Slave node is selected through the CS pin, the CLK pin provides the clock signal for communication, the MOSI pin sends a command to ask the Slave node whether it has data transmission, and the MISO sends a response to the command; if the Slave node has data transmission, the Master node re-initiates the data request operation.

[0068] Specifically, in SPI (Serial Peripheral Interface) communication, there are two communication modes for the Master node:

[0069] (1) Sending data

[0070] When the Master node sends data to the Slave node, the corresponding Slave node is selected through the CS pin, the CLK pin provides the clock signal for communication, and the MOSI pin is the data to be sent;

[0071] (2) Request data

[0072] When the Master node requests data from the Slave node, the corresponding Slave node is selected through the CS pin, the CLK pin provides the clock signal for communication, the MOSI pin needs to send a command to ask the Slave node whether it has data to transmit, and the MISO will send a response to the command. If the Slave node has data to transmit, the Master node needs to re-initiate the data request operation.

[0073] Because the data transmission time of the Slave node is not fixed, the Master node needs to periodically initiate queries to ask the Slave node whether it has data to transmit.

[0074] This embodiment introduces an IRQ pin based on conventional SPI communication. When the Slave node needs to transmit data to the Master node, an IRQ signal is generated on the IRQ pin to notify the Master node that the Slave has data to send. This processing method effectively solves the excessive overhead of system resources and bus resources.

[0075] It should be noted that the above-mentioned Master node refers to the master device node in SPI communication; the Slave node refers to the slave device node in SPI communication.

[0076] IRQ (Interrupt Request): This is a signal used to notify the processor or master device that there is an event that needs to be processed. Although IRQ is not a standard signal in SPI communication, in some systems, the SPI peripheral may report data transmission completion or error status to the master device through the IRQ signal.

[0077] CS (Chip Select): This is a control signal used to select a specific slave device. In SPI communication, the master device uses the CS signal to activate or disable the slave device. Usually, the CS signal is a low-level valid signal, that is, when CS is low, the slave device is selected.

[0078] CLK (Clock): This is the clock signal in SPI communication, generated by the master device and used to synchronize data transmission. The frequency of the clock signal determines the speed of data transmission.

[0079] MOSI (Master Out Slave In): This is one of the data lines through which the master sends data to the slave; data flows from the master to the slave, hence the name "Master Out Slave In".

[0080] MISO (Master In Slave Out): This is another data line through which the master receives data sent by the slave. Data flows from the slave to the master, so it is called "Master In Slave Out".

[0081] In an embodiment provided in the present application, the communication protocol design includes a detailed definition of the communication protocol, specifically including the following contents:

[0082] Magic ID: length 1, used for starting marker;

[0083] Sequence number: length is 1, used for the cumulative sequence number of the sent frame;

[0084] Reserved: The length is 1, reserved for future use;

[0085] Checksum: length is 1, checksum of data content;

[0086] Data length: length is 1, the data length of the data content;

[0087] Channel number: length is 1, different functional channel labels;

[0088] Data content: The length is 0 to 255, data content payload.

[0089] In an embodiment provided in the present application, in the design of the communication protocol, the communication channels are divided into types, including a communication control channel, a heartbeat monitoring channel, a firmware upgrade channel and an information exchange channel.

[0090] In an embodiment provided in the present application, the communication control channel includes an IPC control channel; the heartbeat monitoring channel includes a heartbeat monitoring channel; the firmware upgrade channel includes a reserved channel, an upgrade channel, a power management channel and a system channel; the information exchange channel includes a radio channel, a body channel, an instrument channel, a voice control channel, a DSP audio control channel, a physical button channel and a navigation channel.

[0091] like Figure 3 As shown, in one embodiment provided in the present application, in the AUTOSAR CP design, the AUTOSAR CP architecture includes an application layer module, a runtime environment module and a basic software module;

[0092] The application layer module includes three software components, namely, an SPI data receiving software component, an SPI data processing software component and an SPI data sending software component;

[0093] The runtime environment module includes three threads, namely a data receiving thread, a data processing thread and a data sending thread;

[0094] The basic software modules include system services and complex drivers;

[0095] Wherein, the system service includes an operating system application; the complex driver includes an extended SPI driver;

[0096] The operating system application includes an interrupt service program, a counter, a scheduling table and tasks; the tasks include a data sending task, a data processing task and a data receiving task;

[0097] The extended SPI driver includes an SPI user protocol, an SPI state management, an SPI driver and an I / O driver.

[0098] Specifically, the AUTOSAR CP architecture is divided into three parts: Appl (Application Layer), Rte (Runtime Environment) and BSW (Basic Software); among them, the application layer (Appl) contains three SWCs (Software Components), namely SPIData Recv SWC (SPI data receiving software component): processing the logic of receiving data from the SPI slave device; SPIData Handler SWC (SPI data processing software component): processing the received data or preparing the data to be sent; SPIData Send SWC (SPI data sending software component): processing the logic of sending data to the SPI slave device.

[0099] Rte contains three Runables (threads or executable tasks), namely Data Recv Runable (data receiving thread): This is a task responsible for receiving data from the SPI slave device, which usually handles the data receiving logic, data caching and other operations related to data reception; Data Handler Runable (data processing thread): This is a task responsible for processing received data or preparing data to be sent, including data parsing, formatting, verification and other processing steps; Data Send Runable (data sending thread): This is a task responsible for sending data to the master device via SPI, which handles the data sending logic, manages the sending buffer, ensures that the data is transmitted correctly, etc. It should be noted that Runable is an executable task or thread used to perform specific functions or processing. Specifically in conjunction with the SPI communication of this embodiment, the above Runnable is used to implement different SPI data processing functions.

[0100] The basic software includes system services (System Serviers) and complex drivers (ComplexDrivers); among them, System Serviers includes OS-Applications (operating system applications); ComplexDrivers includes Ex-SPI Driver (extended SPI driver), which is an extended or enhanced SPI driver.

[0101] On the other hand, OS-Applications also include ISR (Interrupt Service Routine): a program that handles hardware interrupts and responds to external or internal events; Count: used to track time, number of event occurrences, or other increasing values; Schedule: a table or structure used to define task scheduling strategies; Task: the basic execution unit in the operating system, referring to an independent execution thread or process. A task performs a specific function or operation and is managed by a scheduler.

[0102] Tasks also include Data Send Task: responsible for sending data to an external device or system, usually processing data transmission logic and sending operations; Data Handler Task: responsible for processing received data or data to be sent, including data parsing, format conversion, verification, etc.; Data Recv Task: responsible for receiving data from an external device or system, it processes data receiving logic, including data reading and caching. The above tasks usually run in parallel in the system to achieve efficient data communication and processing.

[0103] Ex-SPIDriver includes SPI User Protocol, which defines the specific rules and formats for data exchange through the SPI interface, including the order and method of data transmission; SPI State Mangagement, which is responsible for tracking and managing the status of the SPI interface, including configuration, communication status, and error handling; SPIDriver, which is responsible for directly interacting with the SPI hardware interface, providing basic SPI communication functions and hardware control; I / ODriver, which handles input and output operations, communicates with device hardware, and manages the reading and writing of data.

[0104] In an embodiment provided by the present application, in the application layer module, the three software components are specifically:

[0105] The SPI data receiving software component is used to receive data from the SPI interface, including protocol parsing, and pass the data to the SPI data processing software component through the runtime environment module;

[0106] The SPI data processing software component is used to process the data transmitted by the SPI data receiving software component, including processing the data and completing necessary tasks, and transmit the processing results to the SPI data sending software component;

[0107] The SPI data sending software component is used to send the processing results through the SPI interface, including parsing the processing results, and sending the corresponding results through the SPI interface according to the protocol requirements;

[0108] Among them, data is transmitted between the three software components through SR-Port.

[0109] Specifically, in the application layer (Appl), SPIData Recv SWC is used to receive data from the SPI interface, including protocol parsing, and then pass the information to SPIData Handler SWC through Rte; SPIData Handler SWC is used to process the information passed by SPIData Recv SWC, including information processing and completing necessary tasks (actions), and then pass the processing results to SPIData Send SWC; SPIData Send SWC is used to send the processing results through the SPI interface, including parsing the processing results, and then sending the corresponding results through the SPI interface according to the protocol requirements; the information transmission between the above different SWCs is to transmit data through SR-Port.

[0110] It should be noted that SR-Port is a term related to a communication interface. Specifically, it usually refers to the abbreviation of Serial Port; a serial port is a communication interface for data transmission between a computer and an external device, and is widely used for serial communication with external devices, such as modems, printers, sensors, etc. Therefore, SR-Port is used to refer to a serial communication interface in this embodiment.

[0111] In an embodiment provided by the present application, in the runtime environment module, the three threads are specifically:

[0112] The data receiving thread is used to provide a running entity for data reception;

[0113] The data processing thread is used to provide a running entity for data processing;

[0114] The data sending thread is used to provide a running entity for data sending.

[0115] Specifically, in Rte, Data Recv Runable is used to provide the running entity (function) for data reception, which is provided by the complex device driver (CDD); Data Handler Runable is used to provide the running entity (function) for data processing, which is provided by the complex device driver (CDD); Data Send Runable is used to provide the running entity (function) for data sending, which is provided by the complex device driver (CDD).

[0116] In one embodiment provided by the present application, in the system service, the operating system application is a cohesive functional unit consisting of a collection of OS objects;

[0117] The tasks of the operating system application program specifically include:

[0118] The data sending task is used to call the data sending thread to send SPI data;

[0119] The data processing task is used to call the data processing thread to process the SPI data;

[0120] The data receiving task is used to call the data receiving thread to receive SPI data.

[0121] Specifically, this embodiment describes System Services in detail:

[0122] OS-Applications are a collection of OS objects (such as Task, ISR, Schedule Table, Count, Alarm), which form a cohesive functional unit; all objects belonging to the same OS-Applications can access each other.

[0123] And about Task:

[0124] Data Send Task, a task for SPI data reception, will call Data SendRunable (data sending thread);

[0125] Data Handler Task (data processing task), used for SPI data processing tasks, will call DataHandler Runable (data processing thread);

[0126] Data Recv Task (data receiving task), a task used for SPI data receiving, will call Data RecvRunable (data receiving thread).

[0127] like Figure 4-Figure 6 As shown, by Task classification, it is divided into Data Recv Task communication flow chart ( Figure 4 )、DataHandler Task communication flow chart( Figure 5 )、Data Send Task communication flow chart ( Figure 6 ), the following describes the three task processes:

[0128] A) Data Recv Task, Data Handler Task, Data Send Task all require hardware and OS support, and require hardware initialization (including IRQ driver and SPI driver) and OS initialization (including OS-Conunt and ISR);

[0129] B) Data Recv Task: When an IRQ interrupt is detected, Data

[0130] Recv Task; Data Recv Task will call Data Recv Runable;

[0131] Data Recv Runable calls SPIData Recv SWC. SPIData Recv

[0132] SWC receives and parses SPI data; when the data is parsed successfully, it is activated

[0133] Data Handler Task;

[0134] C) Data Handler Task: When the Data Handler Task is activated, it will call the Data HandlerRunable; the Data Handler Runable calls the SPI

[0135] Data Handler SWC. SPIData Handler SWC processes SPI data and performs certain actions based on the processing results; at the same time, according to the results of the actions, it prepares the SPI data response; and then activates the Data SendTask;

[0136] D) Data Send Task: When the Data Send Task is activated, it will call

[0137] Data Send Runable: Data Send Runable calls SPIData Send SWC. It parses the SPI data response of SPISend Handler SWC, encapsulates SPI user protocol data, and then sends it out through SPI.

[0138] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0139] The above description is only a preferred embodiment of the present invention and does not limit the present invention in any form. Although the present invention has been disclosed as a preferred embodiment as above, it is not used to limit the present invention. Any technical personnel in this field can make some changes or modify the technical contents disclosed above into equivalent embodiments without departing from the scope of the technical solution of the present invention. However, any simple modification, equivalent change and modification made to the above embodiments according to the technical essence of the present invention without departing from the content of the technical solution of the present invention still fall within the scope of the technical solution of the present invention.

Claims

1. A multi-processor communication method based on AUTOSAR CP complex driver, characterized by: The steps include: Design the communication interface; Design the communication protocol; Designing AUTOSAR CP; Among them, the communication interface design includes the communication interface hardware design, specifically: An IRQ pin is introduced in SPI communication. When the Slave node transmits data to the Master node, an IRQ signal is generated on the IRQ pin to notify the Master node that the Slave node has data to send.

2. The multi-processor communication method based on AUTOSAR CP complex driver according to claim 1, characterized in that: The communication interface hardware design specifically includes the following contents: Sending data: When the Master node sends data to the Slave node, the corresponding Slave node is selected through the CS pin, the CLK pin provides the clock signal for communication, and the MOSI pin is used as the data line for sending data; Requesting data: When the Master node requests data from the Slave node, the corresponding Slave node is selected through the CS pin, the CLK pin provides the clock signal for communication, the MOSI pin sends a command to ask the Slave node whether it has data transmission, and the MISO sends a response to the command; if the Slave node has data transmission, the Master node re-initiates the data request operation.

3. The multi-processor communication method based on AUTOSAR CP complex driver according to claim 1, characterized in that: Communication protocol design includes a detailed definition of the communication protocol, including the following: Magic ID: length 1, used for starting marker; Sequence number: length is 1, used for the cumulative sequence number of the sent frame; Reserved: The length is 1, reserved for future use; Checksum: length is 1, checksum of data content; Data length: The length is 1, which is the data length of the data content; Channel number: length is 1, different functional channel labels; Data content: The length is 0 to 255, data content payload.

4. The multi-processor communication method based on AUTOSAR CP complex driver according to claim 1, characterized in that: In the design of communication protocols, they are divided according to the types of communication channels, including communication control channels, heartbeat monitoring channels, firmware upgrade channels and information exchange channels.

5. The multi-processor communication method based on AUTOSAR CP complex driver according to claim 4, characterized in that: The communication control channel includes an IPC control channel; the heartbeat monitoring channel includes a heartbeat monitoring channel; the firmware upgrade channel includes a retention channel, an upgrade channel, a power management channel and a system channel; the information exchange channel includes a radio channel, a body channel, an instrument channel, a voice control channel, a DSP audio control channel, a physical button channel and a navigation channel.

6. The multi-processor communication method based on AUTOSAR CP complex driver according to claim 1, characterized in that: In AUTOSAR CP design, the AUTOSAR CP architecture includes application layer modules, runtime environment modules, and basic software modules; The application layer module includes three software components, namely, an SPI data receiving software component, an SPI data processing software component and an SPI data sending software component; The runtime environment module includes three threads, namely a data receiving thread, a data processing thread and a data sending thread; The basic software modules include system services and complex drivers; Wherein, the system service includes an operating system application; the complex driver includes an extended SPI driver; The operating system application includes an interrupt service program, a counter, a scheduling table and tasks; the tasks include a data sending task, a data processing task and a data receiving task; The extended SPI driver includes an SPI user protocol, an SPI state management, an SPI driver and an I / O driver.

7. The multi-processor communication method based on AUTOSAR CP complex driver according to claim 6, characterized in that: In the application layer module, the three software components are specifically: The SPI data receiving software component is used to receive data from the SPI interface, including protocol parsing, and pass the data to the SPI data processing software component through the runtime environment module; The SPI data processing software component is used to process the data transmitted by the SPI data receiving software component, including processing the data and completing necessary tasks, and transmit the processing results to the SPI data sending software component; The SPI data sending software component is used to send the processing results through the SPI interface, including parsing the processing results, and sending the corresponding results through the SPI interface according to the protocol requirements; Among them, data is transmitted between the three software components through SR-Port.

8. The multi-processor communication method based on AUTOSAR CP complex driver according to claim 6, characterized in that: In the runtime environment module, the three threads are specifically: The data receiving thread is used to provide a running entity for data reception; The data processing thread is used to provide a running entity for data processing; The data sending thread is used to provide a running entity for data sending.

9. The multi-processor communication method based on AUTOSAR CP complex driver according to claim 6, characterized in that: In the system services, an operating system application is a cohesive functional unit consisting of a collection of OS objects; The tasks of the operating system application program specifically include: The data sending task is used to call the data sending thread to send SPI data; The data processing task is used to call the data processing thread to process the SPI data; The data receiving task is used to call the data receiving thread to receive SPI data.

Images