Automotive multi-core processor peripheral resource virtualization system

Abstract

The present invention relates to a vehicle multi-core processor peripheral resource virtualization system, comprising a kernel, peripheral resources, and a peripheral virtual machine; the peripheral virtual machine comprises an access interface set and a peripheral resource access main program; the access interface set comprises an input access interface and an output access interface; the peripheral resource access main program is used to scan a peripheral resource access cache; the peripheral resource access cache is used to store data records of peripheral resource access requests; the peripheral resource access request comprises access control information; the access control information comprises a priority, a kernel identifier, an interface identifier, a peripheral channel identifier, an input data pointer, and an output data pointer; the interface identifier is used to indicate the access type of the current peripheral resource access request; the access type comprises synchronous and asynchronous. The present invention provides an undifferentiated peripheral access interface; improves the degree of freedom of application logic software development; and has high generality and portability in different hardware systems.

Description

Technical Field

[0001] The present invention relates to the technical field of automobile controller development, and in particular to a peripheral resource virtualization system for an automobile multi-core processor. Background Art

[0002] In the field of automotive controller development, computing power or instruction execution rate has gradually become a bottleneck in the controller development process. Therefore, multi-core microcontroller solutions are increasingly being introduced and applied to the development of automotive controllers, aiming to make up for the disadvantages of single-core chips in execution efficiency through "parallelism". However, in actual control systems, the implementation of control logic is based on specific input and output signals, that is, various peripheral resources in the microcontroller. These peripheral resources generally cannot be accessed by software control logic in multiple cores at the same time. When software logic in multiple cores accesses on-chip peripherals, it is generally necessary to add additional software logic to handle access conflicts based on hardware characteristics. On the one hand, it greatly limits the efficiency of multi-core operation, and on the other hand, it increases the complexity of application software development.

[0003] In the field of traditional automotive embedded control, for multi-core application scenarios, there are currently two existing technologies for handling the situation where multiple cores access peripheral resources.

[0004] The first prior art is: from the perspective of software architecture, the software logic that needs to access peripheral resources is separated from the software logic that does not need to access peripheral resources, and a single core is allocated to perform the access operation of peripheral resources, that is, to avoid the situation where multiple cores access peripherals.

[0005] The first prior art has the following defects:

[0006] 1. Due to the increased coupling between the application software and the underlying driver software, additional software logic needs to be considered and designed separately during the software development process, which is not conducive to the reuse of application software;

[0007] 2. Since all peripheral accesses are aggregated into one core, the independence of software execution in different cores is limited, thus reducing the efficiency of multi-core operation.

[0008] The second existing technology is: considering the specific chip hardware characteristics, such as the CAN communication peripheral modules of some chips, by isolating different communication channels in hardware design, supporting different channels of the CAN peripheral to be accessed by different cores.

[0009] The second prior art has the following defects:

[0010] 1. Since the second existing technology is developed specifically, each instance has its own particularity and depends on different chip hardware characteristics. Not all peripheral resources can support simultaneous access by multiple cores in hardware, so it can only solve some specific peripheral access problems and has low versatility.

[0011] 2. The multi-core access supported by hardware features also has certain limitations. For example, the CAN communication peripheral module of the chip can support different cores to access different communication channels, so when multiple cores need to access the same communication channel, the hardware solution cannot support it. Summary of the invention

[0012] In view of the above problems, the present invention provides a peripheral resource virtualization system for a multi-core processor for a vehicle, the purpose of which is to provide an undifferentiated peripheral access interface on the basis of ensuring the independent operation of multiple cores; while effectively preventing conflicts in access to the same peripheral by different cores and the software execution efficiency of a single core, decouple application software logic and peripheral drivers, thereby improving the degree of freedom of application logic software development; and have high generality and portability in different hardware systems.

[0013] To solve the above problems, the technical solution provided by the present invention is:

[0014] A vehicle multi-core processor peripheral resource virtualization system comprises a core, peripheral resources and a peripheral virtual machine for supporting unified management of different peripheral resources in different cores; wherein:

[0015] The peripheral virtual machine includes an access interface set and a peripheral resource access main program for controlling the process of the kernel accessing the peripheral resources; wherein:

[0016] The access interface set includes an input access interface and an output access interface; wherein:

[0017] The input access interface is used to load peripheral parameters and transmit data input by the peripheral resources or information input by the peripheral resources;

[0018] The output access interface is used to load peripheral parameters and transmit data output by the peripheral resource or information output by the peripheral resource;

[0019] The peripheral resource access main program is used to scan the peripheral resource access cache; the peripheral resource access cache is set in the peripheral virtual machine and is used to store data records of peripheral resource access requests initiated by the kernel; wherein:

[0020] The peripheral resource access request includes access control information; the access control information includes priority, kernel identification, interface identification, peripheral channel identification, input data pointer and output data pointer; wherein:

[0021] The priority is used to identify the processing priority of the current peripheral resource access request, and is dynamically allocated in real time when the kernel initiates the request;

[0022] The core identifier is used to uniquely identify the core that initiates the current request for accessing the peripheral resource;

[0023] The interface identifier is used to indicate the access type of the current peripheral resource access request and to indicate the access direction of the current peripheral resource access request; the access type includes synchronous and asynchronous; the access direction includes input access or output access;

