Multi-core cross-platform module calling method, system, device and storage medium
By defining the internal hierarchical structure of modules and function pointer structures, flexible calls between modules are enabled, solving the problem of difficult code maintenance in multi-core products and achieving cross-platform compatibility and cost savings.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- VERISILICON MICROELECTRONICS (CHENGDU) CO LTD
- Filing Date
- 2022-05-13
- Publication Date
- 2026-06-02
Smart Images

Figure CN117093262B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of software invocation technology, and in particular to multi-core cross-platform module invocation methods, systems, devices, and storage media. Background Technology
[0002] The market now offers a wide variety of products, such as security and automotive products, which need to support multiple operating systems. As a result, the chips used in these products have also diversified from single-core to multi-core. In order to support these features, multiple software programs or software branches are often required.
[0003] However, because products of the same type have similar application scenarios, a significant portion of their code or module logic is similar. To ensure compatibility with different operating systems or single-core / multi-core processors, multiple software versions or branches need to be maintained. This makes code version maintenance extremely difficult and increases costs dramatically, while also making the software itself lack flexibility. Summary of the Invention
[0004] In view of the shortcomings of the prior art described above, the purpose of this invention is to provide a method, system, device and storage medium for multi-core cross-platform module calling, which solves the problem that in order to be compatible with different operating systems or single-core / multi-core, multiple software or software branches need to be maintained, which makes code version maintenance very difficult, increases costs, and makes the software itself lack flexibility.
[0005] To achieve the above and other related objectives, a first aspect of the present invention provides a multi-core cross-platform module calling system, comprising: multiple functional modules, each functional module including an interconnected driver layer and an adapter layer; a platform module; and a system platform including each functional module and a function pointer structure of the platform module; the function pointer structures of the functional modules are connected to corresponding adapter layers; wherein the system platform calls each functional module in one or more of the following ways: registering the connection interface of the called functional module in the current functional module in the form of a callback function; calling the interface of the function pointer structure of the called functional module in the function pointer structure of the current functional module; assigning the driver layer interface of the called functional module to the function pointer structure of the platform module, so that the current functional module can call the driver layer interface of the called functional module from the function pointer structure of the platform module.
[0006] In some embodiments of the first aspect of the invention, a system abstraction layer is also included for calling functional modules located in different operating systems.
[0007] In some embodiments of the first aspect of the present invention, the operating system includes, but is not limited to, the Linux operating system and the FreeRTOS system.
[0008] To achieve the above and other related objectives, a second aspect of the present invention provides a multi-core cross-platform module invocation method applied to a system platform; the system platform includes various functional modules and function pointer structures of platform modules; the method includes: determining a current functional module and its corresponding called functional module; both the current functional module and the called functional module include interconnected driver layers and adaptation layers; invoking the called functional module to the current functional module through any one or more of the following invocation methods: registering the connection interface of the called functional module in the current functional module using a callback function; invoking the interface of the function pointer structure of the called functional module in the function pointer structure of the current functional module; assigning the driver layer interface of the called functional module to the function pointer structure of the platform module, so that the current functional module can invoke the driver layer interface of the called functional module from the function pointer structure of the platform module.
[0009] In some embodiments of the second aspect of the invention, the method further includes: calling functional modules located in different operating systems through a system abstraction layer.
[0010] In some embodiments of the second aspect of the present invention, the operating system includes, but is not limited to, the Linux operating system and the FreeRTOS system.
[0011] To achieve the above and other related objectives, a third aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the multi-core cross-platform module invocation method.
[0012] To achieve the above and other related objectives, a fourth aspect of the present invention provides a multi-core cross-platform module invocation device, comprising: a processor and a memory; the memory is used to store a computer program, and the processor is used to execute the computer program stored in the memory, so that the terminal executes the multi-core cross-platform module invocation method.
[0013] As described above, the multi-core cross-platform module calling method, system, device, and storage medium of the present invention have the following beneficial effects: The present invention defines the internal hierarchical structure of modules and the calling method between modules, and can flexibly configure the module connection order and combination method according to the application scenario, greatly increasing the code reusability; for diverse customer needs, such as different cores, different communication methods, and different operating system combinations, the maintenance cost of multiple software solutions will increase exponentially. The present invention only requires a software development kit (SDK), supports cross-platform features, and only needs to be customized at compile time according to the actual product (multi-core, inter-core communication method, operating system) to meet the requirements, greatly saving development and maintenance costs. Attached Figure Description
[0014] Figure 1 The diagram shown is a structural schematic of a multi-core cross-platform module calling system according to an embodiment of the present invention.
[0015] Figure 2 The diagram shown is an example of an application of calling the MailBox module in one embodiment of the present invention.
[0016] Figure 3 The diagram shown is a flowchart illustrating a multi-core cross-platform module calling method according to an embodiment of the present invention.
[0017] Figure 4 The diagram shown is a structural schematic of a multi-core cross-platform module calling device according to an embodiment of the present invention. Detailed Implementation
[0018] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that, unless otherwise specified, the following embodiments and features described therein can be combined with each other.
[0019] It should be noted that in the following description, reference is made to the accompanying drawings, which illustrate several embodiments of the present invention. It should be understood that other embodiments may also be used, and changes in mechanical composition, structure, electrical system, and operation may be made without departing from the spirit and scope of the invention. The following detailed description should not be considered limiting, and the scope of the embodiments of the invention is defined only by the claims of the published patents. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. Spatially related terms, such as “upper,” “lower,” “left,” “right,” “below,” “below,” “lower part,” “above,” “upper part,” etc., may be used herein to illustrate the relationship between one element or feature shown in the figures and another element or feature.
[0020] In this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," "linking," "fixing," and "holding" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.
[0021] Furthermore, as used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context indicates otherwise. The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data used can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising,” “including,” indicate the presence of the stated features, operations, elements, components, items, kinds, and / or groups, but do not exclude the presence, occurrence, or addition of one or more other features, operations, elements, components, items, kinds, and / or groups. It should be further understood that the terms “or” and “and / or” as used herein are interpreted as inclusive, or mean any one or any combination thereof. Thus, “A, B, or C” or “A, B, and / or C” means “any one of: A; B; C; A and B; A and C; B and C; A, B, and C.” An exception to this definition will only occur if the combination of elements, functions, or operations is inherently mutually exclusive in some way.
[0022] To address the aforementioned technical problems, this invention provides a cross-platform software design scheme based on multi-core processors. This scheme can be used in commonly available multi-core products on the market, effectively solving the problems of modular reuse of code logic, flexible module configuration, and support for different systems in multi-core products. This invention can significantly reduce software development and maintenance costs.
[0023] Before providing a further detailed description of the present invention, the nouns and terms used in the embodiments of the present invention are explained, and the nouns and terms used in the embodiments of the present invention are subject to the following interpretations:
[0024] <1> The Module Driver Layer provides module functionality API interfaces for applications to use, and calls the System Adaptation Layer (HAL Layer) to adapt to different platforms.
[0025] <2> The HAL Layer provides HAL API interfaces for use by the Driver Layer and calls Operation functions in the System Platform to implement specific functionalities.
[0026] <3> The function pointer structure (Operation) is used to define function interfaces that are closely related to modules and system platforms. There is one function pointer structure in each system platform layer.
[0027] <4> The platform module can be a standalone module or used to manage connections between modules. Applications initialize the system by calling the platform driver layer interface.
[0028] <5> The system platform implements the Operations interface of all other modules in the platform module, and completes the binding relationship between the HAL layer and the function pointer structure, as well as the binding relationship between modules.
[0029] <6> The System Abstraction Layer (OSAL) is used to encapsulate all operating system-related API interfaces for other modules to call.
[0030] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions in the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only for explaining the present invention and are not intended to limit the present invention.
[0031] like Figure 1 The diagram shown illustrates the structure of a multi-core cross-platform module calling system according to an embodiment of the present invention.
[0032] In this embodiment, the multi-core cross-platform module calling system includes three main parts: multiple functional modules, platform modules, and system platform. There is no direct connection between the functional modules and the system platform. The platform module is the bridge connecting the functional modules and the system platform. Some low-level interfaces used in the functional modules can be implemented by connecting the function pointer structure in the system platform through the platform module.
[0033] Specifically, in this embodiment, the functional modules are Module A and Module B. Each functional module has a driver layer and an adapter layer, respectively represented as Module A Driver Layer, Module A Adapter Layer, Module B Driver Layer, and Module B Adapter Layer. The platform module also has a driver layer and an adapter layer, respectively represented as Platform Module Driver Layer and Platform Module Adapter Layer. The system platform includes function pointer structures for the platform module, Module A, and Module B.
[0034] It should be noted that the functional modules described in this embodiment include any one or more of the following: communication and social networking functional modules, audio and video playback functional modules, online shopping functional modules, transaction and payment functional modules, travel navigation functional modules, financial management functional modules, tourism and accommodation functional modules, news reading functional modules, email and cloud storage functional modules, and photography and beautification functional modules, etc.
[0035] In this embodiment, there are three main ways to call between modules. In actual use, any one of the three calling methods can be selected, or multiple calling methods can be combined. This embodiment does not limit this. The following will explain the various calling methods accordingly.
[0036] Invocation method 1) Register the connection interface of the called functional module in the current functional module using a callback function, so as to Figure 1 Take the middle arrow ① as an example.
[0037] It's important to note that a function pointer is a pointer variable that points to a function. While a pointer variable typically points to an integer, character, or array, a function pointer points to a function. Function pointers can be used to call functions and pass parameters, just like regular functions. A callback function is a function called through a function pointer (i.e., a function that is called when another function is executed). For example, in C, callback functions can only be implemented using function pointers. In more modern programming languages like C++, Python, and ECMAScript, functors or anonymous functions can also be used. The use of callback functions can greatly improve programming efficiency, making them widely used in modern programming. Common callback function calls include the quicksort function `qsort` in the C / C++ standard library `stdlib.h / cstdlib` and the binary search function `bsearch`, both of which require a parameter similar to `strcmp` to set the data comparison method.
[0038] Method 2) Call the interface of the function pointer structure of the called functional module within the function pointer structure of the current functional module. For example, using arrow ② in the diagram: If module B wants to call module A, it can directly call the interface (Operation interface) of module A's function pointer structure within module B's function pointer structure.
[0039] In calling method 3), the driver layer interface of the called functional module is assigned to the function pointer structure of the platform module, allowing the current functional module to call the driver layer interface of the called functional module from the function pointer structure of the platform module. Figure 1 Taking arrow ③ as an example: the driver layer interface of the called functional module is assigned to the function pointer structure of the platform module. Module A or module B can then call the driver layer interface of the called functional module from the function pointer structure of the platform module, thereby enabling inter-module calls.
[0040] To facilitate understanding, we will now combine Figure 2 The MailBox is used as the called function module and is invoked through the invocation method 3) described above. An example is shown below:
[0041] First, add the MailBox module and implement the MailBox communication interface; the MailBox module has a driver layer and an adapter layer.
[0042] Secondly, the API (Application Programming Interface) of the MailBox module driver layer is assigned to the function pointer structure of the platform module;
[0043] Finally, by calling the function pointer structure of the platform module from the function pointer structure of module A, module A can call the MailBox module, thus enabling communication between module A and MailBox.
[0044] This example uses the MailBox module as an example only, but it is not limited to this. For those skilled in the art, referring to the technical solution of this invention, other required functional modules can be added according to the above process and method to implement the corresponding communication interface, and can be mounted to the function pointer structure of the platform module in the same way.
[0045] It is worth noting that cross-platform compatibility in this embodiment of the invention can be divided into two cases: one is system cross-platform compatibility, and the other is that the same code can flexibly support multi-core applications. The implementation principles of the two are similar, depending on whether the modules are within the same system. In system cross-platform applications, the same code can support different operating systems, such as FreeRTOS and Linux, through the System Abstraction Layer (OSAL layer).
[0046] like Figure 3 The diagram illustrates a flowchart of a multi-core cross-platform module invocation method according to an embodiment of the present invention. This multi-core cross-platform module invocation method is applied to the system platform of the aforementioned multi-core cross-platform module invocation system, and the method includes the following steps:
[0047] Step S31: Determine the current functional module and the corresponding called functional module; both the current functional module and the called functional module include a driver layer, an adaptation layer, and a function pointer structure set in the system platform; the system platform also has a function pointer structure for the platform module.
[0048] It should be noted that the current functional module and the called functional module can be various types of functional modules, such as email modules, social modules, calendar modules, audio and video modules, game modules, etc., and this embodiment does not limit them.
[0049] Step S32: Call the called functional module to the current functional module using any one or more of the following calling methods:
[0050] Register the connection interface of the called functional module in the current functional module using a callback function;
[0051] Call the interface of the function pointer structure of the called function module from the function pointer structure of the current function module;
[0052] The driver layer interface of the called functional module is assigned to the function pointer structure of the platform module, so that the current functional module can call the driver layer interface of the called functional module from the function pointer structure of the platform module.
[0053] The implementation method of this embodiment of a multi-core cross-platform module calling method is similar to that of the multi-core cross-platform module calling system described above, so it will not be repeated here.
[0054] The multi-core cross-platform module invocation method provided in this embodiment of the invention can be implemented on the terminal side or the server side. For the hardware structure of the multi-core cross-platform module invocation device, please refer to [link to relevant documentation]. Figure 4 This is a schematic diagram of an optional hardware structure of a multi-core cross-platform module calling device 400 provided in an embodiment of the present invention. The device 400 can be a mobile phone, computer device, tablet device, personal digital processing device, factory back-end processing device, etc. The multi-core cross-platform module calling device 400 includes: at least one processor 401, a memory 402, at least one network interface 404, and a user interface 406. The various components in the device are coupled together through a bus system 405. It is understood that the bus system 405 is used to realize the connection and communication between these components. In addition to a data bus, the bus system 405 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 4 The general will label all buses as bus systems.
[0055] The user interface 406 may include a monitor, keyboard, mouse, trackball, clicker, button, touchpad, or touch screen.
[0056] It is understood that memory 402 can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM) or programmable read-only memory (PROM), used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM) and synchronous static random access memory (SSRAM). The memories described in the embodiments of this invention are intended to include, but are not limited to, these and any other suitable categories of memory.
[0057] In this embodiment of the invention, the memory 402 is used to store various types of data to support the operation of the multi-core cross-platform module calling device 400. Examples of this data include: any executable program that operates on the multi-core cross-platform module calling device 400, such as the operating system 4021 and application 4022; the operating system 4021 contains various system programs, such as the framework layer, core library layer, driver layer, etc., used to implement various basic services and handle hardware-based tasks. The application 4022 may contain various applications, such as media players, browsers, etc., used to implement various application services. The implementation of the multi-core cross-platform module calling method provided in this embodiment of the invention can be included in the application 4022.
[0058] The methods disclosed in the above embodiments of the present invention can be applied to processor 401, or implemented by processor 401. Processor 401 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 401 or by instructions in the form of software. The processor 401 may be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 401 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present invention. General-purpose processor 401 may be a microprocessor or any conventional processor, etc. The steps of the accessory optimization method provided in the embodiments of the present invention can be directly reflected as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software module may be located in a storage medium, which is located in a memory. The processor reads the information in the memory and combines it with its hardware to complete the steps of the aforementioned method.
[0059] In an exemplary embodiment, the multi-core cross-platform module invocation device 400 may be used by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), or complex programmable logic devices (CPLDs) to execute the aforementioned method.
[0060] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, enables the multi-core cross-platform module to be invoked.
[0061] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented using computer program-related hardware. The aforementioned computer program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.
[0062] In the embodiments provided by this invention, the computer-readable and writable storage medium may include read-only memory, random access memory, EEPROM, CD-ROM or other optical disc storage devices, disk storage devices or other magnetic storage devices, flash memory, USB flash drive, portable hard drive, or any other medium capable of storing desired program code having an instruction or data structure form and accessible by a computer. Additionally, any connection may be appropriately referred to as a computer-readable medium. For example, if the instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of the medium. However, it should be understood that computer-readable and writable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but are intended for non-transient, tangible storage media. The disks and optical discs used in the invention include compact optical discs (CDs), laser optical discs, optical discs, digital multifunction optical discs (DVDs), floppy disks, and Blu-ray discs, wherein disks typically copy data magnetically, while optical discs use lasers to optically copy data.
[0063] In summary, this invention provides a method, system, device, and storage medium for multi-core cross-platform module invocation. It defines the internal hierarchical structure of modules and the invocation methods between modules, allowing for flexible configuration of module connection order and combination methods according to application scenarios, significantly increasing code reusability. For diverse customer needs, such as different cores, different communication methods, and different operating system combinations, the maintenance costs of multiple software solutions would increase exponentially. This invention requires only one software development kit (SDK), supports cross-platform features, and only requires system customization during compilation based on the actual product (multi-core, inter-core communication method, operating system) to meet requirements, greatly saving development and maintenance costs. Therefore, this invention effectively overcomes the various shortcomings of existing technologies and has high industrial application value.
[0064] The above embodiments are merely illustrative of the principles and effects of the present invention and are not intended to limit the invention. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in the present invention should still be covered by the claims of the present invention.
Claims
1. A multi-core cross-platform module calling system, characterized in that, include: Multiple functional modules, each of which includes an interconnected driver layer and an adapter layer; Platform module; The system platform includes the function pointer structures of each of the aforementioned functional modules and the platform module; the function pointer structures of the functional modules are connected to the corresponding adaptation layers; The system platform can call each of the functional modules in one or more of the following ways: registering the connection interface of the called functional module in the current functional module in the form of a callback function; calling the interface of the function pointer structure of the called functional module in the function pointer structure of the current functional module; assigning the driver layer interface of the called functional module to the function pointer structure of the platform module, so that the current functional module can call the driver layer interface of the called functional module from the function pointer structure of the platform module.
2. The multi-core cross-platform module calling system according to claim 1, characterized in that, It also includes a system abstraction layer, which allows users to call functional modules located in different operating systems.
3. The multi-core cross-platform module calling system according to claim 2, characterized in that, The operating systems include Linux and FreeRTOS.
4. A method for calling multi-core cross-platform modules, characterized in that, Applied to a system platform; the system platform includes various functional modules and function pointer structures for the platform modules; the method includes: Determine the current functional module and its corresponding called functional module; both the current functional module and the called functional module include interconnected driver layers and adaptation layers. The called functional module is invoked to the current functional module through one or more of the following invocation methods: registering the connection interface of the called functional module in the current functional module as a callback function; calling the interface of the function pointer structure of the called functional module in the function pointer structure of the current functional module; assigning the driver layer interface of the called functional module to the function pointer structure of the platform module, so that the current functional module can call the driver layer interface of the called functional module from the function pointer structure of the platform module.
5. The multi-core cross-platform module calling method according to claim 4, characterized in that, Also includes: The system abstraction layer calls functional modules located in different operating systems.
6. The multi-core cross-platform module calling method according to claim 5, characterized in that, The operating systems include Linux and FreeRTOS.
7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the multi-core cross-platform module invocation method as described in any one of claims 4 to 6.
8. A multi-core cross-platform module calling device, characterized in that, include: Processor and memory; The memory is used to store computer programs; The processor is used to execute the computer program stored in the memory to cause the device to perform the multi-core cross-platform module invocation method as described in any one of claims 4 to 6.