Dynamic binding method and system for embedded script and equipment capability

Abstract

The invention relates to an embedded system software engineering technology, in particular to a dynamic binding method and system for an embedded script and equipment capacity. The dynamic binding method for the embedded script and the equipment capacity comprises the steps that when an equipment loader loads a script mirror image, binding of a short ID and an internal ID of equipment is established by comparing a calling name with a capacity name of the equipment, and the binding relation is stored in a memory mapping table; when an equipment interpreter executes the script mirror image, querying the memory mapping table according to the short ID so as to find and execute the capability processing function corresponding to the internal ID of the equipment; wherein the call name is located in an API mapping table in the script mirror image and forms mapping with a corresponding short ID in the API mapping table; the capability name of the equipment is located in a capability mapping table and forms mapping with the internal ID of the equipment.

Description

[0001] Cross-reference to related applications This application is based on and claims priority to Chinese Patent Application No. 2025113101032, filed on September 15, 2025, and Chinese Patent Application No. 2025116647471, filed on November 13, 2025. The entire contents of the above applications are incorporated herein by reference. Technical Field

[0002] This invention relates to embedded system software engineering technology, specifically to a method and system for dynamically binding embedded scripts to device capabilities, as well as electronic devices and readable storage media. Background Technology

[0003] In the field of embedded systems, scripting languages ​​(such as JavaScript, Python, and embedded subsets of Lua) are widely used to implement application logic for IoT devices and smart hardware due to their high development efficiency and flexibility. However, how scripts can securely and efficiently invoke the capabilities provided by embedded devices remains a key challenge.

[0004] Most current mainstream technical solutions employ a static binding mechanism, whereby a fixed numerical ID is assigned to each device capability to be invoked during script compilation. The invocation instructions in the script are directly compiled into invocations based on this numerical ID, while the device side maintains a static ID-capability address mapping table.

[0005] The problem with this static binding approach is that the script must know the exact memory address or fixed numeric ID of the device capability at compile time. The compiler will directly hardcode the call statement as an instruction to jump to a certain address or call a certain numeric ID. However, the internal ID or function address of the same capability may be completely different on different device models or in different firmware versions. This means that a script image compiled for device A may not be able to run on device B, and must be recompiled for different device models, greatly increasing software distribution and maintenance costs.

[0006] Therefore, existing technologies suffer from the problem that static binding "solders" the binding relationship into the script image after compilation and cannot be changed. If the internal ID or function address of the same capability differs on different devices, the script must be recompiled.

[0007] It should be noted that the information disclosed in this background section is only for understanding the background technology of the present application concept, and therefore, the above description is not considered to constitute prior art information. Summary of the Invention

[0008] The purpose of this invention is to provide a method and system for dynamically binding embedded scripts to device capabilities, as well as an electronic device and a readable storage medium.

[0009] To address the aforementioned technical problems, this invention provides a method for dynamically binding embedded scripts to device capabilities, comprising: When the device loader loads the script image, it establishes a binding between a short ID and the device's internal ID by comparing the call name with the device's capability name, and stores the binding relationship in a memory-mapped table; and When the device interpreter executes the script image, it queries the memory mapping table based on the short ID to find and execute the capability processing function corresponding to the internal ID of the device. Wherein: the call name is located in the API mapping table in the script image, and is mapped to the corresponding short ID in the API mapping table; The capability name of the device is located in the capability mapping table and is mapped to the device's internal ID.

[0010] In another aspect, the present invention also provides a method for dynamically binding embedded scripts to device capabilities, including: The script is compiled using the compilation tools on the host computer, and a mapping from call names to short IDs is created to generate an API mapping table, which is then embedded into the script image. The script image is configured to: when the device loader loads the script image, establish a binding between a short ID and a device internal ID by comparing the call name with the device capability name, and store the binding relationship in a memory mapping table; and when the device interpreter executes the script image, query the memory mapping table based on the short ID to find and execute the capability processing function corresponding to the device internal ID. The call name is located in the API mapping table in the script image and is mapped to the corresponding short ID in the API mapping table; and the device capability name is located in the capability mapping table and is mapped to the device internal ID.