[0024] The peripheral channel identifier is used to identify different hardware channels inside the same peripheral resource;

[0025] The input data pointer is used to transfer data when the peripheral resource accesses the input access interface;

[0026] The output data pointer is used for data transfer when the peripheral resource accesses the output access interface.

[0027] Preferably, the data record corresponds to the access control information, and also includes the priority, the kernel identifier, the interface identifier, the peripheral channel identifier, the input data pointer and the output data pointer; and satisfies:

[0028] The data structure of the priority of the data record is the same as the data structure of the priority of the access control information;

[0029] The data structure of the kernel identifier of the data record is the same as the data structure of the kernel identifier of the access control information;

[0030] The data structure of the interface identifier of the data record is the same as the data structure of the interface identifier of the access control information;

[0031] The data structure of the peripheral channel identifier of the data record is the same as the data structure of the peripheral channel identifier of the access control information;

[0032] The data structure of the input data pointer of the data record is the same as the data structure of the input data pointer of the access control information;

[0033] The data structure of the output data pointer of the data record is the same as the data structure of the output data pointer of the access control information.

[0034] Preferably, the peripheral resource access main program further includes an access control strategy for controlling the kernel's access to the peripheral resources; the access control strategy includes the following steps:

[0035] Sb100. When one of the cores initiates a request to access the peripheral resource, a new data record is created in the peripheral resource access cache corresponding to the peripheral resource to be accessed;

[0036] Sb200. Determine the access type of the peripheral resource access request, and then perform the following operations based on the determination result:

[0037] If the access type of the peripheral resource access request is asynchronous, the priority value of the data record corresponding to the peripheral resource access request is fixed to 1; then Sb300 is executed;

[0038] If the access type of the peripheral resource access request is synchronous, all the priority values ​​in the current peripheral resource access cache are traversed, and then the following operations are performed according to the traversal result:

[0039] If the maximum value of all the priorities in the current peripheral resource access cache is 0 or 1, the manually preset maximum priority value is assigned to the priority value of the data record corresponding to the peripheral resource access request; the maximum priority value is greater than 3; then Sb300 is executed;

[0040] If the maximum value of all the priorities in the current peripheral resource access cache is 2 or 3, the manually preset maximum value of the priority is assigned to the priority value of the data record corresponding to the peripheral resource access request, and then all the peripheral resource access requests in the peripheral resource access cache that have not been executed before this moment are cleared; then Sb300 is executed;

[0041] Otherwise, the value obtained by subtracting 1 from the maximum value of all the priorities in the current peripheral resource access cache is assigned to the priority value of the data record corresponding to the peripheral resource access request; then Sb300 is executed;

[0042] Sb300. The access control information of the peripheral resource access request is filled into the corresponding data record in the peripheral resource access cache;

[0043] Sb400 returns the request success information to the peripheral resource access main program;

[0044] Sb500. End this peripheral resource access request.

[0045] Preferably, the peripheral resource access main program processes each peripheral resource access request in the peripheral resource access cache according to the following steps:

[0046] Sc100. Scanning the priority of each peripheral resource access request in the peripheral resource access cache;

[0047] Sc200. For the data records with a priority level other than 0, processing the peripheral resource access request with the highest priority level in descending order of priority level;

[0048] Sc300. The priority of the processed peripheral resource access request is set to 0; then Sc400 is executed;

[0049] Sc400. Go back and perform Sc100 again until the car turns off.

[0050] Preferably, in the process of the peripheral resource access main program processing each peripheral resource access request in the peripheral resource access cache, the function of processing the peripheral resource access request is realized by calling the native interface in the driver software of the peripheral resource corresponding to each peripheral resource access request.

[0051] Preferably, it also includes a system initialization process; the system initialization process is implemented according to the following steps:

[0052] Sa100. Call the native driver software of the peripheral resource to be initialized to perform a peripheral resource initialization operation on the peripheral resource; then perform the following operations according to the result of the peripheral resource initialization operation:

[0053] If the result of the peripheral resource initialization operation is successful, execute Sa200;

[0054] If the result of the peripheral resource initialization operation is unsuccessful, or an error occurs during the peripheral resource initialization operation, a request failure message is returned to the ECU, and the system initialization process is exited;

[0055] Sa200. Perform a peripheral resource validity test operation on the peripheral resource to be initialized; then perform the following operations according to the result of the peripheral resource validity test operation:

[0056] If the result of the peripheral resource validity test operation is that the peripheral resource is valid and available, executing Sa300;

[0057] Otherwise, a request failure message is returned to the ECU, and the system initialization process is exited;

[0058] Sa300. Perform a communication channel validity test operation on all communication channels to be used by the peripheral resource to be initialized; then perform the following operations according to the result of the communication channel validity test operation:

[0059] If the result of the communication channel validity test operation is that the communication channel is valid and available, executing Sa400;

[0060] Otherwise, a request failure message is returned to the ECU, and the system initialization process is exited;

[0061] Sa400 initializes the peripheral resource access cache;

[0062] Sa500. Check whether the peripheral resource access cache has overflow; then perform the following operations based on the result of the check:

[0063] If the peripheral resource access cache overflows, a request failure message is returned to the ECU, and the system initialization process is exited;

[0064] Otherwise, a request success message is returned to the ECU and Sa600 is executed;

[0065] Sa600. Check whether there are any peripheral resources that have not yet been initialized; then perform the following operations based on the results of the check:

