Configuration method and device

Abstract

The invention provides a configuration method and device which can be applied to the field of intelligent vehicles. The method comprises the following steps: acquiring an operating system object configuration file of an application program and a service code of the application program; converting the operating system object configuration file of the application program to obtain an operating system object configuration code; compiling the operating system object configuration code and the service code of the application program to obtain a static library of the application program; and linking the static library of the application program and the static library of the operating system kernel to obtain an executable file. The embodiment of the invention can be applied to the development process of intelligent automobiles or electric automobiles, multiple suppliers do not need to merge the operating system object configuration files, the efficiency of developers is improved, and the manpower communication cost and the time cost during development are saved.

Description

Technical Field

[0001] The present application relates to the field of smart cars, and more specifically, to a configuration method and device. Background Art

[0002] At present, automotive electronic networks are developing towards multi-bus hybrid network interconnection. In 2003, in order to avoid compatibility issues among major manufacturers, the automotive field launched an open and standardized automotive embedded system software architecture (Automotive Open System Architecture, AUTOSAR) specification. Each automobile manufacturer can develop its own software based on this standard.

[0003] In the development process of the traditional automotive embedded system software architecture (classic AUTOSAR, CP), multiple suppliers need to merge the operating system (OS) object configuration files multiple times, generate a unified OS dynamic configuration code in the kernel, and compile the source code at the same time, which brings a lot of manpower communication costs and time costs. Summary of the invention

[0004] The present application provides a configuration method and device that eliminates the need to merge multiple OS object configuration files provided by multiple vendors, thereby helping to improve the efficiency of developers and save manpower communication costs and time costs during the development period.

[0005] In a first aspect, a configuration method is provided, the method comprising: obtaining an operating system (OS) object configuration file of a first application and a business code of the first application; converting the OS object configuration file of the first application to obtain a first OS object configuration code; compiling the first OS object configuration code and the business code of the first application to obtain a static library of the first application; and linking the static library of the first application with a static library of the OS kernel to obtain an executable file.

[0006] Based on the above technical solution, the OS object configuration code is obtained by converting the OS object configuration file of the application, and the OS object configuration code and the business code of the application are compiled to obtain the static library of the application. In this way, only the OS object configuration file and business code provided by each supplier are needed to obtain the final executable file, and there is no need to merge the OS object configuration files provided by multiple suppliers, which helps to improve the efficiency of developers and save the communication cost and time cost of manpower during the development period.

[0007] In the embodiment of the present application, the OS object configuration file used by the application is separated from the OS kernel, the OS kernel is released separately as a component, and the OS object configuration file used for the configuration of the application is combined with the business code and released separately, which can solve the problem of parallel development of AUTOSAR CP, decouple the modules, and each component can release a binary component separately.

[0008] In some possible implementations, converting the OS object configuration file of the first application includes: converting the OS object configuration file of the first application by using an AUTOSAR configuration tool.

[0009] In some possible implementations, compiling the first OS object configuration code and the business code of the first application includes: compiling the first OS object configuration code and the business code of the first application by a compiler.

[0010] In some possible implementations, linking the static library of the first application with the static library of the OS kernel includes: linking the static library of the first application with the static library of the OS kernel through a compiler.

[0011] In some possible implementations, the first OS object configuration code (e.g., App1_os_cfg.c) and the business code of the first application (e.g., App1.c) are compiled to obtain a static library of the first application (e.g., App1.a), including: compiling the first OS object configuration code to obtain a third OS object configuration code (e.g., App1_os_cfg.c.obj) and compiling the business code of the first application to obtain another business code (e.g., App1.c.obj); packaging the third OS object configuration code and the another business code to obtain a static library of the first application.

[0012] In combination with the first aspect, in certain implementations of the first aspect, the method also includes: obtaining an OS object configuration file of a second application and a business code of the second application; converting the OS object configuration file of the second application to obtain a second OS object configuration code; compiling the second OS object configuration code and the business code of the second application to obtain a static library of the second application; wherein, linking the static library of the first application with the static library of the OS kernel to obtain an executable file includes: linking the static library of the first application, the static library of the second application, and the static library of the OS kernel to obtain the executable file.

[0013] Based on the above technical solution, the OS can support multiple applications, which can be provided by different suppliers. Different suppliers can publish OS object configuration files and business codes used for the configuration of applications in parallel. When generating executable files, it is only necessary to link the static libraries of different applications with the static libraries of the OS kernel. In this way, there is no need to merge OS object configuration files provided by multiple suppliers, which helps to improve the efficiency of developers and save the communication cost and time cost of manpower during development.

