A method for implementing DDS multi-core deployment on AutoSar CP platform

Abstract

The present invention discloses a method for implementing DDS multi-core deployment on an AutoSar CP platform, wherein a TCPIP protocol stack is deployed on a first core, and a DDS protocol stack including user interface calls is deployed on a second core; the TCPIP protocol stack on the first core writes data into an inter-core shared queue through an interruption, and notifies a DDS task on the second core through a SetEvent mechanism; after being activated by an event Event, the DDS task takes data from the inter-core shared queue and processes it in real time, and the user task calls a dds_take interface to receive data; the dds_write interface automatically determines whether the current calling core is consistent with the core where the TCPIP is located, and if consistent, directly sends data, and if inconsistent, writes the data into the inter-core shared queue. The multi-core deployment of the present invention reduces the CPU occupancy rate of the TCPIP core, and at the same time utilizes the processing power of other cores, thereby supporting the deployment of more services, greatly improving the flexibility of service deployment and service carrying capacity.

Description

Technical Field

[0001] The present invention relates to DDS communication technology, and in particular to a method for implementing DDS multi-core deployment on an AutoSar CP platform. Background Art

[0002] The current deployment method of DDS on MCU controllers based on the AutoSar CP platform is generally to share a CPU core with the TCPIP protocol stack. Due to the constraints of the CP platform, the message sending function can only be called on the TCPIP core, so DDS is generally deployed on the same core as the TCPIP protocol stack on the MCU. However, for multi-core MCUs, if DDS can only run on a single core, the advantages of multi-cores will not be brought into play, and the computing power and memory resources of idle cores will be wasted; at the same time, the use of DDS by businesses will also be limited to a single core, and the business data of other cores must be transmitted through the shared memory between cores in order to send and receive DDS data, and business deployment is not flexible enough. Summary of the invention

[0003] To solve the deficiencies in the prior art, the present invention aims to provide a method for implementing DDS multi-core deployment on the AutoSar CP platform.

[0004] To achieve the purpose of the present invention, the technical solution adopted by the present invention is:

[0005] A method for implementing DDS multi-core deployment on an AutoSar CP platform comprises the following steps:

[0006] (1) The TCPIP protocol stack is deployed on the first core Core0, and the DDS protocol stack including user interface calls is deployed on the second core Core1;

[0007] (2) The TCPIP protocol stack on the first core Core0 writes the data into the inter-core shared queue through an interrupt, and notifies the DDS task on the second core Core1 through the SetEvent mechanism of the CP;

[0008] (3) After the DDS task is activated by the event Event, it takes data from the inter-core shared queue and processes it in real time. The user task calls the dds_take interface to receive data;

[0009] (4) The dds_write interface automatically determines whether the current calling core is consistent with the core where TCPIP is located. If they are consistent, the data is sent directly. If they are inconsistent, the data is written into the shared queue between cores.

[0010] Furthermore, in step (1), the TCPIP protocol stack is deployed on the first core Core0, which is responsible for receiving and sending network data, and the DDS protocol stack runs on the second core Core1, which is responsible for sending and receiving user data.

[0011] Furthermore, in step (2), the DDS task on the second core Core1 is an extended task. After the TCPIP protocol stack on the first core Core0 receives the network data, it calls the SetEvent mechanism to activate the DDS task of the second core Core1. The DDStask performs message parsing and submits the data to the user cache.

[0012] Furthermore, in step (4), the user calls the CP interface GetCoreID to obtain the serial number of the current core Core1. If it is inconsistent with the core Core0 where TCPIP is located, the data is sent to Core0 in the form of a queue. The task on Core0 takes the data out of the queue and performs the actual Udp_Transmit transmission.

[0013] Furthermore, in the method, when a user transceiver interface accesses the protocol stack rhc, whc, memory pool data, and a resource conflict occurs with data processing in DDS_main_func on another core, a CP inter-core spin lock is added to protect the critical section.

[0014] Furthermore, spin locks include memory pool locks, timed event locks, participant locks, writer locks, and reader locks.

[0015] Furthermore, the memory pool lock is used for the application and release of the protocol stack memory pool, the timer event lock is used for the creation and execution of the timer, the participant lock is used for the participant lock to manage the creation and deletion of all other entities, the writer lock is used for the lock between the user writing data and the whc, and the reader lock is used for the lock between the user reading data and the rhc.