[0011] Thirdly, the present invention also provides an embedded device configured to include: The loading module is configured to: when loading the script image, establish a binding between a short ID and a device internal ID by comparing the call name and the capability name, and store the binding relationship in a memory-mapped table; and The running module is configured to: when running the script image, the device queries the memory mapping table based on the short ID to find and execute the capability processing function corresponding to the device's internal ID; The call name is located in the API mapping table in the script image and is mapped to the corresponding short ID in the API mapping table; and the device capability name is located in the capability mapping table and is mapped to the device internal ID.

[0012] Fourthly, the present invention also provides a computer device configured to include: The compilation module is configured to create a mapping of call names to short IDs when compiling scripts, in order to generate an API mapping table and embed the API mapping table into the script image; The sending module is configured to output a script image to the device loader; The script image is configured to: when the device loader loads the script image, establish a binding between a short ID and a device internal ID by comparing the call name with the device capability name, and store the binding relationship in a memory mapping table; and when the device interpreter executes the script image, query the memory mapping table based on the short ID to find and execute the capability processing function corresponding to the device internal ID. The call name is located in the API mapping table in the script image and is mapped to the corresponding short ID in the API mapping table; and the device capability name is located in the capability mapping table and is mapped to the device internal ID.

[0013] Fifthly, the present invention also provides a dynamic binding system for embedded scripts and device capabilities, comprising: The embedded devices as described above, and the computer devices as described above.

[0014] In a sixth aspect, the present invention also provides a non-transitory readable storage medium storing instructions that, when executed by a processor, cause the processor to execute the aforementioned method for dynamically binding embedded scripts and device capabilities.

[0015] In a seventh aspect, the present invention also provides an electronic device, comprising: Non-transitory computer-readable storage medium; processor; The non-transitory computer-readable storage medium stores instructions that, when executed by a processor, cause the processor to perform the dynamic binding method for embedded scripts and device capabilities as described above.

[0016] Eighthly, the present invention also provides a computer program product including instructions that, when executed by a processor, cause the processor to perform the aforementioned method for dynamically binding embedded scripts to device capabilities.

[0017] Ninthly, the present invention also provides an embedded device, comprising: Readable storage medium; processor; The readable storage medium storage device loader and instructions, when the instructions are executed by the processor, cause the processor to execute the dynamic binding method of embedded scripts and device capabilities as described above.

[0018] The beneficial effect of this invention is that the dynamic binding method of embedded scripts and device capabilities of this invention delays the timing of script calls and device capability binding from when the host computer compiles the script to when the device loads the script image, and binds the script calls and device capabilities based on the name, thereby realizing the dynamic binding of script calls and device capabilities. This solves the technical problem in the prior art where static binding causes the binding relationship to be "welded" into the script image after compilation and cannot be changed. If the internal ID or capability processing function address of the same capability is different on different devices, the script must be recompiled.

[0019] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained through the structures particularly pointed out in the description and the drawings.

[0020] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0021] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0022] Figure 1 The diagram illustrates the steps of a method for dynamically binding embedded scripts to device capabilities according to some embodiments; Figure 2 A schematic block diagram of an embedded device according to some embodiments is shown; Figure 3 A schematic block diagram of a computer device involved in some embodiments is shown; Figure 4 A schematic diagram of a dynamic binding system for embedded scripts and device capabilities is shown in some embodiments; Figure 5 A block diagram illustrating the electronic hardware platform principles involved in some embodiments is shown; Figure 6Block diagrams illustrating the principles of electronic hardware platforms involved in some embodiments are shown. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0024] Explanation of technical terms used in this embodiment: API (Application Programming Interface): Application programming interface.

[0025] TCAN (Typed CAN Data Structure): A typed CAN (Controller Area Network) data structure.

[0026] CAPS (Capabilities Summary): Capabilities Summary.

[0027] In existing static binding schemes, scripts must know the exact memory address or fixed numeric ID of a device capability at compile time. The compiler directly hardcodes the call statements as instructions to jump to a specific address or call a specific numeric ID. However, the internal ID or function address of the same capability may be completely different on different device models or in different firmware versions. This means that a script image compiled for device A may not run on device B, requiring recompilation for different device models, greatly increasing software distribution and maintenance costs.