[0066] If there are still peripheral resources that have not been initialized, return to and execute Sa100 again;

[0067] Otherwise, the peripheral resource access main program is started to start receiving and responding to the peripheral resource access requests of different peripheral resources.

[0068] Preferably, the steps from Sc200 to Sc300 further include the following steps:

[0069] Sc210. Determine the access direction of the peripheral resource access request, and then perform the following operations according to the determination result:

[0070] If the access direction is input access, execute Sc220;

[0071] If the access direction is output access, execute Sc230;

[0072] Sc220. After the processing is completed, the input data record is copied to the memory corresponding to the input data pointer in the peripheral resource access cache;

[0073] Sc230. The output control parameters are first read from the data record in the memory corresponding to the output data pointer in the peripheral resource access cache, and then passed to the native driver software of the peripheral resource.

[0074] Preferably, in Sc100, the peripheral resource access main program periodically scans the priority of each peripheral resource access request in the peripheral resource access cache according to a manually preset scanning cycle;

[0075] Each of the peripheral resources has an independent scanning cycle preset manually.

[0076] Preferably, in Sc100, when a new peripheral resource access request is generated, the peripheral resource access main program is triggered to scan the peripheral resource access cache corresponding to the peripheral resource access request.

[0077] Preferably, each type of the peripheral resources corresponds to an independent peripheral resource access main program; each type of the peripheral resources corresponds to an independent peripheral resource access cache.

[0078] Compared with the prior art, the present invention has the following advantages:

[0079] 1. Since the present invention is specifically aimed at embedded multi-core application scenarios, where different software control logics are processed in parallel in different cores, and conflicts may occur when accessing the same on-chip peripheral resources, a technical solution for on-chip peripheral resource virtualization is adopted, thereby providing an undifferentiated peripheral access interface on the basis of ensuring the independent operation of multiple cores;

[0080] 2. Since the present invention provides an undifferentiated peripheral access interface, it can effectively prevent conflicts between different cores accessing the same peripheral and the software execution efficiency of a single core, while decoupling the application software logic and the peripheral driver, thereby improving the degree of freedom of application logic software development;

[0081] 3. Since the structural design of the present invention also combines the peripheral access characteristics of existing automotive multi-core microprocessors, it has high generality and portability in different hardware systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0082] Figure 1 It is a structural diagram of a peripheral resource virtualization system according to a specific embodiment of the present invention;

[0083] Figure 2 A schematic diagram of the structure of a peripheral resource access request according to a specific embodiment of the present invention;

[0084] Figure 3 A schematic diagram of a process flow of system initialization according to a specific embodiment of the present invention;

[0085] Figure 4 A schematic diagram of a flow chart of an access control strategy according to a specific embodiment of the present invention;

[0086] Figure 5 The present invention is a flowchart of a peripheral resource access main program processing each peripheral resource access request in a peripheral resource access cache according to a specific embodiment of the present invention. DETAILED DESCRIPTION

[0087] The present invention is further explained below in conjunction with specific embodiments. It should be understood that these embodiments are only used to illustrate the present invention and are not used to limit the scope of the present invention. After reading the present invention, various equivalent forms of modifications to the present invention by those skilled in the art all fall within the scope defined by the claims attached to this application.

[0088] like Figure 1 As shown, it should be noted that this specific embodiment designs a peripheral virtual machine based on the native microcontroller peripheral driver software to provide undifferentiated input access interfaces and output access interfaces for different cores to access all peripheral resources on the chip. On these interfaces, application software and operating systems can be easily deployed and integrated.

[0089] It should also be noted in advance that in order to reduce system overhead, the peripheral virtualization interface in this specific embodiment only involves peripheral functions related to the application software, that is, only the peripheral functions used by the application software are virtualized, and the application software can access them freely. Peripheral resource initialization, interrupt processing, etc. are uniformly managed and are invisible to the application software.

[0090] It should also be noted that the virtualization functions involved in different peripheral resources are shown in Table 1:

[0091] Table 1. List of peripheral resources involving virtualization functions

[0092] Input Access Output Access ADC AD conversion value - DI PIN level - ICU Pulse signal period - DO - PIN level PWM - Period, Duty Cycle GPT Overflow Threshold Current count value SPI Sending Data Receiving Data I2C Sending Data Receiving Data LIN Sending LIN messages Receiving LIN messages CAN Send CAN message Receiving CAN messages ETH Send ETH message Receive ETH message

[0093] The automotive multi-core processor peripheral resource virtualization system includes a core, peripheral resources, and a peripheral virtual machine for supporting unified management of different peripheral resources in different cores; wherein:

[0094] The peripheral virtual machine includes an access interface set and a peripheral resource access main program for controlling the process of the kernel accessing peripheral resources; wherein:

[0095] The access interface collection includes input access interfaces and output access interfaces.

[0096] According to the functional definition in Table 1, the access to different peripheral resources is summarized into two types of interfaces in order to unify the internal software implementation logic of the peripheral virtual machine, where:

[0097] The input access interface is used to load peripheral parameters and transmit data or information input by peripheral resources; such as ADC sampling values ​​or CAN communication reception messages.

[0098] The output access interface is used to load peripheral parameters and transmit data or information output by peripheral resources, such as the period collected by the ICU or the message sent by ETH communication.

