Configuration method and apparatus

Abstract

The present application provides a configuration method and apparatus, which can be applied to the field of intelligent vehicles. The method comprises: 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 a static library of an operating system kernel to obtain an executable file. Embodiments of the present application can be applied to the development process of intelligent vehicles or electric vehicles, and there is no need for a plurality of suppliers to combine operating system object configuration files, helping to improve the efficiency of developers, and saving communication costs and time costs associated with human labor in the development period.

Description

Configuration method and device

[0001] This application claims priority to the Chinese patent application with application number 202311337230.2 filed with the State Intellectual Property Office of China on October 16, 2023, and priority to the Chinese patent application with the invention name “Configuration Method and Device”, all contents of which are incorporated by reference into this application. Technical Field

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

[0003] Currently, automotive electronic networks are evolving towards multi-bus hybrid interconnections. In 2003, to mitigate compatibility issues among major manufacturers, the automotive industry introduced the open, standardized Automotive Open System Architecture (AUTOSAR) specification. Automakers can develop their own software based on this standard.

[0004] During the development of the traditional automotive embedded system software architecture (classic AUTOSAR, CP), multiple suppliers need to repeatedly merge operating system (OS) object configuration files, generate unified OS dynamic configuration code in the kernel, and simultaneously compile the source code, resulting in significant communication and time costs.

[0005] Summary of the Invention

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

[0007] In a first aspect, a configuration method is provided, which includes: 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 and the static library of the OS kernel to obtain an executable file.

[0008] Based on this technical solution, the application's OS object configuration file is converted to the OS object configuration code, which is then compiled with the application's business code to create the application's static library. This eliminates the need to merge OS object configuration files from multiple vendors, improving developer efficiency and reducing communication and time costs during development.

[0009] 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 application configuration is combined with the business code and released separately. This can solve the problem of parallel development of AUTOSAR CP, decouple the modules, and each component can release a binary component separately.

[0010] 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 using an AUTOSAR configuration tool.

[0011] 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.

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

[0013] In some possible implementations, compiling the first OS object configuration code (e.g., App1_os_cfg.c) and the business code of the first application (e.g., App1.c) to obtain a static library of the first application (e.g., App1.a) includes: 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); and packaging the third OS object configuration code and the another business code to obtain a static library of the first application.

[0014] In combination with the first aspect, in certain implementations of the first aspect, the method further 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.

[0015] Based on the above technical solution, the OS can support multiple applications, which can be provided by different vendors. Different vendors can concurrently release the OS object configuration files and service code used to configure the applications. When generating the executable file, only the static libraries of the different applications need to be linked with the static libraries of the OS kernel. This eliminates the need to merge OS object configuration files from multiple vendors, helping to improve developer efficiency and saving on communication and time costs during development.

[0016] 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.

[0017] Based on the above technical solution, when OS objects in different applications interact, a user can operate on a provider's OS object by configuring an OS object with the same name and marking it with the "extern" attribute. The provider can then mark the corresponding OS object with the "export" attribute, enabling interaction between OS objects in different applications. This eliminates the need for complex API parameters to achieve OS object interaction, reducing development effort and improving developer efficiency.

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

[0019] 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.

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

[0021] 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: generating a control block CB corresponding to each OS object in the one or more OS objects; 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: registering the configuration variables of the first application in the OS kernel when the OS is started.

[0022] Based on the above technical solution, the OS can support multiple applications. Each application calls the 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.

[0023] In some possible implementations, the OS object configuration file of the first application includes configuration files of multiple types of OS objects (for example, tasks, events, and alarms), each type of OS object includes multiple OS objects under that type, the pointer of each OS object under 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.

[0024] 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.

[0025] Based on the above technical solution, the identity of each OS object can be determined by the application's identity and the OS object's identity within the application. This allows an application's configuration to have a globally unique configuration name that forms the prefix of its OS object namespace, avoiding code conflicts with other applications' OS object configurations.

[0026] In the second aspect, the present application provides a configuration device, which includes: an acquisition unit for acquiring an operating system OS object configuration file of a first application and a business code of the first application; a conversion unit for converting the OS object configuration file of the first application to obtain a first OS object configuration code; a compilation unit for 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 a linking unit for linking the static library of the first application and the static library of the OS kernel to obtain an executable file.

[0027] In combination with the second aspect, in certain implementations of the second aspect, the acquisition unit is further used to obtain 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.