[0028] Therefore, existing technologies suffer from the problem that static binding "solders" the binding relationship into the script image after compilation and cannot be changed. If the internal ID or function address of the same capability differs on different devices, the script must be recompiled.

[0029] Therefore, at least one embodiment provides a method for dynamically binding embedded scripts to device capabilities, including: when the device loader loads the script image, establishing a binding between a short ID and a device internal ID by comparing the call name with the device capability name, and storing the binding relationship in a memory mapping table; and when the device interpreter executes the script image, querying the memory mapping table based on the short ID to find and execute the capability processing function corresponding to the device internal ID; wherein: the call name is located in the API mapping table in the script image and is mapped to the corresponding short ID in the API mapping table; the device capability name is located in the capability mapping table and is mapped to the device internal ID.

[0030] This method for dynamically binding embedded scripts and device capabilities delays the timing of script calls and device capability binding from when the script is compiled on the host computer to when the device loads the script image. It binds script calls and device capabilities based on names, thus achieving dynamic binding between script calls and device capabilities. This solves the technical problem in existing technologies where static binding results in the binding relationship being "welded" to the script image after compilation and cannot be changed. Furthermore, if the internal ID or capability processing function address of the same capability differs on different devices, the script must be recompiled.

[0031] The various non-limiting embodiments of the present disclosure will now be described in detail with reference to the accompanying drawings.

[0032] like Figure 1 As shown, some embodiments provide a method for dynamically binding embedded scripts to device capabilities, including: Step S101: When the device loader loads the script image, it establishes a binding between the short ID and the device internal ID by comparing the call name with the device capability name, and stores the binding relationship in the memory mapping table.

[0033] Step S102: When the device interpreter executes the script image, it queries the memory mapping table based on the short ID to find and execute the capability processing function corresponding to the device internal ID.

[0034] In some embodiments, the call name is located in the API mapping table in the script image and is mapped to the corresponding short ID in the API mapping table; the device capability name is located in the capability mapping table and is mapped to the device internal ID.

[0035] In some embodiments, the method for dynamically binding embedded scripts to device capabilities further includes: compiling the script using a compilation tool on a host computer, creating a mapping from call names to short IDs to generate an API mapping table, and embedding the API mapping table into the script image.

[0036] In some embodiments, creating a mapping from call names to short IDs to generate an API mapping table includes: scanning the entire script source code with a compilation tool to extract all call names from the script; stably sorting the call names; assigning a corresponding short ID to each call name according to the stable sorting; generating the API mapping table; and embedding the API mapping table into the script image.

[0037] Specifically, to ensure the determinism and reproducibility of the generated API mapping table, the extracted call names are subjected to stable sorting. The stable sorting is, for example, but not limited to, lexicographical sorting. For example, the call names "file.write", "sensor.read", "app.tx", and "app.rx" are sorted as "app.rx", "app.tx", "file.write", and "sensor.read".

[0038] Specifically, after the call names are stably sorted, a short ID is assigned to each call name. The short ID can be an integer or a letter. For example, starting from the value 1, the following are some examples: "app.rx" is assigned a short ID of 1, "app.tx" is assigned a short ID of 2, "file.write" is assigned a short ID of 3, and "sensor.read" is assigned a short ID of 4.

[0039] In some embodiments, the method for dynamically binding embedded scripts to device capabilities further includes: during the device startup or initialization phase, registering the various capabilities that the device itself can provide to the device's own runtime registry center, forming a mapping from capability names to device internal IDs, and generating the capability mapping table.

[0040] In some embodiments, the capability mapping table further includes a mapping relationship between device internal IDs and capability processing functions used to implement the corresponding capabilities.

[0041] Specifically, during the device startup or application initialization phase, the operating system running on the device executes a device capability registration process: by traversing the pre-set driver modules, the device enumerates all currently available capabilities and registers each capability's name, corresponding internal device ID, capability processing function used to implement the corresponding capability, and other data as a complete record to a global runtime registry center that exists in the device's memory at runtime, thereby dynamically constructing the capability mapping table.

[0042] During device startup or application initialization, the device can also directly build or overwrite the runtime registry by reading an external JSON file.

