Intelligent equipment control method for heterogeneous computing environment

Abstract

The invention discloses an intelligent device control method in a heterogeneous computing environment, an intelligent device comprises a host end and an MCU end, the control method comprises the following steps: S1, writing a function control code in the same set of high-level language, adding a specified mark to an entry function executed at the MCU end, and calling a corresponding basic service function at a place where MCU hardware IO needs to be accessed; s2, converting a function executed by the MCU end in the function control code into a lightweight byte code, and transmitting the lightweight byte code to the MCU end; and S3, only sending periodic real-time function control, sensor reading and actuator operation write-in tasks to the MCU end for execution. According to the invention, the logic of the host and the MCU end is compiled by using the high-level language in a unified manner, multi-language splitting is avoided, and meanwhile, the MCU end adopts lightweight byte code interpretation and periodic memory management, so that occupation during operation can be compressed, and the industrial-level real-time performance requirement can be met.

Description

Technical Field

[0001] The present invention relates to the technical field of collaborative work between embedded systems and high-computing-power devices, and in particular to a method for uniformly using high-level languages for real-time control and large-scale computing of intelligent devices in a heterogeneous computing environment consisting of a host (high-computing-power host) and a microcontroller (MCU). Background Art

[0002] With the increasing demand for collaboration between embedded systems and high-computing devices in various terminals and industrial scenarios, such as intelligent driving, industrial automation, and IoT terminals, which require both real-time control on the MCU side and high-level complex logic processing on the host side, a variety of heterogeneous computing solutions are emerging, including:

[0003] (1) The traditional dual-language solution uses C or C++ for low-level development on the MCU side, and uses high-level languages such as C#, Java, or Python for upper-level control and business logic development on the host side. Although this solution fully utilizes the low-level performance of the MCU and is easy to develop and maintain on the host side, it requires maintaining two sets of logic at the same time, which is prone to inconsistencies, and the communication protocol is relatively complex, making the debugging process cumbersome.

[0004] (2) Lightweight scripting language solutions, typically MicroPython and Lua, deploy a simplified interpreter on the MCU to execute scripts. This solution has simple syntax and slightly smaller resource usage than C#, but has limited advanced functions and cannot guarantee real-time control performance. Moreover, unlike host-side high-level languages, it still requires multi-language maintenance.

[0005] (3) The .NET Micro Framework solution runs a streamlined version of the .NET runtime on the MCU, allowing developers to use C# programming. This solution has a unified language and a mature IDE ecosystem, but it consumes a lot of MCU resources (hundreds of KB of RAM), supports a limited number of MCU models, and has difficulty meeting the stringent real-time requirements of industrial sites.

[0006] (4) Cross-platform development frameworks (such as Arduino and PlatformIO), which are primarily based on C / C++ and provide a certain tool chain and library ecosystem. Although this solution supports resource-constrained MCUs and has a mature ecosystem, it lacks the convenience of object-oriented high-level languages and lacks cross-platform unified debugging and scheduling capabilities.

[0007] In summary, the above existing solutions generally face the following problems:

[0008] (1) Conflict between resource usage and functional requirements: Lightweight scripting languages are limited in functionality or cannot meet industrial-grade real-time requirements; powerful runtimes occupy too many resources on the MCU side.

[0009] (2) The contradiction between real-time performance and ease of use: high-level languages (such as MicroPython) do not support real-time scenarios; low-level languages (C / C++) have relatively high development efficiency and maintenance costs. High-level languages generally have more user-friendly integrated development environments, allowing developers to more easily develop the required functions; while MCUs generally use C language and its compiler, which is generally different from the development language of actual complex functional algorithms and often requires conversion.

[0010] (3) Development efficiency and consistency issues: Platform or language fragmentation leads to multiple separations of logic, debugging, and protocols; upgrade and maintenance costs are high, and it is difficult to perform synchronous debugging and linkage testing on both ends.

[0011] Therefore, the industry urgently needs a new technical solution with the following characteristics:

[0012] (1) It can still support complete high-level language features and meet real-time control requirements under resource-constrained conditions. For example, MCU, or single-chip microcomputer, is a very simple chip with no operating system, small memory, low main frequency, but extremely low working environment requirements and stable performance; (2) Unified development and debugging of the host and MCU can reduce the cost of multi-language maintenance; (3) Real-time control tasks and high-computing power computing tasks can be flexibly divided and collaboratively processed in the same development environment. Summary of the Invention