[0099] In this specific embodiment, in addition to the above-mentioned interfaces, other accesses involved in the implementation of peripheral functions, such as initialization, parameter setting, fault handling, etc. of peripherals, are considered. Then, offline configuration is solidified, and peripheral virtual machines are uniformly managed, and different cores share the same configuration information.

[0100] It should be noted that the advantages of doing so are: on the one hand, the application software logic generally does not involve the modification of such parameters; on the other hand, it can balance the resource usage of the peripheral virtual machine and the real-time access, which is more suitable for automotive embedded systems with insufficient resources.

[0101] In this specific embodiment, the peripheral functions that require unified management by the peripheral virtual machine and do not provide access control are shown in Table 2:

[0102] Table 2. Peripheral functions that are centrally managed and do not provide access control

[0103]

[0104]

[0105] It should be noted that different cores access the peripheral resources inside the microcontroller by calling the access interface of the virtualized peripheral resources.

[0106] The peripheral resource access main program is used to scan the peripheral resource access cache; the peripheral resource access cache is set in the peripheral virtual machine and is used to store data records of peripheral resource access requests initiated by the kernel.

[0107] like Figure 2 As shown, the peripheral resource access request includes access control information; the access control information includes priority, core identification, interface identification, peripheral channel identification, input data pointer and output data pointer; wherein, for peripheral resources of the same type (ADC, CAN...), a fixed-depth peripheral resource access cache is created inside the peripheral virtual machine, and each data record in the peripheral resource access cache includes:

[0108] The priority is used to identify the processing priority of the current peripheral resource access request, and is dynamically allocated in real time when the kernel initiates the request.

[0109] The core identifier is used to uniquely identify the core that initiates the current request for accessing the peripheral resource, that is, which core initiates the current request for accessing the peripheral resource.

[0110] The interface identifier is used to indicate the access type of the current peripheral resource access request and to indicate the access direction of the current peripheral resource access request; the access type includes synchronous and asynchronous; the access direction includes input access or output access.

[0111] The peripheral channel identifier is used to identify different hardware channels within the same peripheral resource, such as different acquisition channels of an ADC peripheral or different nodes of a CAN peripheral.

[0112] The input data pointer is used to indicate the input data pointer, and data is transferred when the peripheral resource accesses the input access interface.

[0113] The output data pointer is used to indicate the output data pointer, and data is transferred when the peripheral resource accesses the output access interface.

[0114] It should be noted that the access type is divided into two types: synchronous and asynchronous. A basic judgment principle in this specific embodiment is that the synchronous access type corresponds to a high real-time application scenario. After the peripheral virtual machine receives the peripheral resource access request, it will immediately execute the access operation. The asynchronous access type will only execute the access operation when the peripheral resources are idle.

[0115] The data record corresponds to the access control information, and also includes the priority, core identifier, interface identifier, peripheral channel identifier, input data pointer, and output data pointer; and meets the following requirements:

[0116] The data structure of the priority of the data record is the same as the data structure of the priority of the access control information.

[0117] The data structure of the kernel identifier of the data record is the same as the data structure of the kernel identifier of the access control information.

[0118] The data structure of the interface identifier of the data record is the same as the data structure of the interface identifier of the access control information.

[0119] The data structure of the peripheral channel identifier of the data record is the same as the data structure of the peripheral channel identifier of the access control information.

[0120] The data structure of the input data pointer of the data record is the same as the data structure of the input data pointer of the access control information.

[0121] The data structure of the output data pointer of the data record is the same as the data structure of the output data pointer of the access control information.

[0122] like Figure 3 As shown, in this specific embodiment, the system also includes a system initialization process; the system initialization process is implemented according to the following steps:

[0123] Sa100. Call the native driver software of the peripheral resource to be initialized to perform the peripheral resource initialization operation on the peripheral resource; then perform the following operations according to the result of the peripheral resource initialization operation:

[0124] If the result of the peripheral resource initialization operation is successful, Sa200 is executed.

[0125] If the result of the peripheral resource initialization operation is unsuccessful, or an error occurs during the peripheral resource initialization operation, a request failure message is returned to the ECU and the system initialization process is exited.

[0126] It should be noted that in this specific embodiment, the virtualization implementation involved must first use native peripheral driver software to initialize peripheral resources during the initialization phase to meet the subsequent use of other native interfaces for input and output access to peripheral resources.

[0127] It should be further explained that, since the present invention simplifies the virtualization of the peripheral access interface, in order to avoid exceptions during access, such as the use of undefined hardware channels, for the peripheral resources that need to be used, a peripheral resource list is created inside the peripheral virtual machine for subsequent checking whether the peripheral resource access request is reasonable.

[0128] To ensure the effectiveness of the functions implemented by the virtualized access interface, the initialization phase also includes testing of peripheral resources, such as acquisition tests of different ADC channels, transceiver tests of different CAN communication channels, etc., to confirm that the current peripheral resources can be effectively accessed. Finally, the peripheral access cache is initialized, and the main program for processing access requests of different peripheral resources is started to receive and respond to peripheral requests.

[0129] Sa200. Perform a peripheral resource validity test operation on the peripheral resource to be initialized; then perform the following operations based on the result of the peripheral resource validity test operation:

[0130] If the result of the peripheral resource validity test operation is that the peripheral resource is valid and available, Sa300 is executed.