[0028] 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.

[0029] 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 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.

[0030] 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.

[0031] In a third aspect, the present application provides a configuration device, which includes: 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.

[0032] 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.

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

[0034] 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 separately from the processor.

[0035] In a sixth aspect, the present application provides a computer-readable medium, which stores instructions. When the instructions are executed by a processor, the processor implements the configuration method in any possible implementation of the first aspect.

[0036] In a seventh aspect, the present application provides a chip, which includes a circuit for executing the configuration method in any possible implementation of the first aspect above. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0038] FIG2 is a schematic diagram of the business component development process of App1 provided in an embodiment of the present application.

[0039] FIG3 is a schematic diagram of a pointer array of an OS object provided in an embodiment of the present application.

[0040] FIG4 is a schematic diagram of a plurality of component development processes provided in an embodiment of the present application.

[0041] FIG5 is a schematic diagram of the interaction of multiple components provided in an embodiment of the present application.

[0042] FIG6 is a schematic diagram showing the association of the pointer arrays of App1 and App2 through declarations provided in an embodiment of the present application.

[0043] FIG7 is a schematic flowchart of the configuration method provided in an embodiment of the present application.

[0044] FIG8 is a schematic block diagram of a configuration device provided in an embodiment of the present application.

[0045] FIG9 is a schematic block diagram of a configuration device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0046] The following describes the technical solutions in the embodiments of the present application in conjunction with the accompanying drawings. In the description of the embodiments of the present application, unless otherwise specified, " / " represents "or." For example, A / B can represent A or B. "And / or" in this document is merely a description of the association relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, or B exists alone.

[0047] 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 restriction 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 the use of such prefixes should not constitute an unnecessary restriction. In addition, in the description of this embodiment, unless otherwise specified, the meaning of "plurality" is two or more.

[0048] Figure 1 shows a schematic diagram of the CP development process. In the original equipment manufacturer (OEM) software development model, there are common 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 App1's business code App1.c, App2.a compiled through App2's business code App2.c, and libos.a compiled through the OS kernel file are linked to obtain the executable file exec.elf.

[0049] The above process requires multiple suppliers to merge OS object configuration files multiple times. The AUTOSAR configuration tool generates unified OS dynamic configuration code in the kernel based on the merged global OS configuration file and simultaneously compiles the source code. Because multiple suppliers cannot develop in parallel, this results in significant communication and time costs.

[0050] The present invention provides a configuration method and apparatus that can address the issue of multiple vendors being unable to develop concurrently during CP development, thereby improving developer efficiency. This configuration method allows multiple vendors to develop concurrently, and the specific configuration of OS kernel modules and OS objects can be separated into independent components.

[0051] For example, FIG2 shows a schematic diagram of the business component development process of App1 provided in an embodiment of the present application.

[0052] App1's OS object configuration file, App1_os.arxml, and App1's business code, App1.c, can be combined to form App1's business components. App1_os.arxml is the OS object configuration file used by App1. The AUTOSAR configuration tool can read, graphically display, modify, and save App1_os.arxml, converting it into the corresponding compilable configuration code, such as App1_os_cfg.c. Compiled by the compiler, App1_os_cfg.c generates App1_os_cfg.c.obj. The compiler compiles App1.c to generate App1.c.obj. The compiler then packages App1_os_cfg.c.obj and App1.c.obj into the static library App1.a.

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

[0054] 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.

[0055] Exemplarily, FIG3 shows a schematic diagram of a pointer array of an OS object provided in an embodiment of the present application.

[0056] The AUTOSAR configuration tool generates corresponding control blocks (CBs), abbreviated as CBs in the code, based on the OS objects associated with App1_os.arxml. The CB pointers for each OS object type form an array of pointers (PTRs) for each OS object type. App1_os_cfg.c stores arrays of pointers to each OS object type. For example, arrays of pointers to the task control block (task_CB_ptr_array), the event control block (event_CB_ptr_array), and the alarm control block (alarm_CB_ptr_array) are stored in App1_os_cfg.c. App1_os_cfg_var, a global configuration variable, is stored in App1_os_cfg.c. This variable concatenates the pointers to each OS object type. App1_os_cfg_var is a pointer in App1_os_cfg.c that points to App1_os_cfg_ptr. The application layer uses App1_os_cfg_var when registering configuration information with the kernel. App1 can use the OS object ID to operate on it. The ID of the OS object in each business component can be composed of the business component ID and the OS object ID. The kernel layer can find the corresponding control block based on the business component configuration ID and the OS object ID and operate on it. For example, the business component ID is App1, and the OS object ID 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 App1 ID, and 24-31 bits can be used to store the task1 ID. The above App1 and task1 will be converted into numbers, and the OS object ID can be composed of the high bit of App1 and the low bit of task1, for example, App1<<24+task1.