[0043] In some embodiments, when the device loads the script image, a binding between a short ID and a device internal ID is established by comparing the call name and the capability name, and the binding relationship is stored in a memory-mapped table. This includes: traversing the API mapping table through the device's loader; searching and matching in the runtime registry for each call name in the API mapping table; and when a capability name with the same name as the call name is found, the loader extracts the device internal ID corresponding to the capability name to dynamically establish a binding relationship between the device internal ID and the short ID, and stores the binding relationship in the memory-mapped table.

[0044] In some embodiments, if a call name does not find a matching capability name in the runtime registry, the device loader refuses to load the script image, i.e., loading fails; or if a call name does not find a matching capability name in the runtime registry, the device loader allows loading to continue, delaying the loading failure until the script image executes the call.

[0045] Specifically, when the device's loader traverses the API mapping table of the script image, if it finds that a certain call name does not have a matching capability name in the device's runtime registry, the device will take different processing methods according to the preset loading strategy. The loading strategy includes a strict strategy mode and a compatibility strategy mode. In the strict strategy mode, the loader will immediately terminate the entire loading process, directly return an error code indicating a missing capability, and refuse to load the script image, thereby achieving fault pre-emption and fast failure, ensuring that the script image can only run in a fully functional environment. In the compatibility strategy mode, the loader will allow the script image loading process to continue, but will mark the short ID corresponding to the call name as a mapping missing state, and delay the actual binding failure until the first attempt to execute the marked call during script execution. At this time, the processing methods include: the device's interpreter reporting a runtime exception or attempting to execute a predefined degradation scheme (such as ignoring this call or calling a backup capability). This design provides the possibility for the script to run some functions on a capability-tailored device.

[0046] In some embodiments, the capability mapping table further includes: a mapping relationship between device internal IDs and function signatures; therefore, the function signature is structured metadata, including: the total number of parameters the function expects to receive, the data type of each parameter, and the function return value type; the dynamic binding method between the embedded script and device capabilities further includes: when the device interpreter finds the corresponding device internal ID based on the short ID, it first checks whether the total number of parameters the function expects to receive, the data type of each parameter, and the function return value type are consistent with the parameters actually passed in when the script image is executed and called, based on the corresponding function signature; if they are consistent, the call is executed; otherwise, the call is stopped.

[0047] Specifically, this embodiment also provides a type security verification mechanism based on function signatures. In the capability mapping table, each device's internal ID is associated not only with the capability processing function but also with its function signature. The core content of this function signature includes: the total number of parameters the function expects to receive, the specific data type of each parameter (such as int32, string, or a custom structure TCAN), and the specific data type of the function's return value.

[0048] Specifically, after the device interpreter successfully retrieves the corresponding internal device ID based on the short ID provided by the script, it does not immediately execute the call. Instead, it inserts a rigorous verification step: the device interpreter first retrieves the function signature of the corresponding capability from the runtime registry, and then compares it item by item with the parameters actually passed to the script call instruction. Only when all the aforementioned verifications (total number of parameters and types of each parameter) pass successfully will the device interpreter safely dispatch the call to the device capability processing function for execution. If any verification fails at any stage (such as a mismatch in the total number of parameters or a mismatch in parameter types), the device interpreter will immediately terminate the call process and return a specific type error code. This effectively prevents underlying memory access errors, data corruption, or system crashes caused by parameter mismatches, transforming runtime errors into a controllable and predictable exception handling process.

[0049] In some embodiments, after generating the capability mapping table, the device extracts all registered capability names to form a capability name digest (CAPS). Before parsing and traversing the API mapping table through the device's loader, the API mapping table is quickly compared with the capability name digest (CAPS). If all the call names in the API mapping table match the corresponding capability names in the capability name digest (CAPS), the device's loader continues to parse and traverse the API mapping table. If not all the call names in the API mapping table match the corresponding capability names in the capability name digest (CAPS), the device's loader refuses to load the script image, i.e., loading fails. Alternatively, if not all the call names in the API mapping table match the corresponding capability names in the capability name digest (CAPS), the device's loader allows loading to continue, delaying the loading failure until the script image executes the call for which no capability name was matched before processing it.