[0016] The beneficial effect of the present invention is that, compared with the prior art, DDS supports multi-core deployment on the AUTOSAR CP platform, which will effectively utilize the resource advantages of some multi-core MCU chips and greatly improve the utilization of multi-core chip computing power, memory and other resources. After DDS supports multi-core deployment, it will reduce the CPU occupancy rate of the TCPIP core, while utilizing the processing power of other cores, thereby supporting the deployment of more services on the MCU, greatly improving the flexibility of service deployment and the service carrying capacity on the MCU. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 It is a schematic diagram of a method for implementing DDS multi-core deployment on the AutoSar CP platform according to the present invention;

[0018] Figure 2 This is a schematic diagram of multi-core deployment of DDS user interface through CP inter-core spin lock. DETAILED DESCRIPTION

[0019] The technical solution of the present invention is further described below in conjunction with the accompanying drawings and embodiments. The following embodiments are only used to more clearly illustrate the technical solution of the present invention, and cannot be used to limit the protection scope of this application.

[0020] The present invention realizes multi-core deployment of DDS by increasing inter-core shared queue transmission and protecting critical areas through CP spinlocks.

[0021] like Figure 1 As shown, the method for implementing DDS multi-core deployment on the AutoSar CP platform of the present invention comprises the steps of:

[0022] (1) The TCPIP protocol stack is deployed on the first core Core0, and the DDS protocol stack including user interface calls is deployed on the second core Core1;

[0023] For multi-core chips, the TCPIP protocol stack can be deployed on the first core Core0, which is responsible for receiving and sending network data. The tasks of other cores cannot directly call the TCPIP interface. The DDS protocol stack runs on the second core Core1, which is responsible for sending and receiving user data.

[0024] (2) The TCPIP protocol stack on the first core Core0 writes the data into the inter-core shared queue through an interrupt, and notifies the DDS task on the second core Core1 through the SetEvent mechanism of the CP;

[0025] The DDS task on the second core Core1 is an extended task and is in the wait state by default. After the TCPIP protocol stack on the first core Core0 receives network data, it calls the SetEvent mechanism to activate the DDS task of Core1. The DDS task immediately parses the message and submits the data to the user cache.

[0026] (3) After the DDS task is activated by the event Event, it immediately takes data from the inter-core shared queue and processes the data in real time. The user task calls the dds_take interface to receive data;

[0027] DDS task can quickly process the network data received by Core0 through the Event mechanism, which effectively reduces the latency compared to the processing of periodic tasks. Periodic tasks are generally fixed periods of 10ms or 5ms, and data processing naturally has a millisecond latency. Using event activation to extend the task can reduce the latency to hundreds of microseconds.

[0028] (4) The dds_write interface automatically determines whether the current calling core is consistent with the core where TCPIP is located. If they are consistent, the data is sent directly. If they are inconsistent, it means that cross-core is required and the data is written into the shared queue between cores;

[0029] The user calls the CP interface GetCoreID to obtain the serial number of the current core Core1. If it is inconsistent with the core Core0 where TCPIP is located, the data needs to be sent to Core0 in the form of a queue. The task on Core0 takes the data out of the queue and performs the actual Udp_Transmit sending.

[0030] Udp_Transmit is the UDP message sending interface at the bottom layer of CP, which sends DDS data to the network.

[0031] The dds_take interface is used for data reception, and the dds_write interface is used for data transmission.

[0032] like Figure 2 As shown in the figure, by adding CP inter-core spin locks to protect the critical section, multi-core deployment of DDS user interfaces (dds_take, dds_write, etc.) is achieved.

[0033] In AUTOSAR CP, the CP inter-core spinlock is usually used in multi-core processors or multi-tasking environments to prevent data inconsistency or conflict caused by concurrent access of multiple tasks or processor cores to shared resources. Its basic principle is: when a task or processor core wants to access a shared resource, it will continue to spin (that is, busy waiting) until the resource is available. It does not give the CPU time slice to other tasks, but keeps busy waiting until it obtains the permission to lock the resource. Spinlock is usually more efficient than traditional blocking-based lock mechanisms (such as semaphores and mutexes) because it avoids the overhead of context switching.