[0013] To address this issue, the present invention provides a heterogeneous computing environment for both host and MCU systems. This allows developers to write a single source code (based on a unified high-level language) to run it in an adapted form on both the host and MCU, enabling debugging and collaboration within the same development environment. Through lightweight bytecode interpretation and periodic memory management strategies, the MCU can run high-level language logic and ensure real-time performance within limited RAM / Flash resources, while the host retains a complete high-level language ecosystem and powerful computing power, thus achieving a balance between high real-time performance and high computing power requirements.

[0014] The present invention proposes a method for controlling an intelligent device in a heterogeneous computing environment, wherein the intelligent device includes a host and an MCU, and the method includes:

[0015] S1. Write function control code in the same high-level language, add a specified mark to the entry function executed on the MCU side, and call the corresponding basic service function where the MCU hardware IO needs to be accessed;

[0016] S2. Convert the function executed by the MCU in the function control code into lightweight bytecode and transmit it to the MCU;

[0017] S3: Only periodic real-time function control, sensor reading, and actuator operation writing tasks are sent to the MCU for execution.

[0018] Furthermore, the basic service function is declared in the project on the host side, and the corresponding function signature and calling entry are retained; the basic service function is implemented in C or assembly form in the firmware on the MCU side, so that it can be called through the function mapping table when the bytecode is running.

[0019] Furthermore, in S2, the post-processor of the compiler is used to scan the project corresponding to the task code, and based on the calling relationship, a set of functions required by the MCU is compiled, and the function set is compiled into a lightweight bytecode that can be interpreted by the MCU.

[0020] Furthermore, in S3, the method executed by the MCU includes:

[0021] S31, when the MCU virtual machine is running, it is triggered according to the preset cycle and the entry function is pushed into the execution stack; it receives the upper signal from the host side;

[0022] S32, interpreting and executing bytecode instructions one by one;

[0023] S33, recording which variables need to be exchanged with the host are written;

[0024] S34. When the execution stack is completely exited, it indicates the end of the execution of this cycle; the written upper signal, lower signal and static variable value are sent to the host side.

[0025] Furthermore, in S32, when a native function call is encountered, execution is directly jumped; if it is a function expressed in bytecode, it is pushed into the execution stack for execution, and the execution stack is popped after the function execution is completed.

[0026] Furthermore, when the MCU side executes in S3, if a communication delay or network failure occurs, the MCU side keeps its own control loop running independently and keeps the bytecode interpretation loop running; continues to execute the safety logic written in a high-level language when the host is down; and synchronizes and updates data after the host side recovers.

[0027] Furthermore, the MCU side also includes a driver module for each resource on the MCU, a communication module for sending or receiving data to the host, and generates corresponding firmware to be burned into the MCU.

[0028] Furthermore, the memory management method on the MCU side includes:

[0029] (1) Using a linear allocation strategy, objects created within a cycle are allocated sequentially along a fixed direction;

[0030] (2) Lightweight memory cleanup at the end of the cycle.

[0031] Furthermore, lightweight memory organization includes: initially marking all objects as to be cleaned up, identifying and marking static objects and communication data objects that need to be retained, recursively marking other objects referenced by retained objects, and after completing the marking, calculating the total space requirements of the retained objects, and tightly arranging and reorganizing the retained objects to achieve memory organization.

[0032] Furthermore, the host side includes a task management module, a self-task scheduling module, and a data exchange and synchronization module, wherein:

[0033] The task management module traverses all tasks declared in the high-level language script. If a task is marked as "MCU execution", it converts the task into bytecode through the compiler or post-processor during the startup phase and sends it to the corresponding MCU through the communication module.

[0034] Its own task scheduling module runs multiple cycles or event-triggered tasks, and updates the relevant variables and states in the host memory after each cycle is completed;

[0035] The data exchange and synchronization module receives the data packets sent by the MCU in each cycle, parses the updates of the lower-level signals and static variables, and integrates the updates into the global data model. At the same time, it sends the upper-level signals and static variables maintained in its own memory back to the MCU.