[0057] For example, FIG4 shows a schematic diagram of a multiple component development process provided by an embodiment of the present application, wherein the multiple components include App1, App2, and an OS kernel component. As shown in FIG4 , the multiple component development process includes:

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

[0059] The OS kernel's business components include os_task.c, os_event.c, and other code. The compiler compiles os_task.c to generate os_task.c.obj and os_event.c to generate os_event.c.obj. The compiler then packages os_task.c.obj, os_event.c.obj, and other code to generate the OS kernel static library libos.a.

[0060] (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 the static library App1.a.

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

[0062] (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.

[0063] The development process for App2's business components can be referenced for the development process for App1 and will not be repeated here. The AUTOSAR configuration tool can read, graphically display, modify, and save App2_os.arxml, converting it into the corresponding compilable configuration code, such as App2_os_cfg.c. The compiler compiles App2_os_cfg.c to generate App2_os_cfg.c.obj. The compiler then compiles App2.c to generate App2.c.obj. The compiler then packages App2_os_cfg.c.obj and App2.c.obj into the static library App2.a.

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

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

[0066] The above description is based on an example in which the application layer includes business components corresponding to App1 and business components corresponding to App2, but the present application embodiment is not limited thereto. For example, the application layer may also include more or fewer business components.

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

[0068] (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.

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

[0070] Void main(void)

[0071] {

[0072] OS_Configure(APP1,App1_os_cfg_ptr);

[0073] OS_Configure(APP2,App2_os_cfg_ptr);

[0074] StartOS();

[0075] }

[0076] The OS kernel reserves an array 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).

[0077] Each business component can have its own OS object configuration file and assign it a unique configuration name. When two business components have interaction needs, the provider of the OS object adds the 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 OS object name with the same name in its configuration file and adds the external (extern) attribute to it. This OS object is not the 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 symbol.

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

[0079] Figure 5 shows a schematic diagram of the interaction of multiple components provided by an embodiment of the present application. Taking the application layer including App1 and App2 as an example, App1 includes the OS object task_1 and App2 includes the OS objects task3 and event3.

[0080] Task_1 in App1 needs to interact with task_3 in App2. Task_1 in App1 sends an event (set event3 to task3) to task_3 in App2. In this case, App1 can act as the consumer and App2 can act as the provider.

[0081] 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.

[0082] During the configuration phase, the AUTOSAR configuration tool reads the OS object configuration files in the business components and generates compilable configuration code. Each OS object generates a corresponding control block, which is then encoded into the corresponding control block pointer array. The index of the control block pointer array is the OS object ID. For OS objects marked with the extern attribute, the corresponding control block can be omitted; only the extern declaration of the control block is generated. As shown in Figure 5, task1 in App1 generates the control block task1_CB and populates its members. Task3 in App1 generates the external declaration of the control block extern task3_CB. The control block addresses of task1 and task3 in App1 are encoded into task_CB_ptr_array and used by App1.

[0083] For example, Figure 6 shows a schematic diagram of the pointer arrays of App1 and App2, provided in an embodiment of the present application, associated through declarations. As can be seen, 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.

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

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

[0086] In non-AUTOSAR environments, embedded operating systems generally provide APIs for dynamically creating various OS objects. These APIs are used to create OS objects. Because OS objects are created at runtime, the number of OS objects in the system is uncertain. Therefore, a memory management module is required to support dynamic memory allocation for storing OS objects. Furthermore, the complex relationships between OS objects require API parameters to implement. Compared to AUTOSAR, which requires tool interface configuration, this significantly increases the learning and development complexity for developers. Furthermore, the memory management module has a certain degree of uncertainty, and dynamic memory allocation (malloc) failures can lead to system anomalies, which conflicts with the AUTOSAR philosophy.

[0087] 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.

[0088] 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.

[0089] FIG7 shows a schematic flow chart of a configuration method 700 provided in an embodiment of the present application. The method 700 may be executed by an electronic device, or may be executed by a processor, circuit, or chip of the electronic device. The method 700 includes:

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

[0091] Exemplarily, the OS object configuration file of the first application may be the aforementioned App1_os.arxml.

[0092] Exemplarily, the business code of the first application may be the aforementioned App1.c.

[0093] The OS object configuration file and the service code of the first application can be released by the supplier and obtained by the OEM. Different suppliers can release their application OS object configuration files and service codes in parallel, thus solving the problem of parallel development of AUTOSAR CP.

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

[0095] Optionally, converting the OS object configuration file of the first application to obtain the first OS object configuration code includes: 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.

[0096] Exemplarily, the first OS object configuration code may be the aforementioned App1_os_cfg.c.

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

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

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

[0100] Optionally, compiling the first OS object configuration code (e.g., App1_os_cfg.c) and the business code of the first application (e.g., App1.c) to obtain a static library of the first application (e.g., App1.a) includes: 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); and packaging the third OS object configuration code and the another business code to obtain a static library of the first application.

[0101] 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.

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

[0103] Exemplarily, the executable file may be the aforementioned exec.elf.

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

[0105] 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.

[0106] Exemplarily, the OS object configuration file of the second application may be the aforementioned App2_os.arxml.

[0107] Exemplarily, the business code of the second application may be the aforementioned App2.c.

[0108] Exemplarily, the second OS object configuration code may be the aforementioned App2_os_cfg.c.

[0109] 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.

[0110] Optionally, 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 converted 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 converting 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.

[0111] Exemplarily, the first application may be App1 in FIG5 , and the second application may be App2 in FIG5 . The first OS object may be task1 in App1, and the second OS object may be task3 in 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 act as the user, and App2 can act as 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.

[0112] 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 converted to obtain a first OS object configuration code, including: generating a control block CB corresponding to each OS object in the one or more OS objects; 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: registering the configuration variables of the first application in the OS kernel when the OS is started.

[0113] Exemplarily, the configuration variable of the first application may be App1_os_cfg_var, and App1_os_cfg.c includes a pointer App1_os_cfg_ptr pointing to App1_os_cfg_var.

[0114] For example, during the OS startup phase, the execution of the exec.elf function passes through the boot phase and jumps to the main() function. The main() function can be used to perform OS registration and configuration. The OS kernel reserves an array to store App1_os_cfg_ptr and App2_os_cfg_ptr. App1 and App2 can each register their corresponding configuration information with the OS through an API, including information indicating the configuration variables.

[0115] Optionally, 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.

[0116] For example, 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.

[0117] Figure 8 shows a schematic block diagram of a configuration device 800 provided in an embodiment of the present application. The device 800 includes: an acquisition unit 810 for acquiring an operating system (OS) object configuration file of a first application and the service code of the first application; a conversion unit 820 for converting the OS object configuration file of the first application to obtain a first OS object configuration code; a compilation unit 830 for compiling the first OS object configuration code and the service code of the first application to obtain a static library of the first application; and a linking unit 840 for linking the static library of the first application with the static library of the OS kernel to obtain an executable file.

[0118] 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.

[0119] 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.

[0120] 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.

[0121] Optionally, 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.

[0122] 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.

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

[0124] 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 implement communication between the device 900 and other devices or a communication network.

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

[0126] In one implementation, the processor 910 may be a circuit capable of reading and executing 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 relationships of a hardware circuit, where the logical relationships of the hardware circuit are 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 file 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.

[0127] 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.

[0128] An embodiment of the present application further provides a computer program product, which includes: computer program code, which enables the computer to execute the method in the above embodiment when the computer program code is run on a computer.

[0129] An 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.

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

[0131] During implementation, each step of the above method can be completed by an integrated logic circuit of the hardware in the processor or by instructions in the form of software. The method disclosed in conjunction with the embodiments of the present application can be directly embodied as being executed by a hardware processor, or can be executed by a combination of hardware and software modules in the processor. 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 the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware. To avoid repetition, it will not be described in detail here.

[0132] 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.

[0133] Those skilled in the art will 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.

[0134] In the several embodiments provided in this 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 merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, 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.

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

[0136] 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.

[0137] 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. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a ROM, a RAM, a magnetic disk, or an optical disk.

[0138] The above is only a specific implementation method of the present application, but the protection scope of the present application is not limited thereto. Any changes or replacements that can be easily thought of by any technician familiar with this technical field within the technical scope disclosed in this application 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 used 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