[0034] The user transceiver interface (dds_take, dds_write) will access data such as protocol stack rhc, whc, memory pool, etc., which will cause resource conflicts with the data processing in DDS_main_func on another core. Therefore, it is necessary to add locks in the processing flow to protect shared data and ensure that only one core task can access shared resources at a time. The number and description of locks are shown in Table 1.

[0035] Table 1

[0036]

[0037] The beneficial effect of the present invention is that, compared with the prior art, DDS supports multi-core deployment on the AUTOSAR CP platform, which will effectively utilize the resource advantages of some multi-core MCU chips and greatly improve the utilization of multi-core chip computing power, memory and other resources. After DDS supports multi-core deployment, it will reduce the CPU occupancy rate of the TCPIP core, while utilizing the processing power of other cores, thereby supporting the deployment of more services on the MCU, greatly improving the flexibility of service deployment and the service carrying capacity on the MCU.

[0038] The applicant of the present invention has made a detailed explanation and description of the implementation examples of the present invention in conjunction with the drawings in the specification. However, those skilled in the art should understand that the above implementation examples are only preferred implementation schemes of the present invention, and the detailed description is only to help readers better understand the spirit of the present invention, but not to limit the scope of protection of the present invention. On the contrary, any improvements or modifications based on the inventive spirit of the present invention should fall within the scope of protection of the present invention.

Claims

1. A method for implementing DDS multi-core deployment on the AutoSar CP platform, characterized in that: Includes steps: (1) The TCPIP protocol stack is deployed on the first core Core0, and the DDS protocol stack including user interface calls is deployed on the second core Core1; (2) The TCPIP protocol stack on the first core Core0 writes the data into the inter-core shared queue through an interrupt, and notifies the DDS task on the second core Core1 through the SetEvent mechanism of the CP; (3) After the DDS task is activated by the event Event, it takes data from the inter-core shared queue and processes it in real time. The user task calls the dds_take interface to receive data; (4) The dds_write interface automatically determines whether the current calling core is consistent with the core where TCPIP is located. If they are consistent, the data is sent directly. If they are inconsistent, the data is written into the shared queue between cores.

2. The method for implementing DDS multi-core deployment on the AutoSar CP platform according to claim 1, characterized in that: In step (1), the TCPIP protocol stack is deployed on the first core Core0, which is responsible for receiving and sending network data. The DDS protocol stack runs on the second core Core1, which is responsible for sending and receiving user data.

3. The method for implementing DDS multi-core deployment on the AutoSar CP platform according to claim 1, characterized in that: In step (2), the DDS task on the second core Core1 is an extended task. After the TCPIP protocol stack on the first core Core0 receives the network data, it calls the SetEvent mechanism to activate the DDS task of the second core Core1. The DDS task performs message parsing and submits the data to the user cache.

4. The method for implementing DDS multi-core deployment on the AutoSar CP platform according to claim 1, characterized in that: In step (4), the user calls the CP interface GetCoreID to obtain the serial number of the current core Core1. If it is inconsistent with the core Core0 where TCPIP is located, the data is sent to Core0 in the form of a queue. The task on Core0 takes the data out of the queue and performs the actual Udp_Transmit transmission.

5. The method for implementing DDS multi-core deployment on the AutoSar CP platform according to claim 1, characterized in that: In the method, when a user transceiver interface accesses the protocol stack rhc, whc, and memory pool data, and a resource conflict occurs with data processing in DDS_main_func on another core, a CP inter-core spin lock is added to protect the critical section.

6. The method for implementing DDS multi-core deployment on the AutoSar CP platform according to claim 5, characterized in that: Spin locks include memory pool locks, timed event locks, participant locks, writer locks, and reader locks.

7. The method for implementing DDS multi-core deployment on the AutoSar CP platform according to claim 6, characterized in that: The memory pool lock is used for the application and release of the protocol stack memory pool. The timed event lock is used for the creation and execution of the timer. The participant lock is used for the creation and deletion of all other entities managed by the participant lock. The writer lock is used for the lock between the user writing data and the whc. The reader lock is used for the lock between the user reading data and the rhc.

Images