[0014] In combination with the first aspect, in certain implementations of the first aspect, the OS object configuration file of the first application includes a configuration file of the first OS object, the OS object configuration file of the second application includes a configuration file of the second OS object, and the first OS object initiates interaction with the second OS object, wherein the OS object configuration file of the first application is transformed to obtain a first OS object configuration code, including: configuring a third OS object with the same name as the second OS object in the OS object configuration file of the first application and adding a first attribute to the third OS object, the first attribute indicating that the third OS object is an external object; and transforming the OS object configuration file of the second application to obtain a second OS object configuration code, including: adding a second attribute to the second OS object in the OS object configuration file of the second application, the second attribute being used to indicate that the second OS object is an output object.

[0015] Based on the above technical solution, when OS objects in different applications interact, the user operates the OS object of the provider, and can configure the OS object with the same name on the user and mark it with external (extern) attributes, and the provider can mark the output (extern) attributes on the corresponding OS object, so that the interaction of OS objects in different applications can be realized. In this way, there is no need to use complex API parameters to realize the interaction of OS objects, which helps to reduce the development difficulty of developers and also helps to improve the efficiency of developers.

[0016] In some possible implementations, during the conversion of the OS object configuration file of the first application, no corresponding control block is generated for the third OS object, and only a reference thereof is used.

[0017] In some possible implementations, adding the first attribute to the third OS object includes: generating an external (extern) declaration of a control block variable for the third OS object.

[0018] In some possible implementations, adding a second attribute to the second OS object includes: adding an export attribute to the second OS object.

[0019] In combination with the first aspect, in certain implementations of the first aspect, the OS object configuration file of the first application includes configuration files of one or more OS objects, and the OS object configuration file of the first application is converted to obtain a first OS object configuration code, including: for each OS object in the one or more OS objects, generating a control block CB corresponding to each OS object; encoding the pointer of the CB corresponding to each OS object into a pointer array, and the pointer array constitutes the configuration variables of the first application; wherein the method also includes: when the OS is started, registering the configuration variables of the first application in the OS kernel.

[0020] Based on the above technical solution, the OS can support multiple applications. Each application calls an interface to register the configuration information of its OS object with the OS kernel during the OS startup phase. The OS startup phase can complete the initialization of the OS object according to the configuration information of the application.

[0021] In some possible implementations, the OS object configuration file of the first application includes configuration files of multiple types of OS objects (e.g., tasks, events, and alarms), each type of OS object includes multiple OS objects of that type, the pointer of each OS object of that type constitutes the pointer data of the OS object of that type, and the pointer arrays of different types of OS objects constitute the configuration variables of the first application.

[0022] In combination with the first aspect, in some implementations of the first aspect, the identifier of each OS object is determined by the identifier of the first application and the identifier of each OS object within the first application.

[0023] Based on the above technical solution, the identity of each OS object can be determined by the identity of the application and the identity of the OS object in the application. In this way, the configuration of the application can have a globally unique configuration name that constitutes the prefix of its OS object namespace, avoiding code conflicts with the OS object configurations of other applications.

[0024] In the second aspect, the present application provides a configuration device, which includes: an acquisition unit, used to acquire an operating system OS object configuration file of a first application and a business code of the first application; a conversion unit, used to convert the OS object configuration file of the first application to obtain a first OS object configuration code; a compilation unit, used to compile the first OS object configuration code and the business code of the first application to obtain a static library of the first application; and a linking unit, used to link the static library of the first application and the static library of the OS kernel to obtain an executable file.

[0025] In combination with the second aspect, in certain implementations of the second aspect, the acquisition unit is further used to acquire the OS object configuration file of the second application and the business code of the second application; the conversion unit is further used to convert the OS object configuration file of the second application to obtain the second OS object configuration code; the compilation unit is further used to compile the second OS object configuration code and the business code of the second application to obtain the static library of the second application; wherein the linking unit is used to: link the static library of the first application, the static library of the second application and the static library of the OS kernel to obtain the executable file.

[0026] In combination with the second aspect, in certain implementations of the second aspect, the OS object configuration file of the first application includes a configuration file of the first OS object, the OS object configuration file of the second application includes a configuration file of the second OS object, and the first OS object initiates interaction with the second OS object, wherein the conversion unit is used to: configure a third OS object with the same name as the second OS object in the OS object configuration file of the first application and add a first attribute to the third OS object, the first attribute indicating that the third OS object is an external object; and add a second attribute to the second OS object in the OS object configuration file of the second application, the second attribute being used to indicate that the second OS object is an output object.

[0027] In combination with the second aspect, in certain implementations of the second aspect, the OS object configuration file of the first application includes configuration files of one or more OS objects, and the device also includes a registration unit, the conversion unit being used to: generate a control block CB corresponding to each OS object in the one or more OS objects; compile the pointer of the CB corresponding to each OS object into a pointer array, the pointer array constituting the configuration variables of the first application; the registration unit being used to: register the configuration variables of the first application in the OS kernel when the OS is started.

[0028] In combination with the second aspect, in some implementations of the second aspect, the identifier of each OS object is determined by the identifier of the first application and the identifier of each OS object within the first application.