[0036] Furthermore, the host side also includes a data integration module for multiple MCUs or multiple tasks in parallel. The host side uniformly maps and normalizes all data from the MCU or other sources to form a global data memory; processes and forwards the upper-level system to access the lower-level control data or issues new control commands to the MCU.

[0037] The beneficial effects of the intelligent device control method in a heterogeneous computing environment provided by the present invention include:

[0038] (1) Development efficiency and consistency: Use high-level languages to write host and MCU logic, avoiding multi-language fragmentation; integrated debugging and linkage testing can be performed in the same IDE, greatly improving development and maintenance efficiency.

[0039] (2) Balancing resource constraints and real-time control: The MCU side uses lightweight bytecode interpretation and periodic memory management, which can not only compress runtime usage but also meet industrial-grade real-time performance requirements; no large runtime usage is required.

[0040] (3) Flexible update and remote debugging: Through the distribution and online replacement of bytecode, the MCU business logic can be quickly upgraded without refreshing the entire firmware package; the remote debugging mechanism further reduces operation and maintenance costs.

[0041] (4) Compatible with multi-scenario expansion: Whether it is an autonomous forklift, an industrial robot or a smart home device, it only needs to be compiled and deployed separately under a unified high-level language ecosystem to meet both high real-time and high computing power task requirements. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] The accompanying drawings are used to provide a further understanding of the present invention and constitute a part of the specification. Together with the embodiments of the present invention, they are used to explain the present invention and do not constitute a limitation of the present invention. In the accompanying drawings:

[0043] Figure 1 A schematic diagram of a method for controlling an intelligent device according to an embodiment of the present invention;

[0044] Figure 2 A schematic diagram of a method for controlling an intelligent device according to an embodiment of the present invention;

[0045] Figure 3 This is a schematic diagram of the MCU execution process of an embodiment of the present invention;

[0046] Figure 4 Schematic diagram of the functional structure of the host side according to an embodiment of the present invention. DETAILED DESCRIPTION

[0047] In the description of the present invention, it should be understood that the terms "center", "longitudinal", "lateral", "length", "width", "thickness", "up", "down", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inside", "outside", "clockwise", "counterclockwise" and the like to indicate orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore should not be understood as limiting the present invention.

[0048] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of the technical features being referred to. Thus, a feature identified as "first" or "second" may explicitly or implicitly include one or more of the features. In the description of the present invention, "plurality" means two or more, unless otherwise specifically defined.

[0049] In the present invention, unless otherwise expressly specified or limited, the terms "mounted," "connected," "connect," "fixed," etc. should be understood broadly. For example, they may refer to fixed, detachable, or integral connections; mechanical or electrical connections; direct or indirect connections through an intermediary; or internal communication between two components. Those skilled in the art will understand the specific meanings of the above terms in the present invention based on specific circumstances.

[0050] The preferred embodiments of the present invention are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are only used to illustrate and explain the present invention, and are not used to limit the present invention.

[0051] The present invention proposes a method for controlling intelligent devices in a heterogeneous computing environment. Figure 1 、 2 As shown, the smart device includes a host side and an MCU side. The specific control methods include:

[0052] S1. Write function control code in the same high-level language, add a specified mark to the entry function executed on the MCU side, and call the corresponding basic service function where the MCU hardware IO needs to be accessed;

[0053] S2. Convert the function executed by the MCU in the function control code into lightweight bytecode and transmit it to the MCU;

[0054] S3: Only periodic real-time function control, sensor reading, and actuator operation writing tasks are sent to the MCU for execution.

[0055] In S1, within the same high-level language source code, specific tags are used to indicate which tasks or functions are executed on the MCU. For example, in C#, [LogicRunOnMCU(device="MCU1")] can be used to indicate that the function is executed on MCU1. This is the "tag syntax" feature of the C# language itself.

[0056] In a preferred embodiment, tasks requiring low-level MCU hardware operations or high performance are implemented in the MCU firmware in native C / assembly code, referred to as basic service functions, which are called by the bytecode runtime through a function mapping table. For example, a fast Fourier transform function, which is not suitable for high-level programming languages, can be declared in the host-side project, leaving only the corresponding function signature and call entry point at the high-level language level.