[0050] Specifically, before the device's loader parses and traverses the API mapping table, a quick comparison between the API mapping table and the capability name digest is performed. This allows for a macro-level compatibility assessment at the initial binding stage, greatly optimizing loading efficiency and providing crucial early error detection and handling capabilities for resource-constrained embedded devices.

[0051] In some embodiments, the capability name includes capability version information to distinguish different versions of the same capability; and the call name includes call version information.

[0052] Specifically, both the capability name and the call name can contain explicit version information (e.g., the name is get_location@v2.1, where @v2.1 is the version information). The version information can accurately distinguish different implementation versions of the same capability. The capability mapping table can include multiple implementations with the same capability name but different version numbers. The script call name also carries version information, so that when loading and binding, the device can accurately match the versioned capability name and the call name, and bind the script call to a specific device capability version according to the preset version matching strategy (such as strict version matching, latest compatible version, etc.), thus solving the script compatibility challenge caused by the iteration of device capability versions.

[0053] like Figure 2 As shown, some embodiments also provide an embedded device configured to include: The loading module is configured to, when loading the script image, establish a binding between a short ID and a device internal ID by comparing the call name and the capability name, and store the binding relationship in a memory-mapped table; and The running module is configured such that when the script image is running, the device queries the memory mapping table based on the short ID to find and execute the capability processing function corresponding to the device's internal ID; The call name is located in the API mapping table in the script image and is mapped to the corresponding short ID in the API mapping table; and the device capability name is located in the capability mapping table and is mapped to the device internal ID.

[0054] The specific implementation functions of the loading module and the running module are implemented in the embedded device. For details, please refer to the aforementioned section on the dynamic binding method of embedded scripts and device capabilities, which will not be repeated here.

[0055] like Figure 3 As shown, some embodiments also provide a computer device configured to include: The compilation module is configured to create a mapping of call names to short IDs when compiling scripts, in order to generate an API mapping table and embed the API mapping table into the script image; The sending module is configured to output a script image to the device loader; The script image is configured to: when the device loader loads the script image, establish a binding between a short ID and a device internal ID by comparing the call name with the device capability name, and store the binding relationship in a memory mapping table; and when the device interpreter executes the script image, query the memory mapping table based on the short ID to find and execute the capability processing function corresponding to the device internal ID. The call name is located in the API mapping table in the script image and is mapped to the corresponding short ID in the API mapping table; and the device capability name is located in the capability mapping table and is mapped to the device internal ID.

[0056] The specific implementation functions of the compilation module and the sending module are implemented in the computer device. For details, please refer to the aforementioned section on the dynamic binding method of embedded scripts and device capabilities, which will not be repeated here.

[0057] like Figure 4 As shown, some embodiments also provide a dynamic binding system for embedded scripts and device capabilities, including: the embedded device as described above, and the computer device as described above.

[0058] The electronic devices in the embodiments of this disclosure are described below from the perspective of hardware processing: The embodiments disclosed herein do not limit the specific implementation of the electronic device.

[0059] like Figure 5 As shown, some embodiments also provide an electronic device, including: a processor, a non-transitory computer-readable storage medium, a communication bus, and a communication interface; wherein the processor, the non-transitory computer-readable storage medium, and the communication interface communicate with each other through the communication bus; the non-transitory computer-readable storage medium stores instructions that, when executed by the processor, cause the processor to perform the following operations: compile a script, create a mapping from call names to short IDs to generate an API mapping table, and embed the API mapping table into a script image; the script image is configured to: when a device loader loads the script image, establish a binding between a short ID and a device internal ID by comparing the call name with the device's capability name, and store the binding relationship in a memory mapping table; and when a device interpreter executes the script image, query the memory mapping table based on the short ID to find and execute the capability processing function corresponding to the device internal ID; The call name is located in the API mapping table in the script image and is mapped to the corresponding short ID in the API mapping table; and the device capability name is located in the capability mapping table and is mapped to the device internal ID.