[0131] Otherwise, a request failure message is returned to the ECU and the system initialization process is exited.

[0132] Sa300. Perform a communication channel validity test operation on all communication channels to be used by the peripheral resources to be initialized; then perform the following operations based on the results of the communication channel validity test operation:

[0133] If the result of the communication channel validity test operation is that the communication channel is valid and available, Sa400 is executed.

[0134] Otherwise, a request failure message is returned to the ECU and the system initialization process is exited.

[0135] Sa400. Initialize the peripheral resource access cache.

[0136] Sa500. Checks whether the peripheral resource access cache has overflowed; then, based on the check result, performs the following operations:

[0137] If the peripheral resource access cache overflows, a request failure message is returned to the ECU and the system initialization process is exited.

[0138] Otherwise, a request success message is returned to the ECU and Sa600 is executed.

[0139] Sa600. Check whether there are any peripheral resources that have not been initialized; then perform the following operations based on the results of the check:

[0140] If there are peripheral resources that have not been initialized, the process returns and executes Sa100 again.

[0141] Otherwise, the peripheral resource access main program is started to receive and respond to peripheral resource access requests of different peripheral resources.

[0142] It should be noted that when the peripheral virtual machine receives a peripheral resource access request, it first performs necessary error checks, including whether the requested peripheral resource has been initialized or has errors, whether the requested peripheral channel has been configured offline, and whether the peripheral resource access cache has overflowed. When the above errors or exceptions are detected, the interface returns a request failure.

[0143] like Figure 4 As shown, the peripheral resource access main program also includes an access control strategy for controlling the kernel's access to peripheral resources; the access control strategy includes the following steps:

[0144] Sb100. When a core initiates a peripheral resource access request, a new data record is created in the peripheral resource access cache corresponding to the peripheral resource that needs to be accessed.

[0145] Sb200. Determine the access type of the peripheral resource access request, and then perform the following operations based on the determination result:

[0146] If the access type of the peripheral resource access request is asynchronous, the priority value of the data record corresponding to the peripheral resource access request is fixedly set to 1; then Sb300 is executed.

[0147] If the access type of the peripheral resource access request is synchronous, all priority values ​​in the current peripheral resource access cache are traversed, and then the following operations are performed according to the traversal results:

[0148] If the maximum value of all priorities in the current peripheral resource access cache is 0 or 1, the manually preset maximum priority value is assigned to the priority value of the data record corresponding to the peripheral resource access request; the maximum priority value is greater than 3; and then Sb300 is executed.

[0149] If the maximum value of all priorities in the current peripheral resource access cache is 2 or 3, the manually preset maximum priority value is assigned to the priority value of the data record corresponding to the peripheral resource access request, and then all peripheral resource access requests in the peripheral resource access cache that have not been executed before this moment are cleared; then Sb300 is executed.

[0150] Otherwise, the value obtained by subtracting 1 from the maximum value of all priorities in the current peripheral resource access cache is assigned to the priority value of the data record corresponding to the peripheral resource access request; then Sb300 is executed.

[0151] In order to better illustrate the above priority filling rules, the inventors have made the following detailed descriptions:

[0152] It should be clear that the basic principle of priority filling of the present invention is: the filling of priority depends on whether the current request is synchronous or asynchronous.

[0153] For asynchronous access requests, priority = 1 is fixedly assigned; priority = 2 is reserved, and priority = 0 is used to indicate that the current cache record is not in use.

[0154] For synchronous access requests, the priority will be the highest priority Level Top to Priority = 3, specifically:

[0155] When there is no synchronization request in the peripheral resource access cache, that is, the first request for synchronization access, the priority of this data record in the peripheral resource access cache = Level init ; It should be noted that the Level Top =Level init; When there are unexecuted synchronization requests in the peripheral resource access cache, that is, the second, third, ... requests request synchronization access, the priority is the highest priority Level in the current cache current -1, for example, when requesting synchronous access for the second time, the priority assigned is Level init -1 (At this time, Level current =Level init ).

[0156] Similarly, the priority of new synchronous access requests decreases in sequence; but when it decreases to 2, this is an abnormal situation, indicating that the synchronous request of the peripheral resource access cache is blocked, and then the priority of the new synchronous access request decreases from Level 2. init Starts to restart decrement allocation and clears previously unexecuted access requests of the synchronization type.

[0157] After assigning the priority of the current access request, the other data in the peripheral resource access cache is filled with the parameters passed by the virtualized access interface. Finally, the request is returned successful.

[0158] In order to better explain the priority filling rules of synchronous peripheral resource access requests, the inventor further explains as follows:

[0159] When the peripheral virtual machine receives a peripheral resource access request, it performs the above check; after the check, if the current peripheral resource access request is synchronous, it is necessary to first calculate the highest priority Level in the current peripheral resource access cache current :

[0160] If the highest priority = 0 or 1, that is, Level current =0 or 1, indicating that there is no unexecuted synchronization request, the highest priority Levelinit is assigned to the currently synchronized peripheral resource access request.

[0161] If the highest priority is greater than 3, Level init >=Level current >3, indicating that there are unexecuted synchronous peripheral resource access requests, the priority assigned to the current synchronous peripheral resource access request is Level current -1, in the peripheral resource access main program where the peripheral virtual machine responds to the peripheral resource access request, high priority requests will be processed first. Such a priority allocation scheme can ensure that the synchronous peripheral resource access requests are responded to in a first-in-first-out manner.