[0057] In S2, after the function control code is compiled, the compiler's postprocessor (a compiler feature that allows data to be processed after compilation, thereby changing the original compilation result) scans the corresponding project of the program code and compiles the required function set on the MCU based on the call relationship. This is then compiled into lightweight bytecode that the MCU can interpret. This involves checking each instruction of the target function one by one and translating it into executable instructions or equivalent instructions on the MCU through a table lookup (for example, using a batch of instructions to emulate the original instruction's functionality). This results in a binary program that runs the function on the MCU.

[0058] In one embodiment, when running a host-side program, bytecode and configuration data are sent to the MCU via the host-MCU communication interface. The MCU then parses and prepares for execution. The MCU interprets and executes the lightweight bytecode using an MCU virtual machine, which reads one instruction at a time and executes the corresponding function until there are no more instructions to execute.

[0059] In this invention, the MCU virtual machine executes periodically and in real time, specifically for control and sensor data collection. It uploads and downloads data during each cycle and discards all other information. This greatly simplifies the virtual machine design, creating a dedicated system that periodically executes a fixed program, reclaims memory, and communicates with a host computer. The specific development method is prior art and will not be elaborated here.

[0060] In S3, the MCU only executes short-term, real-time-critical control tasks, including sensor reads and actuator writes, sent by the host. For example, in a smart car, hardware devices typically control wheel drivers, light strips, audible and visual alarms, edge collision avoidance strips, emergency stop buttons, and obstacle avoidance sensors. Sensors like edge collision avoidance strips, emergency stop buttons, and obstacle avoidance sensors require high real-time data acquisition and processing, and related safety functions require the driver to brake suddenly within a specified timeframe. Light strips and alarms require periodic state updates. Wheel drivers periodically transmit drive wheel speeds. These control functions require rapid response when triggered or must be invoked within a fixed, precise timeframe. The remaining tasks or functions are executed on the host, including high-computing computations, long-term tasks, data communication with the MCU, and external communications. Because these tasks lack real-time requirements or require large-scale computational logic, they typically involve complex memory management, long runtimes, and unpredictable memory and input / output sizes. In existing implementations, if a host is not available, these functions are run on the MCU, which presents development challenges. If a host runs a more complex program and still needs the MCU to perform real-time tasks, as described in the background technology, the traditional development method requires writing two sets of programs in different languages, while in the present invention, only one set of programs (in the same language) needs to be written, reducing development difficulties.

[0061] Short-cycle, real-time-critical function control, sensor reading, and actuator operation writing tasks with the following characteristics:

[0062] (1) Short execution time. This means a cycle is shorter, the data footprint generated is smaller, and it is easier to process.

[0063] (2) Strict real-time requirements. This means that a cycle is guaranteed to end within a specified time, and the amount of data generated has an upper limit, so it can be completed within a certain resource.

[0064] (3) It only performs real-time function control, sensor reading, and actuator operation writing tasks. This means that its input and output data are almost fixed in length, which means that each interaction does not require complex length judgment, and only the exchange of specified data can complete the task.

[0065] Because the tasks assigned to the MCU are highly defined and possess the aforementioned characteristics, they can be executed efficiently even on MCUs with limited resources and computing power. Typical MCUs have only 50K-500K of memory, which is generally not expandable, and a main frequency of approximately 100-300MHz. These resources are very limited and cannot run any full-scale operating system or full-featured high-level language. For example, smart car obstacle avoidance algorithms, such as the TEB algorithm, use LiDAR point cloud data or multi-frame image data, occupying tens of MB of memory and requiring a multi-core system with a speed of over 1GHz, making them relatively resource-constrained. However, if the system is simply acquiring I / O data, reading and writing CAN bus data messages, converting them into variables, controlling light brightness, and processing basic safety logic such as edge stop and emergency stop, resources are sufficient.

[0066] The MCU uploads lower-level signals (such as sensor readings and actuator status) to the host in each cycle (or after an event is triggered), and receives upper-level signals (such as control target values and configuration parameters) from the host. Figure 3 As shown, specifically including:

[0067] S31, when the MCU virtual machine is running, it is triggered according to the preset cycle and the entry function is pushed into the execution stack; it receives the upper signal from the host side;