[0060] like Figure 6As shown, some embodiments also provide an electronic device, including: Non-transitory computer-readable storage medium; processor; The non-transitory computer-readable storage medium stores instructions that, when executed by a processor, cause the processor to perform the following operations: The script is compiled, and a mapping from call names to short IDs is created to generate an API mapping table, which is then embedded into the script image. The script image is configured to: when the device loader loads the script image, establish a binding between short IDs and internal device IDs by comparing the call names with the device's capability names, and store the binding relationship in a memory mapping table; and when the device interpreter executes the script image, query the memory mapping table based on the short IDs to find and execute the capability processing function corresponding to the internal device ID. The call name is located in the API mapping table in the script image and is mapped to the corresponding short ID in the API mapping table; and the device capability name is located in the capability mapping table and is mapped to the device internal ID.

[0061] In some embodiments, computer devices and industrial control computers can also be used as a type of electronic device.

[0062] Figure 5 and Figure 6 The structure shown does not constitute a limitation on the electronic device and may include fewer or more components than shown, or combine certain components, or have different component arrangements.

[0063] In some embodiments, the communication interface may be RS232, RS485, USB, or TYPE, and can be connected to an external bus adapter. It may also include a wired or wireless network interface, which may optionally include a wired interface and / or a wireless interface (such as a Wi-Fi interface, Bluetooth interface, etc.), typically used to establish communication connections between the computer device and other electronic devices.

[0064] In some embodiments, non-transitory computer-readable storage media include, but are not limited to, flash memory, hard disks, multimedia cards, card-type memories (e.g., SD memory), magnetic storage, magnetic disks, optical disks, etc. In some embodiments, it may be an internal storage unit of a computer device, such as the hard disk of that computer device. In other embodiments, the storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, SmartMedia Card (SMC), Secure Digital (SD) card, Flash Card, etc., provided on the computer device. Furthermore, the storage medium may include both internal storage units and external storage devices of the computer device. The storage medium can be used not only to store application software and various types of data installed on the computer device, such as computer program code, but also to temporarily store data that has been output or will be output.

[0065] In some embodiments, a processor may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip, used to run program code stored in memory or process data, such as executing computer programs.

[0066] In some embodiments, the communication bus can also be an input / output bus, which may be a Peripheral Component Interconnect (PCI) bus or an Enhanced Industry Standard Architecture (EISA) bus, etc. This bus can be divided into address bus, data bus, control bus, etc.

[0067] Optionally, the computer device may also include a user interface, which may include a display, an input unit such as a keyboard, and optionally, a standard wired interface or a wireless interface. Optionally, in some embodiments, the display may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an organic light-emitting diode (OLED) touchscreen, etc. The display may also be appropriately referred to as a screen or display unit, used to display information processed in the computer device.

[0068] When the processor executes the program, it implements the steps in the above-described embodiment of the dynamic binding method between embedded scripts and device capabilities: compiling the script and creating a mapping from call names to short IDs to generate an API mapping table, and embedding the API mapping table into the script image. Alternatively, when the processor executes the computer program, it implements the functions of each module or unit in the above-described device embodiments.

[0069] Some embodiments also provide a non-transitory computer-readable storage medium storing computer-readable instructions that, when executed by at least one processor, cause the previously described method for dynamically binding embedded scripts to device capabilities to be executed.

[0070] Some embodiments also provide a computer program product including a readable storage medium having readable program code stored thereon, the readable program code including instructions that cause at least one processor (one or more computer devices) to perform the dynamic binding method of embedded scripts and device capabilities as described above.

[0071] Some embodiments also provide an embedded device, including: a readable storage medium; a processor; wherein the readable storage medium stores a device loader and instructions, which, when executed by the processor, cause the processor to perform the following operations: when loading the script image, by comparing the call name with the device capability name, establish a binding between a short ID and a device internal ID, and store the binding relationship in a memory mapping table; and when executing the script image, query the memory mapping table according to the short ID to find and execute the capability processing function corresponding to the device internal ID; wherein the call name is located in the API mapping table in the script image and is mapped to the corresponding short ID in the API mapping table; the device capability name is located in the capability mapping table and is mapped to the device internal ID.

[0072] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative; for example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0073] In addition, the functional modules in the various embodiments of the present invention can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0074] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a non-transitory computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0075] Based on the above-described preferred embodiments of the present invention, and through the foregoing description, those skilled in the art can make various changes and modifications without departing from the inventive concept. The technical scope of this invention is not limited to the contents of the specification, but must be determined according to the scope of the claims.