[0029] In a third aspect, the present application provides a configuration device, comprising: a memory for storing a computer program; and a processor for executing the computer program stored in the memory, so that the device performs a configuration method as in any possible implementation of the first aspect.

[0030] In a fourth aspect, the present application provides an electronic device, which includes a configuration device as in any possible implementation of the second aspect or the third aspect.

[0031] In a fifth aspect, the present application provides a computer program product, which includes: a computer program code, which, when executed on a computer, enables the computer to execute the configuration method in any possible implementation of the first aspect.

[0032] It should be noted that the above-mentioned computer program code may be stored in whole or in part on a first storage medium, wherein the first storage medium may be packaged together with the processor or may be packaged separately from the processor.

[0033] In a sixth aspect, the present application provides a computer-readable medium, wherein the computer-readable medium stores instructions, and when the instructions are executed by a processor, the processor implements the configuration method in any possible implementation manner of the first aspect.

[0034] In a seventh aspect, the present application provides a chip, comprising a circuit, wherein the circuit is used to execute the configuration method in any possible implementation manner of the first aspect above. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 It is a schematic diagram of the CP development process.

[0036] Figure 2 It is a schematic diagram of the business component development process of App1 provided in an embodiment of the present application.

[0037] Figure 3 It is a schematic diagram of a pointer array of an OS object provided in an embodiment of the present application.

[0038] Figure 4 It is a schematic diagram of multiple component development processes provided in an embodiment of the present application.

[0039] Figure 5 It is a schematic diagram of the interaction of multiple components provided in an embodiment of the present application.

[0040] Figure 6 This is a schematic diagram of the pointer arrays of App1 and App2 provided in an embodiment of the present application being associated through declaration.

[0041] Figure 7 It is a schematic flowchart of the configuration method provided in an embodiment of the present application.

[0042] Figure 8 It is a schematic block diagram of a configuration device provided in an embodiment of the present application.

[0043] Fig. 9 It is a schematic block diagram of a configuration device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0044] The technical solution in the embodiment of the present application will be described below in conjunction with the drawings in the embodiment of the present application. In the description of the embodiment of the present application, unless otherwise specified, " / " means or, for example, A / B can mean A or B; "and / or" in this article is only a description of the association relationship of associated objects, indicating that there can be three relationships, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone.

[0045] In the embodiments of the present application, prefixes such as "first" and "second" are used only to distinguish different description objects, and have no limiting effect on the position, order, priority, quantity or content of the described objects. The use of prefixes such as ordinal numbers to distinguish description objects in the embodiments of the present application does not constitute a limitation on the described objects. For the statement of the described objects, please refer to the description in the context of the claims or embodiments, and no unnecessary limitation should be constituted due to the use of such prefixes. In addition, in the description of the present embodiment, unless otherwise specified, the meaning of "multiple" is two or more.

[0046] Figure 1 A schematic diagram of the CP development process is shown. In the original equipment manufacturer (OEM) software development model, there are generally scenarios where multiple suppliers develop. For example, the supplier of application (App) 1 needs to merge the OS object configuration file of App1 and the OS object configuration file of App2 provided by the supplier of App2 to obtain a merged OS configuration file. Through the merged OS configuration file, the OS dynamic configuration code os_cfg.c is generated in the kernel, and then the source code is compiled through os_cfg.c to obtain liboscfg.a. Liboscfg.a, App1.a compiled through the business code App1.c of App1, App2.a compiled through the business code App2.c of App2, and libos.a compiled through the OS kernel file are linked to obtain the executable file exec.elf.

[0047] In the above process, multiple suppliers need to merge OS object configuration files multiple times. The AUTOSAR configuration tool will generate a unified OS dynamic configuration code in the kernel based on the merged global OS configuration file, and compile the source code at the same time. Since multiple suppliers cannot develop in parallel, this will bring a lot of manpower communication costs and time costs.

[0048] The embodiment of the present application provides a configuration method and device, which can solve the problem that multiple suppliers cannot develop in parallel during the CP development process, and help improve the efficiency of developers. The configuration method allows multiple suppliers to develop in parallel, and the specific configuration of the OS kernel module and the OS object can be separated into independent components.

[0049] For example, Figure 2 A schematic diagram of the business component development process of App1 provided in an embodiment of the present application is shown.

[0050] App1's OS object configuration file App1_os.arxml and App1's business code App1.c can be combined into App1's business component. App1_os.arxml is the OS object configuration file used by App1. The AUTOSAR configuration tool can read, graphically display, modify, save, and convert App1_os.arxml into the corresponding compilable configuration code App1_os_cfg.c, etc. The compilable configuration code App1_os_cfg.c can be compiled by the compiler to obtain App1_os_cfg.c.obj. The compiler can compile App1.c to obtain App1.c.obj. The compiler can package App1_os_cfg.c.obj and App1.c.obj into a static library App1.a.