[0068] S32. Interpret and execute the bytecode instructions one by one, and directly jump to the execution when encountering a native function call; if it is a function expressed in bytecode, it is pushed into the execution stack for execution, and the execution stack is popped after the function execution is completed;

[0069] S33. Record which variables (high-level signals, low-level signals, and static variables) that need to be exchanged with the host have been written.

[0070] S34. When the execution stack is completely exited, it indicates that the execution of this cycle is completed; the written upper signal, lower signal and static variable value are sent to the host through the communication interface.

[0071] In one embodiment, if a communication delay or network failure occurs, the MCU maintains its own independent control loop and the bytecode interpretation loop. Furthermore, the MCU can continue to execute safety logic written in a high-level language for the host computer during a downtime (e.g., executing an emergency stop). After the host computer recovers, data synchronization and updates can resume.

[0072] In one embodiment, the MCU also includes driver modules for various MCU resources (such as enabling and configuring GPIO / CAN) and a communication module for sending and receiving data to the host. These two modules are compiled together with basic service functions to generate corresponding firmware that is burned into the MCU. At this point, the MCU has basic hardware initialization, general driver, communication, and bytecode interpretation capabilities.

[0073] After the MCU is powered on, it completes basic hardware initialization, including: configuring the system clock and peripheral clocks, initializing communication interfaces (such as serial ports, CAN, Ethernet, etc.), configuring GPIO and other necessary peripherals, establishing communication with the host, receiving and verifying the bytecode sent by the host, and storing it in the designated program storage area.

[0074] Because programs running on the MCU are required to periodically process variables and discard all other intermediate data, the MCU virtual machine runtime becomes lightweight. The key innovation lies in the host executing complex algorithmic logic, while the MCU only needs to handle simple logic such as real-time processing and sensor IO.

[0075] In one embodiment, the memory management method on the MCU side includes:

[0076] (1) Using a linear allocation strategy, objects created within a cycle are allocated sequentially along a fixed direction;

[0077] (2) Perform lightweight memory cleanup at the end of the cycle, including: initially marking all objects as to be cleaned, identifying and marking static objects and communication data objects that need to be retained, recursively marking other objects referenced by retained objects, calculating the total space requirements of retained objects after marking is completed, and closely arranging and reorganizing retained objects to achieve memory regularity.

[0078] Through the above method, it is ensured that memory management is completed in a deterministic manner in each cycle, avoiding the time uncertainty caused by garbage collection. The difference between this and traditional memory association is that traditional memory management cannot confirm the time when it can be run. In the present invention, all the logic of the smart device is in an integrated high-level language, and only the real-time control logic that needs to be executed periodically will be sent to the MCU. Due to the periodic execution, memory management can be performed during non-periodic time. Memory management is relatively time-consuming, and it is impossible to predict when memory management is more appropriate in complex program logic. In the present invention, it is ensured that memory management will be executed at the appropriate time.

[0079] In one embodiment, the host side has a highly integrated operation and management mechanism, including:

[0080] (1) It will traverse all tasks declared in the high-level language script. If a task is marked as "MC execution", it will be converted into bytecode by the compiler or post-processor during the startup phase and sent to the corresponding MCU through the communication module. For tasks executed locally on the host side, they are directly triggered by the task management module on a periodic basis.

[0081] (2) It can run multiple cycles or event-triggered tasks simultaneously (such as high-computing algorithms, data aggregation, and visualization interfaces). These tasks update the relevant variables and states in the host memory after each cycle. Thanks to the host's powerful computing power and rich library support, it can run highly complex operations such as image recognition and path planning.

[0082] (3) After the MCU completes its task, it sends a data packet to the host during each control cycle (a control cycle is a periodic program execution, which also includes communication between the MCU and the host and memory recycling management). It then parses the updated items such as "lower-level signals" and "static variables" and integrates these contents into the global data model. After the parsing is completed, the values required by the MCU in the "upper-level signals" and "static variables" maintained in the memory are packaged and sent back to the MCU, allowing both ends to perform bidirectional synchronization in each cycle.

[0083] (4) Multiple MCUs or multiple tasks can exist in parallel. The host side will uniformly map and normalize all data from the MCU or other sources to form a global data memory. When the upper-level system (such as a remote server or user interface) needs to access the lower-level control data or issue a new control command to the MCU, it can interact with the host side through interfaces such as HTTP and WebSocket. The host will uniformly process and forward the data, thus realizing the connection and expansion of multi-level control.