Claims

1. A method for dynamically binding embedded scripts to device capabilities, characterized in that, include: When the device loader loads the script image, it establishes a binding between the short ID and the device's internal ID by comparing the call name with the device's capability name, and stores the binding relationship in a memory mapping table; as well as When the device interpreter executes the script image, it queries the memory mapping table based on the short ID to find and execute the capability processing function corresponding to the internal ID of the device. The call name is located in the API mapping table in the script image and is mapped to the corresponding short ID in the API mapping table; The capability name of the device is located in the capability mapping table and is mapped to the device's internal ID.

2. The method for dynamically binding embedded scripts to device capabilities according to claim 1, characterized in that, Also includes: During the device startup or initialization phase, the various capabilities that the device itself can provide are registered to the device's own runtime registry center, forming a mapping from capability names to device internal IDs, and generating the capability mapping table.

3. The method for dynamically binding embedded scripts to device capabilities according to claim 2, characterized in that, The capability mapping table also includes a mapping relationship between the device's internal ID and the capability processing function used to implement the corresponding capability.

4. The method for dynamically binding embedded scripts to device capabilities according to claim 2, characterized in that, When the device loader loads the script image, it establishes a binding between the short ID and the device's internal ID by comparing the call name with the device's capability name, and stores the binding relationship in a memory-mapped table, including: The API mapping table is parsed and traversed using the device's loader; For each call name in the API mapping table, a search and match are performed in the runtime registry; and When a capability name with the same name as the call name is found, the loader extracts the device internal ID corresponding to the capability name to dynamically establish a binding relationship between the device internal ID and the short ID, and stores the binding relationship in a memory-mapped table.

5. The method for dynamically binding embedded scripts to device capabilities according to claim 4, characterized in that, If a call name cannot be found in the runtime registry as a matching capability name, the device loader will refuse to load the script image, i.e., loading will fail; or If a call name cannot be found to match a capability name in the runtime registry, the device loader will allow loading to continue, and the loading failure will be delayed until the script image executes the call.

6. The method for dynamically binding embedded scripts to device capabilities according to claim 3, characterized in that, The capability mapping table also includes: the mapping relationship between device internal IDs and function signatures; The function signature is structured metadata, including: the total number of parameters the function expects to receive, the data type of each parameter, and the function return value type; The method for dynamically binding embedded scripts to device capabilities also includes: When the device interpreter finds the corresponding internal device ID based on the short ID, it first checks whether the total number of parameters the function expects to receive, the data type of each parameter, and the function return value type are consistent with the parameters actually passed in when the script image is executed. If they are consistent, the call is executed; otherwise, the call is stopped.

7. The method for dynamically binding embedded scripts to device capabilities according to claim 4, characterized in that, After generating the capability mapping table, the device extracts all registered capability names to form a capability name summary; as well as Before parsing and traversing the API mapping table through the device's loader, the API mapping table is first quickly compared with the capability name digest. If all the call names in the API mapping table can match the corresponding capability names in the capability name digest, then the API mapping table is parsed and traversed through the device's loader. If not all call names in the API mapping table match the corresponding capability names in the capability name digest, the device loader refuses to load the script image, i.e., loading fails; or If not all call names in the API mapping table match the corresponding capability names in the capability name digest, the device loader will allow loading to continue, and the loading failure will be delayed until the script image executes the call for which no capability name was matched before processing it.

8. The method for dynamically binding embedded scripts to device capabilities according to claim 1, characterized in that, The capability name includes capability version information to distinguish different versions of the same capability; and The call name includes the call version information.

9. A method for dynamically binding embedded scripts to device capabilities, characterized in that, include: The script is compiled using the compilation tools on the host computer, and a mapping from call names to short IDs is created to generate an API mapping table, which is then embedded into the script image. The script image is configured to: when the device loader loads the script image, establish a binding between a short ID and the device's internal ID by comparing the call name with the device's capability name, and store the binding relationship in a memory mapping table; And when the device interpreter executes the script image, it queries the memory mapping table based on the short ID to find and execute the capability processing function corresponding to the internal ID of the device; The call name is located in the API mapping table in the script image and is mapped to the corresponding short ID in the API mapping table; and the device capability name is located in the capability mapping table and is mapped to the device internal ID.