[0051] The above process of converting App1_os.arxml into App1_os_cfg.c.obj may be referred to as a conversion process, and the conversion process may be implemented in the AUTOSAR configuration tool.

[0052] The above process of compiling App1_os_cfg.c to obtain App1_os_cfg.c.obj, compiling App1.c to obtain App1.c.obj, and packaging App1_os_cfg.c.obj and App1.c.obj to obtain App1.a can be implemented in the compiler.

[0053] For example, Figure 3 A schematic diagram of a pointer array of an OS object provided in an embodiment of the present application is shown.

[0054] The AUTOSAR configuration tool can generate the corresponding control block (CB) according to the OS object to which App1_os.arxml belongs, which is abbreviated as CB in the code. The pointer of the CB of each type of OS object constitutes the pointer (PTR) array of each type of OS object. App1_os_cfg.c stores the pointer array of each type of OS object. For example, the task control block pointer data (task_CB_ptr_array), the event control block pointer data (event_CB_ptr_array) and the alarm control block pointer data (alarm_CB_ptr_array). App1_os_cfg.c stores a total global configuration variable App1_os_cfg_var, which connects the pointer data of each type of OS object in series. There is a pointer App1_os_cfg_ptr in App1_os_cfg.c pointing to App1_os_cfg_var. The application layer uses App1_os_cfg_var when registering configuration information with the kernel layer. App1 can use the OS object ID to operate it. The ID of the OS object in each business component can be composed of the ID of the business component and the ID of the OS object. The kernel layer can find the corresponding control block according to the configuration ID of the business component and the ID of the OS object, and operate it. For example, the ID of the business component is App1, and the ID of the OS object in App1 is task1. Then the final OS object ID can be composed of 32 bits, of which 0-23 bits can be used to store the ID of App1, and 24-31 bits can be used to store the ID of task1. The above App1 and task1 will be converted into numbers, and the ID of the OS object can be composed of the high bits of App1 and the low bits of task1, for example, App1<<24+task1.

[0055] For example, Figure 4 FIG. 1 is a schematic diagram showing a development process of multiple components provided in an embodiment of the present application, wherein the multiple components include App1, App2, and an OS kernel component. Figure 4 As shown, the multiple component development process includes:

[0056] (1) The compiler generates the OS kernel static library libos.a

[0057] The business components of the OS kernel include os_task.c, os_event.c and other codes. The compiler can compile os_task.c to obtain os_task.c.obj and compile os_event.c to obtain os_event.c.obj. The compiler can package os_task.c.obj, os_event.c.obj and others to obtain the OS kernel static library libos.a.

[0058] (2) The compiler can compile the compilable configuration code converted from the OS object configuration file of App1 and the business code of App1 to obtain a static library App1.a.

[0059] The above process (2) can refer to the above Figure 2 The development process shown will not be repeated here.

[0060] (3) The compiler can compile the compilable configuration code converted from the OS object configuration file of App2 and the business code of App2 to obtain the static library App2.a.

[0061] The development process of the business components of App2 can refer to the development process of the business components of App1, which will not be repeated here. The AUTOSAR configuration tool can read, graphically display, modify and save App2_os.arxml and convert it into the corresponding compilable configuration code App2_os_cfg.c, etc. The compilable configuration code App2_os_cfg.c can be compiled by the compiler to obtain App2_os_cfg.c.obj. The compiler can compile App2.c to obtain App2.c.obj. The compiler can package App2_os_cfg.c.obj and App2.c.obj into a static library App2.a.

[0062] App2_os_cfg.c may also include App2_os_cfg_ptr, which points to App2_os_cfg_var, which is obtained by concatenating pointer data of various types of OS objects in App2.

[0063] There is no actual order of precedence between the development processes (1), (2) and (3) above.

[0064] The above description is based on an example that the application layer includes a business component corresponding to App1 and a business component corresponding to App2, and the embodiment of the present application is not limited thereto. For example, the application layer may also include more or fewer business components.

[0065] (4) The compiler can link App1.a, App2.a and libos.a into the executable file exec.elf.

[0066] (5) During the OS startup phase, the execution of the above exec.elf will go through the boot phase and jump into the main() function. The main() function can be used to perform OS registration configuration.

[0067] For example, the main() function is as follows:

[0068] Void main(void)

[0069] {

[0070] OS_Configure(APP1,App1_os_cfg_ptr);

[0071] OS_Configure(APP2,App2_os_cfg_ptr);

[0072] StartOS();

[0073] }

[0074] An array is reserved in the OS kernel to store App1_os_cfg_ptr and App2_os_cfg_ptr. App1 and App2 can register their corresponding configuration information with the OS through the application programming interface (API).