[0084] (5) For external system access requirements, the present invention supports writing "upper-level information" or reading "lower-level information" and can utilize the host's powerful operating environment for security verification, permission management, and data logging. In this way, the host can maintain high-frequency two-way communication with the MCU internally and provide a friendly interface externally, allowing upper-level business systems or cloud platforms to flexibly manage and monitor the device.

[0085] Accordingly, the above functions can be made into modules, including task management module, self-task scheduling module, data communication and synchronization module, data integration module and external interface module, such as Figure 4 shown.

[0086] (1) The task management module traverses all tasks declared in the high-level language script. If a task is marked as "MC execution", it converts the task into bytecode through the compiler or post-processor during the startup phase and sends it to the corresponding MCU through the communication module. For tasks executed locally on the host side, they are directly triggered by the task management module on a periodic basis.

[0087] (2) Self-task scheduling module: It can run multiple cycles or event-triggered tasks (such as high-computing algorithms, data aggregation, and visualization interfaces) simultaneously. These tasks will update the relevant variables and states in the host memory after each cycle. Thanks to the powerful computing power and rich library support of the host, it can run high-complexity operations such as image recognition and path planning.

[0088] (3) Data Communication and Synchronization Module: After receiving the data packets sent to the host in each control cycle (a control cycle is a periodic execution of the program, which is also a communication between the MCU and the host + memory recycling management), the module parses the updated items such as "lower-level signals" and "static variables" and integrates these contents into the global data model. After the parsing is completed, the data communication and synchronization module packages the values required by the MCU in the "upper-level signals" and "static variables" maintained in its own memory and sends them back to the MCU, so that both ends are synchronized in both directions in each cycle.

[0089] (4) Data integration module: Multiple MCUs or multiple tasks can exist in parallel. The host side will uniformly map and normalize all data from the MCU or other sources to form a global data memory. When the upper-level system (such as a remote server or user interface) needs to access lower-level control data or issue new control commands to the MCU, it can interact with the host side through interfaces such as HTTP and WebSocket. The host will uniformly process and forward the data, realizing the connection and expansion of multi-level control.

[0090] (5) External interface module, providing external system read and write capabilities: For external system access requirements, the present invention supports writing "upper-level information" or reading "lower-level information" and can utilize the host's powerful operating environment for security verification, permission management, and data logging. In this way, the host can maintain high-frequency two-way communication with the MCU internally and provide a friendly external interface, allowing upper-level business systems or cloud platforms to flexibly manage and monitor the device.

[0091] In summary, the host achieves a collaborative division of labor between real-time control and high-performance computing through unified multi-tasking management and bidirectional data synchronization with the MCU. Furthermore, the flexible interfaces provided to external systems further simplify integration with upper-layer platforms and improve development and maintenance efficiency.

[0092] Example: Self-driving forklifts

[0093] To illustrate the application of the present invention in actual industrial scenarios, the following uses an unmanned forklift as an example:

[0094] 1. MCU side

[0095] Motor FOC and PID control are executed at a high-speed cycle (e.g. 10ms) to achieve real-time and precise adjustment of the travel and steering motors.

[0096] Handle sudden emergency stop signal: if triggered, immediately cut off the motor output.

[0097] At the end of each cycle, the lower-level signals such as steering wheel position, speed, load sensor value, etc. are uploaded to the host.

[0098] The above operations require extremely high real-time performance and stability, so they are implemented on the MCU side by combining the bytecode interpretation and execution of the present invention with the underlying native functions.

[0099] 2. Host side

[0100] Control the forklift's indicator lights and broadcast warning statements according to the upper signal

[0101] The target pallet position data (coordinates) is identified based on the lidar data as a lower-level signal.

[0102] Connecting to a higher-level system, such as an intelligent driving system: it writes higher-level signals (wheel speed, direction, indicator lights, and alarm text) and reads lower-level signals (pallet identification data).

[0103] The above requirements all involve long-term control, high computing power, or non-hard real-time requirements. For example, indicator light switching cycles are long, speech synthesis of alarm text requires high computing power, and pallet identification data requires both computing power and high precision and frequency.