[0162] If the highest priority = 3, that is, Level current=3, indicating that there is no priority for synchronous peripheral resource access requests that can be allocated, that is, the peripheral resource access cache where the synchronous peripheral resource access request is located is full. This is usually due to an internal error that caused a large number of synchronous or asynchronous peripheral resource access requests to be accumulated and could not be responded to in time. At this time, all the previously cached peripheral resource access requests need to be cleared and re-started from Level init Start allocating priorities. The priority of the current peripheral resource access request is Level init .

[0163] Level init The value is a default value set offline, which is set independently for different peripheral resources. Its determination should take into account the size of the peripheral resource access cache and the proportion of synchronous peripheral resource access requests to asynchronous peripheral resource access requests in actual applications.

[0164] Sb300. Fill the access control information of the peripheral resource access request into the corresponding data record in the peripheral resource access cache, including the core identifier, interface identifier, peripheral channel identifier, input data pointer and output data pointer. ;

[0165] Sb400. Returns request success information to the peripheral resource access main program.

[0166] Sb500. End this peripheral resource access request.

[0167] like Figure 5 As shown, the peripheral resource access main program processes each peripheral resource access request in the peripheral resource access cache according to the following steps:

[0168] Sc100. Scan the priority of each peripheral resource access request in the peripheral resource access cache.

[0169] In this specific embodiment, in Sc100, the peripheral resource access main program periodically scans the priority of each peripheral resource access request in the peripheral resource access cache according to a manually preset scanning cycle.

[0170] It should be further explained that each peripheral resource has an independent scanning cycle preset manually.

[0171] In this specific embodiment, in Sc100, when a new peripheral resource access request is generated, the peripheral resource access main program is triggered to scan the peripheral resource access cache corresponding to the peripheral resource access request.

[0172] It should be further explained that the peripheral virtual machine contains a peripheral resource access main program, which scans the peripheral resource access cache corresponding to the peripheral resource with different periodic scans or triggers the scan when a new peripheral resource access request is received according to different peripheral access characteristics. For data records with non-0 priority, each peripheral resource access request is processed in sequence, starting from the data records of the peripheral resource access request with high priority; after the processing is completed, the priority of the corresponding peripheral resource access request data record is set to 0; the process of processing the peripheral resource access request is implemented using the native interface in the peripheral driver software.

[0173] It should be further explained that each type of peripheral resource uses independent cache data, and there is no coupling between different peripheral resources. Therefore, in the application, the virtual software of different peripheral resources can be deployed on different cores based on the actual load of each core to balance the comprehensive load of several cores.

[0174] It should be further explained that, since the virtualized access interface of peripheral resources only involves the input and output characteristics directly related to the application function, the status feedback of peripheral resources does not provide a direct access interface, but is reflected in the return value through each call to the virtualized input and output interface, that is, when the peripheral resource cannot receive the access request, the request failure status is directly returned. In addition, the space of the peripheral resource access cache is limited. When there is no idle peripheral resource access cache, the request failure is also returned.

[0175] It should be further explained that the present invention also takes into account the problem of possible conflicts when processing multiple cores accessing the same peripheral resources; for this problem, this specific embodiment adopts a method of combining peripheral resource access requests from different cores into a serialized access queue and placing it in the peripheral resource access cache; and then using additional access control software, that is, the peripheral resource access main program in the peripheral virtual machine, to process each peripheral resource access request in turn to solve it.

[0176] Sc200. For data records with a priority level other than 0, process the peripheral resource access request with the highest priority level in descending order.

[0177] Sc210. Determine the access direction of the peripheral resource access request, and then perform the following operations based on the determination result:

[0178] If the access direction is input access, execute Sc220.

[0179] If the access direction is output access, execute Sc230.

[0180] Sc220. After the processing is completed, the input data record is copied to the memory corresponding to the input data pointer in the peripheral resource access cache.

[0181] Sc230. The output control parameters are first read from the data record in the memory corresponding to the output data pointer in the peripheral resource access cache, and then passed to the native driver software of the peripheral resource.

[0182] Sc300. Set the priority of the processed peripheral resource access request to 0; then execute Sc400.

[0183] Sc400. Go back and perform Sc100 again until the car turns off.

[0184] In this specific embodiment, during the process of the peripheral resource access main program processing each peripheral resource access request in the peripheral resource access cache, the function of processing the peripheral resource access request is implemented by calling the native interface in the driver software of the peripheral resource corresponding to each peripheral resource access request.

[0185] It should be noted that each type of peripheral resource corresponds to an independent peripheral resource access main program; each type of peripheral resource corresponds to an independent peripheral resource access cache.

[0186] It should be further explained that, in this specific embodiment, the actual access operation to the peripheral resources is implemented in the peripheral resource access main program inside the peripheral virtual machine.

[0187] Therefore, in addition to the above functions, the main program for accessing peripheral resources also includes the error handling function of peripheral resources. When an abnormality is detected in the peripheral, recovery is attempted by resetting the peripheral and reinitializing it.

[0188] When there is no error in the peripheral resources, the peripheral resource access main program will scan all peripheral resource access caches, call the peripheral native driver software in descending order of priority, and process each peripheral resource access request in turn; among them:

[0189] For an input peripheral resource access request, after processing is completed, the input data is copied to the memory corresponding to the data pointer in the peripheral resource access cache.

[0190] For the output peripheral resource access request, the output control parameters are first read from the memory corresponding to the data pointer in the peripheral resource access cache, and then passed to the native peripheral driver software. After executing an access to the peripheral resource access cache, the priority in the data record is set to 0 to release the cache space.

[0191] It should be further explained that different types of peripheral resources correspond to a peripheral resource access main program. The execution cycle of the peripheral resource access main program can be defined offline according to the access frequency of the application software to this peripheral resource, that is, the peripheral resources with high frequency of access adopt a shorter execution cycle.

[0192] In addition, for access to some key peripheral resources, such as security-related operations that require strict synchronous execution, the execution of the peripheral resource access main program can be additionally triggered after requesting access to the peripheral resources.

[0193] In the above detailed description, various features are grouped together in a single embodiment to simplify the disclosure. This method of disclosure should not be interpreted as reflecting an intention that the embodiments of the claimed subject matter require more features than are clearly stated in each claim. On the contrary, as reflected in the appended claims, the invention is in a state of having less than all the features of the disclosed individual embodiments. Therefore, the appended claims are hereby expressly incorporated into the detailed description, with each claim standing on its own as a separate preferred embodiment of the invention.

[0194] The disclosed embodiments are described above to enable any person skilled in the art to implement or use the present invention. Various modifications of these embodiments are obvious to those skilled in the art, and the general principles defined herein may also be applied to other embodiments without departing from the spirit and scope of the present disclosure. Therefore, the present disclosure is not limited to the embodiments given herein, but is consistent with the broadest scope of the principles and novel features disclosed in this application.

[0195] The above description includes examples of one or more embodiments. Of course, it is not possible to describe all possible combinations of components or methods for the purpose of describing the above embodiments, but it should be recognized by those skilled in the art that the various embodiments may be further combined and arranged. Therefore, the embodiments described herein are intended to cover all such changes, modifications and variations that fall within the scope of protection of the appended claims. In addition, with respect to the term "comprising" used in the specification or claims, the word is covered in a manner similar to the term "including", just as "including," is explained as a transitional word in the claims. In addition, any term "or" used in the specification of the claims is intended to mean "non-exclusive or".

[0196] The specific implementation methods described above further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above description is only a specific implementation method of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A vehicle multi-core processor peripheral resource virtualization system, characterized in that: It includes a kernel, peripheral resources and a peripheral virtual machine for supporting unified management of different peripheral resources in different kernels; wherein: The peripheral virtual machine includes an access interface set and a peripheral resource access main program for controlling the process of the kernel accessing the peripheral resources; wherein: The access interface set includes an input access interface and an output access interface; wherein: The input access interface is used to load peripheral parameters and transmit data input by the peripheral resources or information input by the peripheral resources; The output access interface is used to load peripheral parameters and transmit data output by the peripheral resource or information output by the peripheral resource; The peripheral resource access main program is used to scan the peripheral resource access cache; the peripheral resource access cache is set in the peripheral virtual machine and is used to store data records of peripheral resource access requests initiated by the kernel; wherein: The peripheral resource access request includes access control information; the access control information includes priority, kernel identification, interface identification, peripheral channel identification, input data pointer and output data pointer; wherein: The priority is used to identify the processing priority of the current peripheral resource access request, and is dynamically allocated in real time when the kernel initiates the request; The core identifier is used to uniquely identify the core that initiates the current request for accessing the peripheral resource; The interface identifier is used to indicate the access type of the current peripheral resource access request and to indicate the access direction of the current peripheral resource access request; the access type includes synchronous and asynchronous; the access direction includes input access or output access; The peripheral channel identifier is used to identify different hardware channels inside the same peripheral resource; The input data pointer is used to transfer data when the peripheral resource accesses the input access interface; The output data pointer is used for data transfer when the peripheral resource accesses the output access interface.

2. The vehicle multi-core processor peripheral resource virtualization system according to claim 1, characterized in that: The data record corresponds to the access control information, and also includes the priority, the kernel identifier, the interface identifier, the peripheral channel identifier, the input data pointer, and the output data pointer; and satisfies: The data structure of the priority of the data record is the same as the data structure of the priority of the access control information; The data structure of the kernel identifier of the data record is the same as the data structure of the kernel identifier of the access control information; The data structure of the interface identifier of the data record is the same as the data structure of the interface identifier of the access control information; The data structure of the peripheral channel identifier of the data record is the same as the data structure of the peripheral channel identifier of the access control information; The data structure of the input data pointer of the data record is the same as the data structure of the input data pointer of the access control information; The data structure of the output data pointer of the data record is the same as the data structure of the output data pointer of the access control information.