[0075] Each business component can have its own OS object configuration file and assign it a unique configuration name. When two business components have interaction requirements, the provider of the OS object adds an export attribute to the OS object in its OS object configuration file to facilitate the export of the symbol corresponding to the OS object. The user of the OS object configures the same OS object name in its configuration file and adds an external (extern) attribute to it. This OS object is not an object of this business component, and its variable is modified with extern when generating code. Several static library compilations of business components and OS kernel components can be linked together through the same symbols.

[0076] Business components can register configuration information through the OS API and complete the initialization of system resources during the OS startup phase.

[0077] Figure 5The schematic diagram of the interaction of multiple components provided by the embodiment of the present application is shown. Take the application layer including App1 and App2 as an example. App1 includes OS object task_1 and App2 includes OS objects task3 and event3.

[0078] Task_1 in App1 needs to interact with task_3 in App2. Task_1 in App1 will send an event (set event3 to task3) to task_3 in App2. At this point, App1 can be the user and App2 can be the provider.

[0079] App2 will mark task3 and event3 with the export attribute. In App1, you can configure task3 and event3 with the same name and mark them as extern objects from App2.

[0080] During the configuration phase, the AUTOSAR configuration tool reads the OS object configuration file in the business component and generates compilable configuration code. Each OS object will generate a corresponding control block and be compiled into the corresponding control block pointer array. The index of the control block pointer array is the ID of the OS object. For OS objects marked with the extern attribute, you do not need to generate the corresponding control block, but only generate the extern declaration of the control block. Figure 5 As shown, task1 in App1 will generate a control block task1_CB and fill its members. Task3 in App1 will generate an external declaration of the control block extern task3_CB. The control block addresses of task1 and task3 in App1 will be compiled into task_CB_ptr_array and used by App1.

[0081] For example, Figure 6 The schematic diagram of the pointer arrays of App1 and App2 provided by the embodiment of the present application through declaration association is shown. It can be seen that the external declaration extern task3_CB in App1 is associated with task3_CB in App2. The external declaration extern event3_CB in App1 is associated with event3_CB in App2.

[0082] The export attribute and the extern attribute can be used to implement the interaction between multiple business components without the need to implement the interaction between multiple business components through API parameters, which helps to reduce the learning and development difficulty for developers.

[0083] After App1.a and App2.a are linked (or compiled and linked), the corresponding variable names will be converted into specific memory addresses. For example, during the compilation process, the CB variable task1_CB can be converted into a memory address (for example, 0x00001010).

[0084] In the non-AUTOSAR field, embedded OS generally provides APIs for dynamically creating various OS objects, and OS objects are created through APIs. Since OS objects are created at runtime, it is uncertain how many OS objects there are in the system, and a memory management module is required to support dynamic memory application for storing OS objects. Moreover, the complex relationship between OS objects also needs to be implemented by passing in API parameters. Compared with AUTOSAR, which has tool interface configuration, it greatly increases the learning and development difficulty for developers. At the same time, there is a certain degree of uncertainty in the memory management module, and dynamic memory allocation (malloc) may fail to cause system abnormalities, which conflicts with the AUTOSAR concept.

[0085] In an embodiment of the present application, in the process of converting App1_os.arxml into App1_os_cfg.c, a static global variable CB can be generated for each OS object, and memory can be pre-allocated for each CB; in the compilation stage of linking the static library into an executable file, the memory location corresponding to each OS object can be determined.

[0086] In this way, a static global variable CB is generated through the OS object, and memory can be allocated for CB during the compilation phase, thereby solving the problem of memory uncertainty.

[0087] Figure 7 A schematic flow chart of a configuration method 700 provided in an embodiment of the present application is shown. The method 700 may be executed by an electronic device, or the method 700 may be executed by a processor, circuit or chip of the electronic device, and the method 700 includes:

[0088] S710: Obtain an operating system OS object configuration file of a first application and a service code of the first application.

[0089] Exemplarily, the OS object configuration file of the first application may be the above-mentioned App1_os.arxml.

[0090] Exemplarily, the business code of the first application may be the above-mentioned App1.c.

[0091] The OS object configuration file of the first application and the service code of the first application may be released by a supplier and obtained by the car manufacturer. Different suppliers may release the OS object configuration files and service codes of their applications in parallel, thereby solving the problem of parallel development of AUTOSAR CP.

[0092] S720: Convert the OS object configuration file of the first application to obtain a first OS object configuration code.

[0093] Optionally, the OS object configuration file of the first application is converted to obtain a first OS object configuration code, including: reading, graphically displaying, modifying and saving the OS object configuration file of the first application and converting it into the first OS object configuration code.

[0094] Exemplarily, the first OS object configuration code may be the above-mentioned App1_os_cfg.c.

[0095] The above process of converting the OS object configuration file can be implemented in the AUTOSAR configuration tool.

[0096] S730: Compile the first OS object configuration code and the business code of the first application to obtain a static library of the first application.

[0097] The static library of the first application program may be App1.a.