[0104] When debugging is required, developers can simultaneously view the host's high-computing logic and the MCU's real-time control process in the IDE, greatly improving debugging efficiency.

[0105] This example demonstrates the application of the present invention in the scenario of autonomous driving of industrial vehicles: by writing in the same high-level language and reasonably dividing tasks, the MCU side ensures high real-time control, and the host side is responsible for high computing power and overall scheduling, ultimately achieving an efficient process of unified development and collaborative debugging.

[0106] Those skilled in the art will understand that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art will understand that they can still modify the technical solutions described in the above embodiments, or make equivalent replacements for some or all of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope defined by the claims of the present invention.

Claims

1. A method for controlling intelligent devices in a heterogeneous computing environment, characterized in that: The intelligent device includes a host side and an MCU side, and the method includes: S1. Write function control code in the same high-level language, add a specified mark to the entry function executed on the MCU side, and call the corresponding basic service function where the MCU hardware IO needs to be accessed; S2. Convert the function executed by the MCU in the function control code into lightweight bytecode and transmit it to the MCU; S3: Only periodic real-time function control, sensor reading, and actuator operation writing tasks are sent to the MCU for execution.

2. The intelligent device control method according to claim 1, characterized in that: Declare the basic service function in the host-side project, retain the corresponding function signature and call entry; implement the basic service function in C or assembly form in the MCU-side firmware, and call it through the function mapping table when the bytecode is running.

3. The intelligent device control method according to claim 1, wherein: In S2, the post-processor of the compiler is used to scan the project corresponding to the task code, and based on the calling relationship, the function set required by the MCU is compiled, and the function set is compiled into a lightweight bytecode that can be interpreted by the MCU.

4. The intelligent device control method according to claim 1, wherein: In S3, the methods executed by the MCU include: S31, the MCU virtual machine is triggered according to the preset cycle when running, and the entry function is pushed into the execution stack; S32, interpreting and executing bytecode instructions one by one; S33, recording which variables need to be exchanged with the host are written; S34. When the execution stack is completely exited, it indicates that the execution of this cycle is completed; the written upper signal, lower signal and static variable value are sent to the host side.

5. The intelligent device control method according to claim 4, characterized in that: In S32, when a native function call is encountered, execution jumps directly; if it is a function expressed in bytecode, it is pushed into the execution stack for execution, and the execution stack is popped after the function execution is completed.

6. The intelligent device control method according to claim 4, characterized in that: When executing on the MCU side in S3, if a communication delay or network failure occurs, the MCU side keeps its own control loop running independently and keeps the bytecode interpretation loop running. It also continues to execute the safety logic written in a high-level language when the host fails. After the host is restored, data synchronization and update are performed.

7. The intelligent device control method according to claim 1, characterized in that: The MCU side also includes driver modules for various resources on the MCU, a communication module for sending or receiving data to the host, and generates corresponding firmware to be burned into the MCU.

8. The intelligent device control method according to claim 1, characterized in that: Memory management methods on the MCU side include: (1) Using a linear allocation strategy, objects created within a cycle are allocated sequentially along a fixed direction; (2) Lightweight memory cleanup at the end of the cycle.

9. The intelligent device control method according to claim 8, characterized in that: Lightweight memory defragmentation includes: initially marking all objects as to be cleaned up, identifying and marking static objects and communication data objects that need to be retained, recursively marking other objects referenced by retained objects, calculating the total space requirements of retained objects after marking is completed, and tightly arranging and reorganizing retained objects to achieve memory regularity.

10. The intelligent device control method according to claim 1, wherein: The host side includes task management module, self-task scheduling module, data exchange and synchronization module, among which, The task management module traverses all tasks declared in the high-level language script. If a task is marked as "MCU execution", it converts the task into bytecode through the compiler or post-processor during the startup phase and sends it to the corresponding MCU through the communication module. Its own task scheduling module runs multiple cycles or event-triggered tasks, and updates the relevant variables and states in the host memory after each cycle is completed; The data exchange and synchronization module receives the data packets sent by the MCU in each cycle, parses the updates of the lower-level signals and static variables, and integrates the updates into the global data model. At the same time, it sends the upper-level signals and static variables maintained in its own memory back to the MCU.

Images