10. The method for dynamically binding embedded scripts to device capabilities according to claim 9, characterized in that, Create a mapping from call names to short IDs to generate an API mapping table, including: The entire script source code is scanned using a compiler tool to extract all call names from the script; The call names are sorted stably. After assigning a corresponding short ID to each call name according to a stable sorting, the API mapping table is generated and embedded into the script image.

11. An embedded device, characterized in that, The embedded device is configured to include: The loading module is configured to: when loading the script image, establish a binding between a short ID and a device internal ID by comparing the call name and the capability name, and store the binding relationship in a memory-mapped table; and The running module is configured to: when running the script image, the device queries the memory mapping table based on the short ID to find and execute the capability processing function corresponding to the device's internal ID; The call name is located in the API mapping table in the script image and is mapped to the corresponding short ID in the API mapping table; and the device capability name is located in the capability mapping table and is mapped to the device internal ID.

12. The embedded device according to claim 11, characterized in that, Also includes: The registration module is configured to register the various capabilities that the device itself can provide to the device's own runtime registration center during the device startup or initialization phase, forming a mapping from capability names to device internal IDs, and generating the capability mapping table.

13. The embedded device according to claim 12, characterized in that, When the loading module loads the script image, it establishes a binding between the short ID and the device's internal ID by comparing the call name with the device's capability name, and stores the binding relationship in a memory-mapped table, including: The API mapping table is parsed and traversed using the device's loader; For each call name in the API mapping table, a search and match are performed in the runtime registry; and When a capability name with the same name as the call name is found, the loader extracts the device internal ID corresponding to the capability name to dynamically establish a binding relationship between the device internal ID and the short ID, and stores the binding relationship in a memory-mapped table.

14. The embedded device according to claim 13, characterized in that, If a call name cannot be found in the runtime registry as a matching capability name, the device loader will refuse to load the script image, i.e., loading will fail; or If a call name cannot be found to match a capability name in the runtime registry, the device loader will allow loading to continue, and the loading failure will be delayed until the script image executes the call.

15. A computer device, characterized in that, The computer device is configured to include: The compilation module is configured to create a mapping of call names to short IDs when compiling scripts, in order to generate an API mapping table and embed the API mapping table into the script image; The sending module is configured to output a script image to the device loader; The script image is configured to: when the device loader loads the script image, establish a binding between a short ID and a device internal ID by comparing the call name with the device capability name, and store the binding relationship in a memory mapping table; and when the device interpreter executes the script image, query the memory mapping table based on the short ID to find and execute the capability processing function corresponding to the device internal ID. The call name is located in the API mapping table in the script image and is mapped to the corresponding short ID in the API mapping table; and the device capability name is located in the capability mapping table and is mapped to the device internal ID.

16. The computer apparatus according to claim 15, characterized in that, Create a mapping from call names to short IDs to generate an API mapping table, including: The entire script source code is scanned using a compiler tool to extract all call names from the script; The call names are sorted stably. After assigning a corresponding short ID to each call name according to a stable sorting, the API mapping table is generated and embedded into the script image.

17. A dynamic binding system for embedded scripts and device capabilities, characterized in that, include: The embedded device as claimed in claim 11, and, The computer device as claimed in claim 15.

18. A non-transitory readable storage medium, characterized in that, The system stores instructions that, when executed by a processor, cause the processor to perform the dynamic binding method of embedded scripts and device capabilities as described in any one of claims 1-10.

19. An electronic device, characterized in that, include: Non-transitory computer-readable storage medium; processor; The non-transitory computer-readable storage medium stores instructions that, when executed by a processor, cause the processor to perform the dynamic binding method of embedded scripts and device capabilities as described in any one of claims 9 or 10.

20. A computer program product, characterized in that, Includes instructions that, when executed by a processor, cause the processor to perform the dynamic binding method of embedded scripts and device capabilities as described in any one of claims 1-10.

21. An embedded device, characterized in that, include: Readable storage medium; processor; The readable storage medium storage device loader and instructions, when the instructions are executed by the processor, cause the processor to execute the dynamic binding method of embedded scripts and device capabilities as described in any one of claims 1-8.

Images