[0098] Optionally, the first OS object configuration code (e.g., App1_os_cfg.c) and the business code of the first application (e.g., App1.c) are compiled to obtain a static library of the first application (e.g., App1.a), including: compiling the first OS object configuration code to obtain a third OS object configuration code (e.g., App1_os_cfg.c.obj) and compiling the business code of the first application to obtain another business code (e.g., App1.c.obj); packaging the third OS object configuration code and the another business code to obtain a static library of the first application.

[0099] The compiling of the first OS object configuration code and the business code of the first application includes: compiling the first OS object configuration code and the business code of the first application by a compiler.

[0100] S740: Link the static library of the first application program and the static library of the OS kernel to obtain an executable file.

[0101] Exemplarily, the executable file may be the above-mentioned exec.elf.

[0102] The above linking of the static library of the first application program and the static library of the OS kernel includes: linking the static library of the first application program and the static library of the OS kernel through a compiler.

[0103] Optionally, the method 700 also includes: obtaining an OS object configuration file of a second application and a business code of the second application; converting the OS object configuration file of the second application to obtain a second OS object configuration code; compiling the second OS object configuration code and the business code of the second application to obtain a static library of the second application; wherein, linking the static library of the first application and the static library of the OS kernel to obtain an executable file includes: linking the static library of the first application, the static library of the second application and the static library of the OS kernel to obtain the executable file.

[0104] Exemplarily, the OS object configuration file of the second application may be the above-mentioned App2_os.arxml.

[0105] Exemplarily, the business code of the second application may be the above-mentioned App2.c.

[0106] Exemplarily, the second OS object configuration code may be the above-mentioned App2_os_cfg.c.

[0107] Optionally, the second OS object configuration code (e.g., App2_os_cfg.c) and the business code of the second application (e.g., App2.c) are compiled to obtain a static library of the second application (e.g., App2.a), including: compiling the second OS object configuration code to obtain a fourth OS object configuration code (e.g., App2_os_cfg.c.obj) and compiling the business code of the second application to obtain another business code (e.g., App2.c.obj); and packaging the fourth OS object configuration code and the another business code to obtain a static library of the second application.

[0108] Optionally, the OS object configuration file of the first application includes a configuration file of the first OS object, and the OS object configuration file of the second application includes a configuration file of the second OS object, and the first OS object initiates interaction with the second OS object, wherein the OS object configuration file of the first application is transformed to obtain a first OS object configuration code, including: configuring a third OS object with the same name as the second OS object in the OS object configuration file of the first application and adding a first attribute to the third OS object, the first attribute indicating that the third OS object is an external object; and transforming the OS object configuration file of the second application to obtain a second OS object configuration code, including: adding a second attribute to the second OS object in the OS object configuration file of the second application, the second attribute being used to indicate that the second OS object is an output object.

[0109] Exemplarily, the first application may be the above Figure 5 App1 in the example, the second application may be the above Figure 5 App2 in the above. The first OS object can be task1 in the above App1, and the second OS object can be task3 in the above App2. task_1 in App1 needs to interact with task_3 in App2. task_1 in App1 will send an event (set event3 to task3) to task_3 in App2. At this time, App1 can be the user and App2 can be the provider. App2 will mark task3 and event3 with the export attribute. In App1, task3 and event3 with the same name can be configured and marked as extern objects from App2.

[0110] Optionally, the OS object configuration file of the first application includes configuration files of one or more OS objects, and the OS object configuration file of the first application is transformed to obtain a first OS object configuration code, including: for each OS object in the one or more OS objects, generating a control block CB corresponding to each OS object; encoding the pointer of the CB corresponding to each OS object into a pointer array, and the pointer array constitutes the configuration variables of the first application; wherein, the method 700 also includes: when the OS is started, registering the configuration variables of the first application in the OS kernel.

[0111] Exemplarily, the configuration variable of the first application may be App1_os_cfg_var, and there is a pointer App1_os_cfg_ptr pointing to App1_os_cfg_var in App1_os_cfg.c.

[0112] Exemplarily, during the OS startup phase, the process of executing the above exec.elf will go through the boot phase and jump into the main() function. The main() function can be used to perform OS registration configuration. An array is reserved in the OS kernel to store App1_os_cfg_ptr and App2_os_cfg_ptr. App1 and App2 can register their corresponding configuration information with the OS through the API respectively, and the configuration information includes information for indicating the configuration variable.

[0113] Optionally, the identification of each OS object is determined by the identification of the first application and the identification of each OS object within the first application.

[0114] Exemplarily, the ID of the business component is App1, the ID of the OS object is task1, and the OS object ID may consist of 32 bits, wherein bits 0-23 may be used to store the ID of App1, and bits 24-31 may be used to store the ID of task1.