3. The vehicle multi-core processor peripheral resource virtualization system according to claim 2, characterized in that: The peripheral resource access main program also includes an access control strategy for controlling the kernel to access the peripheral resources; the access control strategy includes the following steps: Sb100. When one of the cores initiates a request to access the peripheral resource, a new data record is created in the peripheral resource access cache corresponding to the peripheral resource to be accessed; Sb200. Determine the access type of the peripheral resource access request, and then perform the following operations based on the determination result: If the access type of the peripheral resource access request is asynchronous, the priority value of the data record corresponding to the peripheral resource access request is fixed to 1; then Sb300 is executed; If the access type of the peripheral resource access request is synchronous, all the priority values ​​in the current peripheral resource access cache are traversed, and then the following operations are performed according to the traversal result: If the maximum value of all the priorities in the current peripheral resource access cache is 0 or 1, the manually preset maximum priority value is assigned to the priority value of the data record corresponding to the peripheral resource access request; the maximum priority value is greater than 3; then Sb300 is executed; If the maximum value of all the priorities in the current peripheral resource access cache is 2 or 3, the manually preset maximum value of the priority is assigned to the priority value of the data record corresponding to the peripheral resource access request, and then all the peripheral resource access requests in the peripheral resource access cache that have not been executed before this moment are cleared; then Sb300 is executed; Otherwise, assigning a value obtained by subtracting 1 from the maximum value of all the priorities in the current peripheral resource access cache to the priority value of the data record corresponding to the peripheral resource access request; Then execute Sb300; Sb300. The access control information of the peripheral resource access request is filled into the corresponding data record in the peripheral resource access cache; Sb400 returns the request success information to the peripheral resource access main program; Sb500. End this peripheral resource access request.

4. The vehicle multi-core processor peripheral resource virtualization system according to claim 3, characterized in that: The peripheral resource access main program processes each peripheral resource access request in the peripheral resource access cache according to the following steps: Sc100. Scanning the priority of each peripheral resource access request in the peripheral resource access cache; Sc200. For the data records with a priority level other than 0, processing the peripheral resource access request with the highest priority level in descending order of priority levels; Sc300. The priority of the processed peripheral resource access request is set to 0; then executing Sc400; Sc400. Go back and perform Sc100 again until the car turns off.

5. The vehicle multi-core processor peripheral resource virtualization system according to claim 4, characterized in that: In the process of the peripheral resource access main program processing each peripheral resource access request in the peripheral resource access cache, the function of processing the peripheral resource access request is realized by calling the native interface in the driver software of the peripheral resource corresponding to each peripheral resource access request.

6. The vehicle multi-core processor peripheral resource virtualization system according to claim 5, characterized in that: It also includes a system initialization process; the system initialization process is implemented according to the following steps: Sa100. Call the native driver software of the peripheral resource to be initialized to perform a peripheral resource initialization operation on the peripheral resource; then perform the following operations according to the result of the peripheral resource initialization operation: If the result of the peripheral resource initialization operation is successful, execute Sa200; If the result of the peripheral resource initialization operation is unsuccessful, or an error occurs during the peripheral resource initialization operation, a request failure message is returned to the ECU, and the system initialization process is exited; Sa200. Perform a peripheral resource validity test operation on the peripheral resource to be initialized; then perform the following operations according to the result of the peripheral resource validity test operation: If the result of the peripheral resource validity test operation is that the peripheral resource is valid and available, executing Sa300; Otherwise, a request failure message is returned to the ECU, and the system initialization process is exited; Sa300. Perform a communication channel validity test operation on all communication channels to be used by the peripheral resource to be initialized; then perform the following operations according to the result of the communication channel validity test operation: If the result of the communication channel validity test operation is that the communication channel is valid and available, executing Sa400; Otherwise, a request failure message is returned to the ECU, and the system initialization process is exited; Sa400 initializes the peripheral resource access cache; Sa500. Check whether the peripheral resource access cache has overflow; then perform the following operations based on the result of the check: If the peripheral resource access cache overflows, a request failure message is returned to the ECU, and the system initialization process is exited; Otherwise, a request success message is returned to the ECU and Sa600 is executed; Sa600. Check whether there are any peripheral resources that have not yet been initialized; then perform the following operations based on the results of the check: If there are still peripheral resources that have not been initialized, return to and execute Sa100 again; Otherwise, the peripheral resource access main program is started to start receiving and responding to the peripheral resource access requests of different peripheral resources.

7. The vehicle multi-core processor peripheral resource virtualization system according to claim 6, characterized in that: The steps between Sc200 and Sc300 also include the following: Sc210. Determine the access direction of the peripheral resource access request, and then perform the following operations according to the determination result: If the access direction is input access, execute Sc220; If the access direction is output access, execute Sc230; Sc220. After the processing is completed, the input data record is copied to the memory corresponding to the input data pointer in the peripheral resource access cache; Sc230. The output control parameters are first read from the data record in the memory corresponding to the output data pointer in the peripheral resource access cache, and then passed to the native driver software of the peripheral resource.

8. The vehicle multi-core processor peripheral resource virtualization system according to claim 7, characterized in that: In Sc100, the peripheral resource access main program periodically scans the priority of each peripheral resource access request in the peripheral resource access cache according to a manually preset scanning period; Each of the peripheral resources has an independent scanning cycle preset manually.

9. The vehicle multi-core processor peripheral resource virtualization system according to claim 7, characterized in that: In Sc100, when a new peripheral resource access request is generated, the peripheral resource access main program is triggered to scan the peripheral resource access cache corresponding to the peripheral resource access request.

10. A vehicle multi-core processor peripheral resource virtualization system according to any one of claims 8 or 9, characterized in that: Each type of the peripheral resources corresponds to an independent peripheral resource access main program; each type of the peripheral resources corresponds to an independent peripheral resource access cache.

Images