[0115] Figure 8 A schematic block diagram of a configuration device 800 provided in an embodiment of the present application is shown. The device 800 includes: an acquisition unit 810, used to acquire an operating system OS object configuration file of a first application and a business code of the first application; a conversion unit 820, used to convert the OS object configuration file of the first application to obtain a first OS object configuration code; a compilation unit 830, used to compile the first OS object configuration code and the business code of the first application to obtain a static library of the first application; and a linking unit 840, used to link the static library of the first application with the static library of the OS kernel to obtain an executable file.

[0116] Optionally, the acquisition unit 810 is also used to obtain the OS object configuration file of the second application and the business code of the second application; the conversion unit 820 is also used to convert the OS object configuration file of the second application to obtain the second OS object configuration code; the compilation unit 830 is also used to compile the second OS object configuration code and the business code of the second application to obtain the static library of the second application; wherein the linking unit 840 is used to: link the static library of the first application, the static library of the second application and the static library of the OS kernel to obtain the executable file.

[0117] Optionally, the OS object configuration file of the first application includes a configuration file of the first OS object, and the OS object configuration file of the second application includes a configuration file of the second OS object, and the first OS object initiates interaction with the second OS object, wherein the conversion unit 820 is used to: configure a third OS object with the same name as the second OS object in the OS object configuration file of the first application and add a first attribute to the third OS object, the first attribute indicating that the third OS object is an external object; and add a second attribute to the second OS object in the OS object configuration file of the second application, the second attribute being used to indicate that the second OS object is an output object.

[0118] Optionally, the OS object configuration file of the first application includes configuration files of one or more OS objects, and the device also includes a registration unit, the conversion unit 820, is used to: generate a control block CB corresponding to each OS object in the one or more OS objects; compile the pointer of the CB corresponding to each OS object into a pointer array, and the pointer array constitutes the configuration variables of the first application; the registration unit is used to: register the configuration variables of the first application in the OS kernel when the OS is started.

[0119] Optionally, the identification of each OS object is determined by the identification of the first application and the identification of each OS object within the first application.

[0120] It should be understood that the division of the units in the above device is only a division of logical functions, and in actual implementation, they can be fully or partially integrated into one physical entity, or they can be physically separated.

[0121] Fig. 9 It is a schematic block diagram of the configuration device 900 provided in an embodiment of the present application. Fig. 9 The configuration device 900 shown may include: a processor 910, a transceiver 920, and a memory 930. The processor 910, the transceiver 920, and the memory 930 are connected via an internal connection path, the memory 930 is used to store instructions, the processor 910 is used to execute the instructions stored in the memory 930, and the transceiver 920 receives / sends data. Optionally, the memory 930 may be coupled to the processor 910 via an interface, or may be integrated with the processor 910.

[0122] It should be noted that the transceiver 920 may include but is not limited to a transceiver device such as an input / output interface to achieve communication between the device 900 and other devices or a communication network.

[0123] The memory 930 may be a read-only memory (ROM), a static storage device, a dynamic storage device or a random access memory (RAM).

[0124] In one implementation, the processor 910 may be a circuit with the ability to read and execute instructions, such as a central processing unit (CPU), a microprocessor or a digital signal processor (DSP); in another implementation, the processor 910 may implement certain functions through the logical relationship of a hardware circuit, and the logical relationship of the hardware circuit is fixed or reconfigurable, for example, the processor 910 may be a hardware circuit implemented by an application-specific integrated circuit (ASIC) or a programmable logic device (PLD), such as a field programmable gate array (FPGA). In a reconfigurable hardware circuit, the process of the processor loading a configuration document to implement the hardware circuit configuration can be understood as the process of the processor loading instructions to implement the functions of some or all of the above units.

[0125] An embodiment of the present application further provides an electronic device, which may include the above-mentioned configuration device 800, or the above-mentioned configuration device 900.

[0126] The embodiment of the present application further provides a computer program product, which includes: a computer program code, and when the computer program code is executed on a computer, the computer executes the method in the above embodiment.

[0127] The embodiment of the present application further provides a computer-readable medium, wherein the computer-readable medium stores a program code. When the computer program code runs on a computer, the computer executes the method in the above embodiment.

[0128] An embodiment of the present application also provides a chip, including a circuit, for executing the method in the above embodiment.

[0129] In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in a processor or an instruction in the form of software. The method disclosed in conjunction with the embodiment of the present application can be directly embodied as a hardware processor for execution, or a combination of hardware and software modules in a processor for execution. The software module can be located in a storage medium mature in the art such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or a power-on erasable programmable memory, a register, etc. The storage medium is located in a memory, and the processor reads the information in the memory and completes the steps of the above method in conjunction with its hardware. To avoid repetition, it is not described in detail here.

[0130] It should also be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0131] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0132] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0133] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0134] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0135] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as USB flash drives, mobile hard drives, ROM, RAM, magnetic disks, or optical disks.

[0136] The above description is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be covered.

Claims

1. A configuration method, characterized in that: include: Obtaining an operating system OS object configuration file of a first application and a service code of the first application; Converting the OS object configuration file of the first application to obtain a first OS object configuration code; Compiling the first OS object configuration code and the business code of the first application to obtain a static library of the first application; The static library of the first application program and the static library of the OS kernel are linked to obtain an executable file.

2. The method according to claim 1, characterized in that The method further comprises: Obtaining an OS object configuration file of a second application and a service code of the second application; converting the OS object configuration file of the second application to obtain a second OS object configuration code; Compiling the second OS object configuration code and the business code of the second application to obtain a static library of the second application; The linking of the static library of the first application and the static library of the OS kernel to obtain an executable file includes: The static library of the first application, the static library of the second application, and the static library of the OS kernel are linked to obtain the executable file.

3. The method according to claim 2, characterized in that The OS object configuration file of the first application includes a configuration file of a first OS object, the OS object configuration file of the second application includes a configuration file of a second OS object, the first OS object initiates interaction with the second OS object, The converting of the OS object configuration file of the first application to obtain the first OS object configuration code includes: configuring a third OS object having the same name as the second OS object in the OS object configuration file of the first application and adding a first attribute to the third OS object, wherein the first attribute indicates that the third OS object is an external object; The converting the OS object configuration file of the second application to obtain the second OS object configuration code includes: A second attribute is added to the second OS object in the OS object configuration file of the second application, where the second attribute is used to indicate that the second OS object is an output object.

4. The method according to any one of claims 1 to 3, characterized in that The OS object configuration file of the first application includes one or more OS object configuration files, and the converting the OS object configuration file of the first application to obtain the first OS object configuration code includes: For each OS object among the one or more OS objects, generating a control block CB corresponding to each OS object; Compiling the pointer of the CB corresponding to each OS object into a pointer array, wherein the pointer array constitutes the configuration variables of the first application; Wherein, the method further comprises: When the OS is started, the configuration variables of the first application are registered in the OS kernel.

5. The method according to claim 4, characterized in that The identification of each OS object is determined by the identification of the first application and the identification of each OS object within the first application.

6. A configuration device, characterized in that: include: An acquisition unit, configured to acquire an operating system OS object configuration file of a first application and a service code of the first application; a conversion unit, configured to convert the OS object configuration file of the first application to obtain a first OS object configuration code; A compiling unit, configured to compile the first OS object configuration code and the business code of the first application to obtain a static library of the first application; The linking unit is used to link the static library of the first application program and the static library of the OS kernel to obtain an executable file.

7. The device according to claim 6, characterized in that The acquisition unit is further configured to acquire an OS object configuration file of a second application and a service code of the second application; The conversion unit is further used to convert the OS object configuration file of the second application to obtain a second OS object configuration code; The compiling unit is further used to compile the second OS object configuration code and the business code of the second application to obtain a static library of the second application; The linking unit is used to link the static library of the first application, the static library of the second application and the static library of the OS kernel to obtain the executable file.

8. The device according to claim 7, characterized in that The OS object configuration file of the first application includes a configuration file of a first OS object, the OS object configuration file of the second application includes a configuration file of a second OS object, the first OS object initiates interaction with the second OS object, Wherein, the conversion unit is used for: configuring a third OS object having the same name as the second OS object in the OS object configuration file of the first application and adding a first attribute to the third OS object, wherein the first attribute indicates that the third OS object is an external object; A second attribute is added to the second OS object in the OS object configuration file of the second application, where the second attribute is used to indicate that the second OS object is an output object.

9. The device according to any one of claims 6 to 8, characterized in that The OS object configuration file of the first application includes one or more OS object configuration files, and the device further includes a registration unit. The conversion unit is used to: generate a control block CB corresponding to each OS object in the one or more OS objects; Compiling the pointer of the CB corresponding to each OS object into a pointer array, wherein the pointer array constitutes the configuration variables of the first application; The registration unit is used to register the configuration variables of the first application in the OS kernel when the OS is started.

10. The device according to claim 9, characterized in that The identification of each OS object is determined by the identification of the first application and the identification of each OS object within the first application.

11. A configuration device, characterized in that: include: Memory for storing computer programs; A processor, configured to execute the computer program stored in the memory, so that the apparatus performs the configuration method according to any one of claims 1 to 5.

12. An electronic device, characterized in that: Comprising a configuration device as claimed in any one of claims 6 to 11.

13. A computer-readable storage medium, characterized in that: Instructions are stored thereon, and when the instructions are executed by a processor, the processor implements the configuration method according to any one of claims 1 to 5.

14. A chip, characterized in that: The chip comprises a circuit for executing the configuration method according to any one of claims 1 to 5.

15. A computer program product, characterized in that The computer program product comprises: a computer program code, and when the computer program code is run on a computer, the computer is enabled to execute the configuration method according to any one of claims 1 to 5.

Images