Flight control program intelligent adaptation method and system oriented to heterogeneous processing architecture

Abstract

The invention relates to a flight control program intelligent adaptation method and system oriented to a heterogeneous processing architecture, and solves the technical problems of low efficiency, strategy solidification, difficulty in knowledge reuse and the like when a flight control program is manually transplanted to a domestic or novel chip in the prior art. And automatically generating a customization strategy containing environment configuration, a peripheral list, a test path and branch planning. Accordingly, a debugging environment is automatically deployed, a drive code is generated, and parallel development branches are initialized. An event-driven and dependent sensing mechanism is adopted, verification tasks are dynamically scheduled, code integration is coordinated, hardware abstraction layer configuration and interface codes are intelligently adjusted, a flight control program image is finally and automatically constructed, and efficient and reliable heterogeneous chip flight control program intelligent adaptation is achieved. The method has the following technical effects that automatic intelligent adaptation of the flight control program to the heterogeneous chip is realized, the transplantation efficiency and the code quality are greatly improved, and reusable adaptive knowledge assets are formed.

Description

Technical Field

[0001] This invention relates to the technical field of embedded system software development, and in particular to a method and system for intelligent adaptation of flight control programs for heterogeneous processing architectures. Background Technology

[0002] The flight control system is the core control unit of an unmanned aerial vehicle (UAV). Currently, mainstream open-source flight control systems (such as ArduPilot and PX4) mainly support foreign chips and lack support for domestically developed chips, which restricts the independent development of my country's UAV industry.

[0003] To port open-source flight controllers to domestically produced chips, existing technologies typically employ a manual adaptation method. This method requires manually setting up a debugging environment, rewriting the underlying drivers for the operating system, and modifying the configuration and interface code of the hardware abstraction layer. The entire process relies on the developer's experience and requires multiple people to collaborate on code management and integration testing.

[0004] However, this method has significant drawbacks: it is inefficient, highly dependent on manual labor, and has a long development cycle; the adaptation strategy is rigid and cannot be dynamically optimized based on constraints such as resources and risks; the process is inflexible, and experience in adapting to different chips is difficult to reuse effectively; the verification and integration processes are discrete, rely on manual coordination, are prone to errors, and are complex to manage. Therefore, there is an urgent need for an automated and intelligent adaptation method to improve the development efficiency and reliability of domestically produced chip flight control systems. Summary of the Invention

[0005] In order to achieve automated and intelligent adaptation of flight control programs to heterogeneous chips, significantly improve porting efficiency and code quality, and form reusable adaptation knowledge assets, this application provides a method and system for intelligent adaptation of flight control programs for heterogeneous processing architectures.

[0006] Firstly, this application provides a method for intelligent adaptation of flight control programs to heterogeneous processing architectures, employing the following technical solution: A method for intelligent adaptation of flight control programs for heterogeneous processing architectures, executed by an adaptation decision engine, includes the following operations: Obtain the hardware description file of the target processing architecture, combine it with the preset set of external constraints and the historical adaptation knowledge base, and generate a customized adaptation strategy through the strategy optimization algorithm. The strategy includes at least the environment configuration, the target peripheral configuration list obtained from the hardware description file, the test and verification path, and the version control branch structure planning optimized for parallel development. Based on the environment configuration section of the strategy, the automated toolchain is invoked to deploy dedicated debugging service components on demand for the target processing architecture, and an online simulation and debugging channel with resource monitoring capabilities is established. Parse the hardware description file to extract the register mapping, interrupt and clock parameters of each peripheral. Based on the parameters, match the general template from the driver template knowledge base and synthesize the underlying driver framework code of each peripheral. According to the branch structure plan, initialize the parallel development branch in the version control system and submit the generated driver framework code to the corresponding branch. In response to the development completion event triggered by committing code on any development branch, the automated verification of ready peripheral drivers is dynamically scheduled based on the test and verification path and the real-time status of simulation resources. After the peripheral driver is verified, for each verified peripheral driver, a corresponding hardware abstraction layer configuration change instruction is generated based on the hardware description file; the debug channel is invoked to debug the hardware abstraction layer configuration file and interface code corresponding to the peripheral one by one; After the hardware abstraction layer of all necessary peripherals has been debugged, the source code of the target flight control program's hardware abstraction layer is parsed, the dependencies between peripherals are automatically identified, and the order of merging code from each development branch to the main branch is dynamically coordinated based on the relationship. The integration pipeline executes the build and test processes, and after the integration conditions defined by the strategy are met, it triggers the build and output of the final flight control program image.

[0007] By adopting the above technical solutions and implementing strategy-driven, fully automated processes, efficient and reliable adaptation of flight control programs to heterogeneous chips has been achieved. The technical benefits are significant: the porting cycle is greatly shortened, reducing reliance on expert experience; code quality and consistency are improved, and human error is reduced through intelligent verification and dependency coordination; reusable knowledge assets are formed, and historical adaptation experience is accumulated and optimized. Ultimately, this provides intelligent support for the rapid adoption and ecosystem development of domestically produced chips.

[0008] Secondly, this application provides a flight control program intelligent adaptation system for heterogeneous processing architectures, employing the following technical solution: A flight control program intelligent adaptation system for heterogeneous processing architecture includes a memory, a processor, and a program stored in the memory and executable on the processor. When the program is loaded and executed by the processor, it implements the flight control program intelligent adaptation method for heterogeneous processing architecture as described in the first aspect. Attached Figure Description

[0009] Figure 1 This is a flowchart illustrating a method for intelligent adaptation of flight control programs to heterogeneous processing architectures according to an embodiment of this application. Detailed Implementation

[0010] The present application will be further described in detail below with reference to the accompanying drawings.

[0011] Reference Figure 1This application discloses a method for intelligent adaptation of flight control programs to heterogeneous processing architectures, which is executed by an adaptation decision engine. The operations performed by the engine include: Step S1: Obtain the hardware description file of the target processing architecture. Combine this with a pre-defined set of external constraints and a historical adaptation knowledge base. Then, generate a customized adaptation strategy using a strategy optimization algorithm. The strategy should include at least the environment configuration, a list of target peripheral configurations obtained from parsing the hardware description file, a test and verification path, and a version control branch structure plan optimized for parallel development. The adaptation decision engine is an intelligent software module designed to provide decision support for the adaptation process of the UAV flight control system. It generates the optimal adaptation strategy by parsing the hardware description file, combining project constraints, and utilizing historical adaptation experience. Its main functions include: Hardware Description File Parsing: The adaptation decision engine can read and parse the hardware description file of the target processing architecture, extracting key information such as chip model, peripheral resource list, register mapping, interrupt vector distribution, and memory mapping characteristics. For example, for Xiaohua Semiconductor's HC32 chip, the engine can extract detailed information about all its peripherals, such as SPI, I2C, and UART.

[0012] External constraint integration: The adaptive decision engine incorporates external constraints (such as development cycle, cost budget, performance indicators, supply chain risks, etc.) into the decision-making process and quantifies them as inputs to the optimization algorithm.

[0013] Historical adaptation knowledge utilization: The adaptation decision engine combines experience from the historical adaptation knowledge base (such as success patterns and typical problem avoidance solutions) to avoid repeating mistakes and optimize the adaptation path.

[0014] Strategy Optimization and Generation: The adaptation decision engine uses built-in optimization algorithms (such as multi-objective particle swarm optimization) to solve multi-objective optimization problems using hardware characteristics, quantization constraints, and historical experience data as input, ultimately outputting a customized adaptation strategy. One of the core outputs of this strategy is version control branch structure planning. For example, for a project with 5 engineers that needs to adapt to 18 peripherals, the algorithm will plan a Git repository structure containing 1 main branch, 1 integration branch, and 18 feature branches, and clarify the collaborative relationships between the branches, laying the foundation for parallel development.

[0015] Step S2: Based on the environment configuration section of the strategy, the automated toolchain is invoked to deploy dedicated debugging service components on demand for the target processing architecture, establishing an online simulation and debugging channel with resource monitoring capabilities. The environment configuration section of the customized adaptation strategy specifies the exact type and version of the required debugging toolchain. For example, the strategy might specify using Eclipse as the integrated development environment (IDE) and pyocd as the debugging server, specifying their version numbers.

[0016] The automated toolchain then performs deployment: First, the specified debug server software package is installed and configured on the local development host, loading debug protocol support compatible with the target chip (e.g., HC32). Next, the corresponding client plugin is installed in the IDE, and communication connection parameters and chip simulation configuration files are configured. Then, a connection is established with the local debug server via the plugin, forming a stable communication link with the target flight control board. Finally, a resource monitoring agent is deployed to collect information such as connection status and data throughput in real time, completing the initialization of the debug channel.

[0017] For details on the process, please refer to steps S21 to S25, which will not be elaborated here.

[0018] Step S3 involves parsing the hardware description file to extract register mappings, interrupts, and clock parameters for each peripheral. Based on these parameters, a general template is matched from the driver template knowledge base, and the underlying driver framework code for each peripheral is synthesized. Following the branch structure plan, a parallel development branch is initialized in the version control system, and the generated driver framework code is submitted to the corresponding branch. Specifically, for domestically produced gyroscope sensors, the system prioritizes matching and generating their driver framework code to ensure rapid adaptation and efficient operation in the flight control system. For example, the system generates corresponding initialization functions, data reading functions, and interrupt handling functions based on the gyroscope's register addresses, interrupt vectors, and other information in the hardware description file. Following the branch structure plan, a parallel development branch is initialized in the version control system, and the generated driver framework code is submitted to the corresponding branch.

[0019] The driver template knowledge base contains a collection of standardized driver code templates used to generate basic driver code frameworks for different peripherals. It can be obtained by the development team building and maintaining it themselves based on common hardware architectures and programming standards, or by referring to template resources from the open-source community. The version control system, such as Git, is a tool used to manage code versions. It can be obtained by installing the corresponding software (such as a Git client) and configuring the project repository.

[0020] The necessary processes are as follows: 1. Hardware Description File Parsing: The system first reads the hardware description file of the target processing architecture and extracts key information, such as peripheral resource lists, register mappings, interrupt and clock parameters. For example, for the HC32 chip, its hardware description file is parsed to obtain information such as register addresses, interrupt priorities, and clock sources for peripherals such as SPI, I2C, and UART. This process is implemented by writing a parsing script, which reads the hardware description file (usually in XML or JSON format) and extracts the required data. 2. Matching Driver Templates and Generating Code Framework: Based on the extracted hardware parameters, the system matches a general template from the driver template knowledge base to generate the underlying driver framework code for each peripheral. For example, for the SPI peripheral, the system finds the SPI driver template from the template library and, combined with information such as the SPI register addresses in the hardware description file, generates the basic driver code framework for the SPI peripheral. The code generation tool automatically fills in the key parameters in the template, such as initialization functions and data read / write interfaces. 3. Version Control Branch Structure Initialization: According to the version control branch structure plan in the adaptation strategy, parallel development branches are initialized in the version control system (such as Git). For example, the strategy plans one main branch, one integration branch, and multiple feature branches (such as feature / spi1, feature / i2c1, etc.). The system automatically creates these branches and commits the generated driver framework code to the corresponding feature branch. This process is automated through scripts, ensuring that the development of each peripheral driver is carried out on an independent branch, supporting parallel development by multiple developers. 4. Commit Driver Framework Code: The generated driver framework code is automatically committed to the corresponding feature branch. For example, the driver framework code for the SPI peripheral is committed to the feature / spi1 branch, and the driver framework code for the I2C peripheral is committed to the feature / i2c1 branch. The commit message includes information such as the peripheral name and driver framework version, facilitating subsequent development and debugging by developers. 5. Development Environment Preparation Completed: At this point, the system has completed the process from parsing the hardware description file to generating the driver framework code and has initialized parallel development branches in the version control system. Developers can further develop and debug the peripheral driver code on their respective feature branches without interfering with each other. This process lays the foundation for subsequent parallel development and code merging.

[0021] Step S4: In response to the development completion event triggered by code submission on any development branch, dynamically schedule the automated verification of ready peripheral drivers based on the test verification path and the real-time status of simulation resources. The test verification path defines the entire process from code submission to completion of automated testing, including test environment preparation, test case execution order, and result feedback. It is obtained through the path defined in the customized adaptation strategy generated by the adaptation decision engine. The real-time status of simulation resources refers to the current status information of hardware resources (such as CPU, memory, peripherals, etc.) in the simulation environment. It is obtained in real-time through interfaces or monitoring modules provided by the simulation tool, such as via JTAG or the debug server's API. Automated verification refers to the process of testing code using automated tools and scripts without manual intervention. It is obtained by integrating existing automated testing frameworks (such as Jenkins, Travis CI, etc.) or developing customized automated test scripts.

[0022] The necessary processes are as follows: 1. Monitoring and triggering of development completion events: The system monitors code commit events on the development branch in real time through the commit hooks configured in the version control system. When developers complete code development and commit to the branch, the commit hook triggers the start of the automated verification process. For example, through Git's post-commit hook, the system can capture commit events and notify the automated testing platform to start the verification task. This method ensures that every code change can enter the verification stage in a timely manner, avoiding delays and errors caused by manual intervention. 2. Dynamic scheduling of test verification paths: The system dynamically schedules verification tasks based on preset test verification paths and the real-time status of simulation resources. First, the system obtains the current resource status of the simulation environment through the simulation tool's API, including information such as CPU utilization, memory usage, and peripheral availability. Then, the system schedules tasks according to their resource requirements and priorities. For example, for tasks with high resource requirements, the system will prioritize scheduling them when resources are sufficient; for low-priority tasks, they are placed in a waiting queue and executed only after resources are released. This dynamic scheduling mechanism ensures the effective use of resources and the efficient execution of verification tasks. 3. Execution and Monitoring of Automated Verification: The automated testing tool executes test cases according to the preset test verification path. Test cases cover multiple aspects of the peripheral driver, including functionality, performance, and boundary conditions. For example, for a UART peripheral driver, test cases include sending and receiving function tests, performance tests at different baud rates, and stability tests under extreme conditions. During testing, the system monitors the execution status and resource usage of tasks in real time to ensure smooth verification. If resource status changes, the system can dynamically adjust the execution order of tasks or pause certain tasks to optimize resource utilization. 4. Feedback and Processing of Test Results: After testing, the system collects and analyzes the test results. If the test passes, the system records the verification result in the version control system and marks the peripheral driver as "verified." If the test fails, the system generates a detailed error report, including failed test cases and error logs, and provides feedback to the developers. Developers can quickly locate and fix problems based on this information. Furthermore, the system can dynamically adjust the scheduling strategy of subsequent tasks based on the test results, such as prioritizing the re-verification of fixed tasks.

[0023] Step S5: After the peripheral driver passes verification, for each verified peripheral driver, generate the corresponding hardware abstraction layer configuration change instruction based on the hardware description file; call the debug channel to debug the hardware abstraction layer configuration file and interface code corresponding to the peripheral one by one.

[0024] The Hardware Abstraction Layer (HAL) configuration change commands are used to modify the HAL configuration file (such as halconf.h) to adapt to the peripheral characteristics of a specific hardware platform. They are obtained by adapting the command set generated by the decision engine based on the hardware description file. The debug channel is the communication link used to debug the HAL configuration file and interface code. It is typically established by debugging tools (such as pyocd and openocd) and connecting to the target hardware. It is obtained by configuring the communication parameters between the debugging toolchain and the target hardware to establish a stable debugging connection.

[0025] The necessary process is as follows: 1. Generation of Hardware Abstraction Layer (HAL) configuration change instructions: After the peripheral driver passes verification, the system generates corresponding HAL configuration change instructions based on the hardware description file. The hardware description file contains detailed information about the peripheral (such as register addresses, interrupt priorities, etc.). The system parses this information to generate change instructions for the HAL configuration file (such as halconf.h). For example, if the hardware description file specifies the register address and interrupt vector of a peripheral (such as SPI), the system will generate corresponding instructions to enable the configuration options of that peripheral. 2. Invoking the debug channel: The system invokes the established debug channel to prepare for debugging the HAL configuration file and interface code. The establishment of the debug channel is based on a preset debug toolchain configuration, such as using Eclipse as the integrated development environment (IDE) and pyocd as the debug server. The system establishes a connection with the local debug server through the debug plugin in the IDE, forming a stable communication link with the target hardware. The initialization of the debug channel includes loading the debug protocol support of the target hardware, configuring communication parameters and the simulation environment. 3. Debugging of the HAL configuration file and interface code: The system debugs the HAL configuration file and interface code corresponding to each verified peripheral one by one. The debugging process includes: Configuration file modification: Based on the generated change instructions, modify the hardware abstraction layer configuration file (such as halconf.h) to enable or disable configuration options for specific peripherals.

[0026] Interface code debugging: The debugging channel verifies the functionality of the hardware abstraction layer interface code. For example, it verifies whether peripheral initialization, data read / write, and other functions are working correctly. During debugging, the system monitors hardware resource status in real time to ensure the stability and accuracy of the debugging process.

[0027] 4. Debugging Result Feedback and Optimization: After debugging is complete, the system collects and analyzes the results. If debugging is successful, the hardware abstraction layer configuration file and interface code are marked as "debugged" and recorded in the version control system. If debugging fails, the system generates a detailed error report, including the failed debugging steps and error messages, to help developers quickly locate and fix the problem. Developers can use this information to optimize the hardware abstraction layer code and re-debug.

[0028] Step S6: After monitoring and confirming the debugging of the hardware abstraction layer (HAL) of all necessary peripherals, the target flight control program's HAL source code is parsed to automatically identify the dependencies between peripherals. Based on these dependencies, the order in which code is merged from each development branch to the main branch is dynamically coordinated. Specifically, the dependencies between peripherals refer to the possible dependencies between different peripheral drivers; for example, the initialization of some peripherals may depend on the configuration of other peripherals. These dependencies are obtained by parsing dependency declarations or comments in the HAL source code or through a pre-defined dependency rule base. The code merging order refers to the order in which code from multiple development branches is merged into the main branch. This order is obtained dynamically through the merging tools and strategies of a version control system (such as Git), combined with the dependency analysis results.

[0029] The necessary processes are as follows: 1. Monitoring the Hardware Abstraction Layer (HAL) debugging completion status: The system continuously monitors the HAL debugging status of all necessary peripherals. Once the HAL debugging of all peripherals is complete, the system prepares to enter the code merging phase. The monitoring mechanism tracks the status of each peripheral driver through status tags (such as "Debugged") in the version control system, ensuring that all necessary peripheral drivers have passed debugging. 2. Parsing the HAL source code: The system parses the HAL source code of the target flight control program to extract the dependencies between peripherals. The parsing process includes: Dependency identification: By analyzing dependency declarations in the source code (such as #include directives, function call relationships, etc.), the dependencies between peripherals can be identified. For example, the initialization function of some peripherals may call the interface functions of other peripherals, indicating that a dependency relationship exists.

[0030] Dependency Graph Construction: The identified dependencies are constructed into a dependency graph for subsequent code merging order planning. The dependency graph is a directed graph where nodes represent peripheral drivers and edges represent dependencies.

[0031] 3. Dynamically Coordinate Code Merging Order: Based on the dependency graph, the system dynamically plans the code merging order from each development branch to the main branch. The merging order planning follows these rules: Dependency Priority Principle: Prioritize merging the driver code of peripherals that they depend on. For example, if peripheral A depends on peripheral B, merge the code for peripheral B first. Conflict Minimization Principle: Minimize conflicts during the merge process. The system analyzes the scope of code changes and prioritizes merging branches with fewer conflicts. Modularization Principle: Divide the merge into functional modules to ensure that each module's code can run and be tested independently after merging.

[0032] 4. Code Merging and Conflict Resolution: The system will gradually merge the code from each development branch into the main branch according to the planned sequence. During the merging process, the system will automatically detect and resolve conflicts. Automatic conflict resolution: For simple conflicts (such as differences in comments or formatting), the system resolves and records them automatically. Manual conflict resolution: For complex conflicts (such as logical conflicts), the system marks the conflict location and notifies the developer to resolve it manually. After the developer resolves the conflict, the system continues the merging process.

[0033] 5. Merge Result Verification: After the code merge is complete, the system automatically runs integration tests to verify whether the merged code meets expectations. Integration tests include functional tests, performance tests, and stability tests to ensure that all peripheral drivers function correctly after the merge. If the tests fail, the system will roll back the merge operation and notify the developers to readjust the code.

[0034] Step S7 involves executing the build and test through the integration pipeline, and triggering the build and output of the final flight control program image after the integration conditions defined by the strategy are met. The final generated flight control program image supports various domestically produced chips and sensors, providing reliable software support for the independent controllability of the UAV flight control system. The integration pipeline refers to a series of automated tools and processes used to execute code building, testing, and deployment. It is obtained by integrating existing continuous integration (CI) tools, such as Jenkins and GitLab CI, and configuring automated scripts and tasks. The integration conditions defined by the strategy refer to the conditions defined in the adaptation strategy generated by the adaptation decision engine, used to determine when to trigger the build and output of the final flight control program. They are obtained by parsing the adaptation strategy file and extracting the integration conditions (such as code coverage, test pass rate, etc.). The flight control program image refers to the final generated executable file or firmware used for deployment on the UAV flight control hardware. It is obtained by compiling and linking the source code of the flight control program.

[0035] Necessary Process Description: 1. Configuration and Startup of the Integration Pipeline: The system configures automated tasks, including code building, testing, and deployment, through an integration pipeline tool (such as Jenkins). The startup trigger for the integration pipeline can be code merging into the main branch, a scheduled task, or manual triggering. For example, the integration pipeline automatically starts after all peripheral driver code is merged into the main branch. 2. Code Building and Compilation: The integration pipeline first executes the code building task, compiling the flight control program's source code into an executable file or firmware. The building process includes: Code fetch: Fetch the latest code from the version control system.

[0036] Preparation of the compilation environment: Configure the compilation toolchain (such as GCC, Keil, etc.) and the compilation parameters for the target hardware.

[0037] Compile and execute: Run the compilation command to generate intermediate files and the final image of the flight control program.

[0038] 3. Automated Test Execution: After code building is complete, the integration pipeline automatically executes test tasks to verify the functionality and performance of the flight control program. Test tasks include: Unit testing: Verifies whether each module functions correctly. Integration testing: Verifies whether the interaction between modules meets expectations. Performance testing: Evaluates the performance metrics of the flight control program, such as response time and resource usage. Stability testing: Simulates the actual operating environment to test the stability of the flight control program.

[0039] 4. Integration Condition Verification: After testing, the system verifies whether the integration conditions defined in the policy are met. Integration conditions may include: Test pass rate: The pass rate of all test cases must reach a preset threshold (e.g., 95%). Code coverage: Code coverage must be no less than a preset value (e.g., 80%). Performance metrics: The performance metrics of the flight control program must meet preset standards. If the integration conditions are met, the system will continue to execute subsequent steps; if not, the system will record the problem and notify the developers to fix it.

[0040] 5. Construction and Output of the Final Flight Control Program Image: Once the integration conditions are met, the system triggers the construction of the final flight control program image. The final construction process includes: Optimized compilation: The code is optimized for compilation to ensure the generated image has optimal performance and minimal size. Firmware packaging: The compiled executable file is packaged into a firmware file suitable for the target hardware platform. Image output: The final flight control program image is output to a specified location, such as local storage, a remote server, or a version control system.

[0041] 6. Results Feedback and Deployment Preparation: The system will provide the development team with the final flight control program image build results and prepare for deployment. If the build is successful, the system will record the image version information and generation time for easy version management and deployment. If the build fails, the system will record detailed error information to help developers quickly locate the problem.

[0042] The generation of customized adaptation strategies through strategy optimization algorithms includes: Step S11: Parse the hardware description file and extract the hardware features of the target processing architecture. The hardware features include a list of peripheral resources, performance parameters, interrupt vector distribution, and memory mapping features.

[0043] The hardware description file (HMRF) is a technical document detailing the target processing architecture, specifying information such as the chip's register addresses, peripheral functions, pin definitions, and performance parameters. Hardware features, extracted from the HMRF, are key information used to guide the generation of the adaptation strategy. These features include a list of peripheral resources, performance parameters, interrupt vector distribution, and memory mapping characteristics. These features directly determine the specific content and priority of the adaptation strategy.

[0044] The necessary process is described below: 1. Hardware Description File Acquisition: First, download the hardware description file (HMRF) of the target chip from the chip manufacturer's official website, such as the technical manual and datasheet. These files are usually provided in PDF or HTML format and contain detailed technical parameters of the chip. For example, for Xiaohua Semiconductor's HC32 chip, its technical manual can be obtained from the official website, which details the chip's register addresses, peripheral functions, and pin definitions. 2. Peripheral Resource List Extraction: Parse the hardware description file to extract all peripherals supported by the target chip and their functions. For example, extract the peripheral resource list from the HC32 technical manual, including the SPI interface (for sensor communication), I2C interface (for connecting external devices), UART interface (for serial communication), and GPIO pins (for general purpose input / output). This process is implemented using regular expressions and text parsing algorithms to ensure the accuracy and completeness of the extracted information. 3. Performance Parameter Extraction: Extract the performance parameters of the target chip from the hardware description file, such as clock speed, RAM size, and Flash capacity. These parameters are used to evaluate the chip's processing and storage capabilities. For example, the HC32 chip has a clock speed of 200MHz, RAM size of 128KB, and Flash capacity of 512KB. These performance parameters are obtained by analyzing the specification table in the technical manual, ensuring that the adaptation strategy meets the project's performance requirements. 4. Interrupt Vector Distribution Extraction: Parse the hardware description file to extract the layout of the interrupt vector table, including interrupt priorities and interrupt handler function addresses. For example, the interrupt vector distribution of the HC32 chip includes multiple priority levels and corresponding interrupt handler function addresses. This process is implemented by parsing the interrupt vector table in the technical manual, ensuring that the interrupt handling logic in the adaptation strategy is correct. 5. Memory Mapping Feature Extraction: Extract the chip's memory space layout from the hardware description file, including the address ranges of the code area, data area, and stack area. For example, the memory mapping features of the HC32 chip include the code area (0x00000000 to 0x00080000), the data area (0x20000000 to 0x20020000), and the stack area (0x20020000 to 0x20040000). This information is obtained by analyzing the storage mapping diagram in the technical manual, ensuring that the storage configuration in the adaptation strategy is reasonable and effective.

[0045] Step S12: Based on the extracted hardware features, the external constraint set is matched and analyzed with the extracted hardware features to determine the urgency of the adaptation task, the upper limit of resource input, and the key performance indicator requirements, thereby generating quantified constraints. The external constraint set consists of a series of constraints defined in the project requirements, including development cycle, cost limit, and performance indicators. These constraints guide the generation of the adaptation strategy, ensuring that the adaptation process meets project requirements. The external constraint set is usually provided by the project manager and exists in the form of a document or configuration file. For example, the project requirements document may specify a development cycle of 3 months, a cost limit of 100,000 yuan, and a main frequency of no less than 200MHz. Hardware features are key information extracted from the hardware description file, including peripheral resource lists, performance parameters, interrupt vector distribution, and memory mapping characteristics. These features directly determine the specific content and priority of the adaptation strategy. Hardware features are obtained by parsing the chip's technical manual and datasheet; for example, information such as the main frequency and RAM size are extracted from the HC32 chip's technical manual. Quantified constraints are specific and measurable constraints generated by combining the external constraints with the hardware features. These conditions guide the urgency of the adaptation task, the upper limit of resource investment, and the requirements of key performance indicators. Quantitative constraints are usually expressed in specific values ​​or ranges, such as an urgency level of "high," a resource investment limit of 100,000 yuan, and a main frequency requirement of no less than 200MHz.

[0046] The necessary process is as follows: 1. Obtaining and parsing the set of external constraints: First, obtain the set of external constraints from the project requirements document. These constraints typically include development cycle, cost ceiling, performance indicators, etc. For example, the project requirements document may specify a development cycle of 3 months, a cost ceiling of 100,000 yuan, and a main frequency of no less than 200MHz. Parse these conditions and convert them into specific parameter values ​​for subsequent analysis. 2. Matching analysis between hardware features and external constraints: Perform matching analysis between the extracted hardware features and external constraints to determine the urgency of the adaptation task, the upper limit of resource input, and the key performance indicator requirements. The specific process is as follows: Urgency Analysis: Assess the urgency of the adaptation task based on the development cycle and hardware characteristics. For example, if the development cycle is short (e.g., 3 months) and the hardware characteristics indicate high chip complexity (e.g., abundant peripheral resources but incomplete documentation), then the urgency is high and needs to be prioritized. Urgency can be quantified using a simple scoring model, such as scoring based on complexity and time urgency; a higher score indicates higher urgency. Resource Allocation Limit Analysis: Assess the resource allocation limit based on the cost limit and hardware characteristics. For example, if the cost limit is 100,000 yuan, and the hardware characteristics indicate the need to purchase specific development boards and debugging tools, these costs need to be allocated reasonably within the budget. Resource allocation can be quantified using a budget allocation model, such as allocating resources based on hardware requirements and budget constraints to ensure that resource allocation does not exceed the limit. Key Performance Indicator Requirement Analysis: Assess the key performance indicator requirements based on performance indicators and hardware characteristics. For example, if the performance indicator requires a clock speed of at least 200MHz, and the hardware characteristics show that the target chip's clock speed is 200MHz, this meets the requirement; however, if the target chip's clock speed is lower than 200MHz, an alternative solution needs to be found. Performance metrics can be quantified using a simple validation model, such as comparing hardware performance with project requirements to ensure that hardware performance meets project needs.

[0047] 3. Generate quantified constraints: Based on the matching analysis described above, generate quantified constraints. These constraints will serve as input for subsequent adaptation strategy generation. For example: Urgency: Based on the urgency analysis results, the urgency level is quantified as "high" or "normal".

[0048] Resource input ceiling: Based on the resource input analysis results, the resource input ceiling is quantified into a specific value, such as 100,000 yuan. Key performance indicators: Based on the performance indicator analysis results, key performance indicators are quantified into specific values, such as a main frequency of not less than 200MHz and a RAM size of not less than 128KB.

[0049] Step S13: Based on hardware characteristics and quantitative constraints, retrieve past adaptation cases with similar hardware characteristics and constraints from the historical adaptation knowledge base, and extract their successful adaptation patterns and typical problem avoidance solutions as historical experience data.

[0050] The historical adaptation knowledge base is a database storing past adaptation cases, including successful adaptation patterns, typical problems, and solutions. This historical experience data is used to optimize current adaptation strategies and avoid repeating mistakes. Successful adaptation patterns include successful adaptation methods and strategies from past cases, such as specific driver development sequences and optimized code structures. Typical problem avoidance solutions address common problems encountered in past adaptation cases and their solutions, such as hardware compatibility issues and performance bottlenecks.

[0051] The necessary process is as follows: 1. Integrating hardware features and quantified constraints: The extracted hardware features (such as clock speed, RAM size, peripheral resources) and quantified constraints (such as urgency, resource investment limits, performance indicators) are integrated to form a comprehensive query condition. This integration process is achieved through feature vectorization to ensure the comprehensiveness and accuracy of the search conditions. For example, hardware features and constraints are converted into a feature vector to facilitate subsequent similarity calculation. 2. Retrieving similar historical adaptation cases: Based on the integrated query conditions, past adaptation cases with similar hardware features and constraints are retrieved from the historical adaptation knowledge base. The retrieval process is achieved through feature matching and similarity calculation to ensure that the most similar historical case to the current adaptation task is found. Specific technical means include: Feature matching: Quickly filter out preliminary matching cases through keyword matching and feature vector comparison. Similarity calculation: Use algorithms such as cosine similarity or Euclidean distance to calculate the similarity between the query conditions and historical cases to ensure the accuracy of search results.

[0052] 3. Extract successful adaptation patterns and typical problem avoidance solutions: Extract successful adaptation patterns and typical problem avoidance solutions from the retrieved historical adaptation cases. Specific technical methods include: Successful Adaptation Pattern Extraction: By analyzing the development sequence, code optimization strategies, and resource allocation schemes in historical cases, reusable success patterns are extracted. For example, analyzing the priority order of driver development in historical cases determines the development order of the current adaptation task.

[0053] Typical Problem Avoidance Solution Extraction: By analyzing hardware compatibility issues, performance bottlenecks, and development efficiency problems encountered in historical cases, corresponding avoidance solutions are extracted. For example, specific methods for resolving hardware compatibility issues in historical cases are extracted to provide a reference for current adaptation tasks.

[0054] Step S14 involves using hardware characteristics, quantification constraints, and historical experience data as input, and then performing multi-objective optimization through a strategy optimization algorithm. The final result is a customized adaptation strategy that includes environment configuration, a list of target peripheral configurations, test and verification paths, and a version control branch structure plan optimized for parallel development. The necessary processes described above can be referenced in steps S141 to S145, and will not be elaborated upon here.

[0055] Using hardware characteristics, quantification constraints, and historical experience data as input, a multi-objective optimization solution is obtained through a strategy optimization algorithm. The final result is a customized adaptation strategy that includes environment configuration, a list of target peripheral configurations, test and verification paths, and a version control branch structure plan optimized for parallel development. Step S141: Based on quantified constraints, determine at least three parallel optimization objectives, including an adaptation cycle objective, a driver stability objective, and a supply chain risk objective. The adaptation cycle objective is determined based on the urgency requirements in the quantified constraints; the driver stability objective is determined based on the peripheral resource list in the hardware features; and the supply chain risk objective is determined based on a pre-defined component supply risk level mapping relationship and the corresponding component models for each peripheral in the hardware features. Quantified constraints are specific and measurable constraints generated by combining external constraints with hardware features. These constraints guide the urgency, resource investment limits, and key performance indicator requirements of the adaptation task. For example, if the urgency level is "high," the resource investment limit is 100,000 yuan, and the main frequency requirement is no less than 200MHz. The adaptation cycle objective, determined based on the urgency requirements in the quantified constraints, aims to minimize the completion time of the adaptation task. For example, if the urgency level is "high," the adaptation cycle objective might be to control the development cycle within 3 months. The driver stability objective, determined based on the peripheral resource list in the hardware features, aims to ensure the stability and reliability of the driver program. For example, if the hardware features indicate abundant peripheral resources (such as SPI, I2C, UART, GPIO), the driver stability objective might be to ensure high stability for all peripheral drivers. Supply chain risk objective: This optimization objective, determined based on a pre-defined component supply risk level mapping and the corresponding component models for each peripheral in the hardware features, aims to minimize supply chain risk. For example, if the supply risk of certain components is high, the supply chain risk objective might be to select alternative components with stable supply.

[0056] The necessary process is as follows: First, extract urgency requirements from the quantitative constraints. Using time planning models and critical path analysis techniques, assess the urgency of the adaptation task and determine the adaptation cycle target. Specifically, a dynamic time adjustment mechanism is adopted, combined with task decomposition and resource allocation, to compress the development cycle to within 3 months. For example, for the HC32 chip adaptation task, if the urgency level is "high," the system will automatically decompose the task into stages such as low-level driver development, hardware abstraction layer debugging, and integration testing, and allocate specific time windows for each stage. Simultaneously, a 10% time buffer is reserved for critical tasks (such as SPI driver development) to cope with unexpected delays. Critical path identification technology is used to determine which tasks have the greatest impact on the overall schedule, thus prioritizing resource allocation to ensure the adaptation task is completed within the specified time and meets the project's time requirements. Second, based on the peripheral resource list in the hardware characteristics, determine the driver stability target through peripheral complexity analysis and stability assessment models. For each peripheral (such as SPI, I2C, UART, GPIO), assess its functional complexity and criticality, and set the corresponding stability level based on historical failure rate data. For example, for the SPI peripheral of the HC32 chip, if it serves as the communication interface for a main IMU sensor (such as the MPU6050), the system will set its stability level to the highest. For highly complex peripherals, redundant design strategies and fault injection tests are introduced to simulate communication failure scenarios and verify the fault tolerance of the driver. Simultaneously, performance optimization algorithms (such as dynamic voltage and frequency adjustment) ensure stable operation under different loads, thereby ensuring the stability and reliability of the driver during the adaptation process. Finally, based on the preset component supply risk level mapping relationship and the component models in the hardware characteristics, supply risk assessment and alternative component selection algorithms are used to determine the supply chain risk targets. A supply risk score is given for each component, and combined with market research and supplier evaluation, high-risk components are identified and stable alternatives are selected. For example, if the supply risk level of an IMU sensor (such as the MPU6050) on which a critical peripheral of the HC32 chip depends is "high," the system will automatically select a stable alternative model (such as ICM-20602) from the alternative component library and adjust the driver code to adapt to the new sensor. Establish a risk warning mechanism to monitor the dynamics of the supply chain in real time, and ensure timely response to component shortages or supplier issues to avoid project delays caused by supply chain problems.

[0057] Step S142 involves parsing the historical experience data. Successful adaptation cases recorded in the historical experience data are vectorized based on their performance in adaptation cycle, driving stability, and supply chain risk, constructing a historical case feature vector library. Feature vectorization transforms qualitative descriptions in the historical experience data (such as "short adaptation cycle" and "stable driving force") into computable numerical vectors, facilitating subsequent similarity calculations and machine learning processing. This process requires defining clear quantitative indicators and transformation rules. The historical case feature vector library is a database composed of feature vectors from all historical adaptation cases, used for quickly retrieving and matching similar cases. This library uses an efficient index structure (such as KD-Tree or Ball-Tree) for storage, supporting fast similarity queries.

[0058] We conducted in-depth analysis of historical experience data to extract the performance characteristics of each case across three dimensions: adaptation cycle, driver stability, and supply chain risk. Taking the HC32 chip adaptation case as an example, the analysis process is as follows: Adaptation cycle feature extraction: Information such as the actual development cycle, time spent at each stage, and reasons for delays is extracted from project documentation. For example, a record from an HC32 adaptation case shows that the underlying driver development took 4 weeks, hardware abstraction layer debugging took 3 weeks, integration testing took 2 weeks, and the total cycle was 9 weeks. The system normalizes this time data and generates adaptation cycle feature values ​​[0.45, 0.35, 0.20], representing the time percentage of each stage.

[0059] Driver stability feature extraction: Analyze driver failure rates, test pass rates, performance metrics, and other data in the case studies. For example, in this HC32 case, the SPI driver failure rate is 2%, the I2C driver failure rate is 5%, and the IMU driver failure rate is 1%. The system generates a stability feature vector [0.98, 0.95, 0.99] based on a weighted average of the inverse of the failure rate, where a value closer to 1 indicates greater stability.

[0060] Supply chain risk feature extraction: Identify the key component models, supplier information, procurement cycles, and supply interruption records used in the case. For example, the MPU6050 sensor used in the HC32 case experienced a 3-week supply delay. The system generates supply chain risk features [0.9] based on a preset risk level mapping (e.g., 1-week delay = risk value 0.3, 3-week delay = risk value 0.9).

[0061] Feature vectorization and vector library construction: The extracted feature values ​​are combined into high-dimensional vectors, with each historical case corresponding to a feature vector. For example, the feature vector of the HC32 case mentioned above can be represented as [0.45, 0.35, 0.20, 0.98, 0.95, 0.99, 0.9], where the first three dimensions are adaptation cycle features, the middle three dimensions are driving stability features, and the last dimension is supply chain risk features.

[0062] Step S143: Based on the historical case feature vector library, retrieve several historical cases with the highest similarity to the current hardware features, current quantization constraints, and supply chain risk objectives. Extract the strategy decision paths corresponding to these historical cases and encode them into the initial particle swarm for the multi-objective particle swarm optimization algorithm. The strategy decision path is the specific adaptation strategy execution sequence recorded in the historical cases, including the operation steps and parameter settings for environment configuration, target peripheral configuration list, and testing and verification paths. This path information is automatically extracted from the version control system's commit history and project documents. The multi-objective particle swarm optimization algorithm is a swarm intelligence-based optimization algorithm that finds the Pareto optimal solution set for multi-objective problems by simulating the flight behavior of particles in the solution space. Each particle represents a candidate strategy; its position vector corresponds to the strategy parameters, and its velocity vector determines the direction of parameter adjustment. The initial particle swarm is the starting set of particles for the algorithm's iterative search; its quality directly affects the convergence speed and the quality of the final solution. Generating the initial particle swarm through encoding historical cases fully utilizes existing experience and avoids inefficient searches caused by random initialization.

[0063] The necessary process is described below: Similar Historical Case Retrieval: Based on current hardware characteristics (e.g., HC32 chip with a main frequency of 200MHz, RAM of 128KB, and peripheral list) and quantitative constraints (e.g., high urgency, resource limit of 100,000 yuan), the system performs a similarity search in the historical case feature vector database. The system employs a weighted cosine similarity algorithm, assigning differentiated weights (e.g., cycle weight 0.4, stability weight 0.4, risk weight 0.2) to different feature dimensions (e.g., adaptation cycle weight 0.4, stability weight 0.4, risk weight 0.2) to calculate the comprehensive similarity between the current task and historical cases. The system returns the top K cases with the highest similarity (typically K=5~10). For example, if a historical case is adapted to a domestic chip with a main frequency of 180MHz and RAM of 96KB, its similarity score might reach 0.85, and it would be judged as a highly similar case.

[0064] Strategy Decision Path Extraction and Encoding: From similar historical cases, the strategy decision paths are extracted, including environment configuration (e.g., Eclipse + pyocd debugging environment), target peripheral configuration list order (e.g., SPI before IMU), and test verification path (e.g., unit test → integration test → system test). This path information is encoded into the initial particle swarm for the multi-objective particle swarm optimization algorithm. The encoding process uses a feature mapping mechanism to convert strategy parameters into particle position vectors. For example, the target peripheral configuration list is mapped to an integer sequence (SPI=1, I2C=2, IMU=3), and the test path is mapped to a binary mask (unit test=001, integration test=010, system test=100), ultimately generating a multi-dimensional position vector for each particle. Simultaneously, initial velocities are assigned to particles based on the execution performance of historical cases (e.g., on-time completion, stability score), guiding the algorithm to search towards high-performance regions.

[0065] Step S144: Run the multi-objective particle swarm optimization algorithm. Iteratively search in the solution space with the optimization objectives of adaptation cycle, driving stability and supply chain risk. Dynamically update the position and velocity of each particle according to the fitness of each particle. After reaching the preset convergence condition, output a set of Pareto front candidate strategies. Each candidate strategy includes a combination of environment configuration, target peripheral configuration list, test and verification path and version control branch structure planning.

[0066] The multi-objective particle swarm optimization algorithm is an evolutionary algorithm based on swarm intelligence. It simulates the flight behavior of particles in the solution space to simultaneously optimize multiple conflicting objectives. Each particle represents a candidate adaptation strategy; its position vector encodes strategy parameters (such as the target peripheral configuration list and environment configuration), and its velocity vector determines the direction of parameter adjustment. The algorithm iteratively updates particle positions and velocities, gradually approaching the Pareto optimal front. The solution space is a multi-dimensional search space composed of all possible strategy combinations. Its dimensions are determined by decision variables such as environment configuration parameters, the sequence of target peripheral configuration lists, and test / verification path selection. The boundary of the solution space is limited by hardware characteristics and quantization constraints; for example, the number of peripherals on the HC32 chip determines the maximum length of the target peripheral configuration list. The fitness function is a quantification metric used to evaluate the quality of particles. Independent fitness calculation methods are designed for different optimization objectives. For example, the fitness function for the adaptation cycle objective is calculated based on a development time estimation model; the driving stability objective is based on a stability score weighted by peripheral complexity; and the supply chain risk objective is based on a mapping relationship of component supply risk levels. Pareto Frontier Candidate Strategy Set: In the solution space, a set of non-dominated solutions that cannot improve any objective without compromising other objectives. Each candidate strategy corresponds to a complete combination of environment configuration, target peripheral configuration list, and test and verification path, representing a potential adaptation scheme that achieves a balance among the three objectives.

[0067] The necessary process is as follows: 1. Initialization and Iterative Search: Based on the initial particle swarm generated in step S143, a multi-objective particle swarm optimization algorithm is launched in the solution space. The initial position and velocity of each particle are set according to the execution effect of historical cases to ensure the quality of the initial solution. For example, for the HC32 chip adaptation task, the initial particle swarm may include a strategy of "developing the SPI driver first, then the IMU driver", and its initial velocity is set according to the success rate and stability of similar strategies in historical cases. 2. Dynamic Update and Fitness Evaluation: In each iteration, the position and velocity of each particle are dynamically updated according to its fitness. The fitness calculation comprehensively considers three parallel optimization objectives: Adaptation cycle target: Calculate the total development time using a time estimation model, for example, 4 weeks for underlying driver development + 3 weeks for abstraction layer debugging + 2 weeks for integration testing = 9 weeks. Driver stability target: Evaluate using a peripheral complexity-weighted failure rate prediction model, for example, an SPI driver failure rate of 0.02, a weight of 0.4, and a score of 0.98. Supply chain risk target: Calculate a risk score based on the component supply risk level mapping relationship, for example, an MPU6050 risk value of 0.9.

[0068] The fitness function combines the three objectives mentioned above to assign a comprehensive score to each particle. For example, a particle representing the strategy of "prioritizing the development of drivers corresponding to high-supply-risk components" scores highly on the supply chain risk objective, but may sacrifice the adaptation cycle. The algorithm balances this trade-off through the fitness function to ensure equilibrium among multiple objectives.

[0069] The following formula is used in the particle velocity update process: .

[0070] .in, Let i be the velocity of particle i; This represents the position of particle i. w=0.7 is the inertia weight. c1=c2=1.5 are the learning factors. rand() is a random number in the range [0,1]. For example, the current position of a particle... If the value represents "SPI priority 1, IMU priority 2", and its pBest is "SPI priority 1, IMU priority 3", and its gBest is "SPI priority 1, IMU priority 2", then... The system will dynamically adjust based on the difference, causing the particles to move to a better position.

[0071] 3. Convergence Judgment and Pareto Front Output: When the preset convergence condition is met (e.g., the number of iterations exceeds 100 or the particle position change rate is less than 1%), the algorithm stops searching and outputs a set of Pareto front candidate strategies. This strategy set contains multiple candidate solutions that achieve different balances among the three objectives. For example, one candidate strategy may emphasize short cycles (optimal adaptation cycle is 8 weeks). Another may emphasize high stability (driving stability score 0.99). A third may emphasize low risk (supply chain risk score 0.1).

[0072] Each candidate strategy includes a clear environment configuration (such as Eclipse + pyocd debugging environment), a target peripheral configuration list (such as SPI → IMU → PWM), and a test verification path (such as a combination of unit test → integration test → system test), providing rich options for subsequent strategy selection.

[0073] Step S145: Based on the upper limit of resource input and key performance indicator requirements in the quantitative constraints, and combined with the optimization goal of parallel development efficiency, the Pareto frontier candidate strategy set is screened and evaluated, and the candidate strategy that satisfies all constraints and is optimal in comprehensive evaluation is selected as the final customized adaptation strategy.

[0074] Among these, the resource investment ceiling refers to the maximum resource investment limit for the adaptation task defined in the quantitative constraints, such as 100,000 yuan. This limit is used to ensure that the adaptation process is completed within the budget. Key performance indicator requirements are the performance requirements that the adaptation task must meet as defined in the quantitative constraints, such as a mains frequency of no less than 200MHz and RAM size of no less than 128KB. These indicators are used to ensure that the adapted system can meet the basic performance requirements of the project.

[0075] The necessary processes are described below: 1. Resource Input Screening: First, candidate strategies are screened based on the upper limit of resource input. For example, if the upper limit of resource input is 100,000 yuan, all candidate strategies with an expected resource input not exceeding 100,000 yuan are screened. This process is achieved by evaluating the resource requirements (such as development tools, testing equipment, and human resource costs) of each candidate strategy. 2. Key Performance Indicator Screening: Second, candidate strategies are screened based on key performance indicator requirements. For example, if the key performance indicators require a main frequency of not less than 200MHz and a RAM size of not less than 128KB, all candidate strategies that meet these performance requirements are screened. This process is achieved by evaluating the hardware configuration and performance prediction of each candidate strategy. 3. Comprehensive Evaluation: A comprehensive evaluation is conducted among the candidate strategies that meet the upper limit of resource input and key performance indicator requirements. The comprehensive evaluation considers the balance of three objectives: adaptation period, driver stability, and supply chain risk. For example, the comprehensive score of each candidate strategy is calculated using the following formula: Comprehensive Score = α × Adaptation Period Score + β × Driver Stability Score + γ × Supply Chain Risk Score. Wherein, α, β, and γ are the weights of adaptation period, driver stability, and supply chain risk, respectively, set according to project requirements. For example, α=0.4, β=0.3, γ=0.3.

[0076] 4. Final Strategy Determination: Select the candidate strategy with the highest overall score as the final customized adaptation strategy. For example, suppose there are three candidate strategies after screening: Candidate Strategy A: Adaptation period 8 weeks, driver stability score 0.95, supply chain risk score 0.2, overall score 0.85. Candidate Strategy B: Adaptation period 9 weeks, driver stability score 0.99, supply chain risk score 0.1, overall score 0.88. Candidate Strategy C: Adaptation period 7 weeks, driver stability score 0.90, supply chain risk score 0.3, overall score 0.82.

[0077] After comprehensive evaluation, candidate strategy B received the highest overall score, and therefore B was selected as the final customized adaptation strategy.

[0078] Based on the environment configuration section of the strategy, the automated toolchain is invoked to deploy dedicated debugging service components on demand for the target processing architecture, establishing an online simulation and debugging channel with resource monitoring capabilities, including: Step S21: Analyze the environment configuration part of the customized adaptation strategy, determine the type and version of the required debugging service components, and select the corresponding debugging server software package and integrated development environment client plugin from the automation toolchain.

[0079] The automation toolchain is a set of tools for automating the deployment and configuration of development environments, including package managers (such as apt and pip) and configuration scripts (such as bash scripts). These tools simplify the environment setup process and ensure consistency and repeatability of environment configuration. The debugging service components are software modules that support hardware debugging, such as GDB servers and emulator plugins. These components enable functions such as code debugging and resource monitoring.

[0080] The necessary process is as follows: First, extract environment configuration information from the customized adaptation strategy to clarify the type and version of the required debugging service components. For example, the strategy file may specify the use of Eclipse as the integrated development environment (IDE) and require the installation of a specific version (e.g., 0.34.3) of the pyocd debugging server package and its client plugin. This process is implemented through automated scripts to ensure accurate extraction of configuration information. Next, based on the extracted information, accurately select the matching debugging server package and IDE client plugin from the automated toolchain. The specified version of the pyocd package is automatically downloaded and installed using a package management tool (e.g., pip), while the corresponding client plugin is installed in Eclipse. This process is seamless, ensuring compatibility between components and the target hardware architecture. For example, suppose the environment configuration section of the customized adaptation strategy specifies Eclipse IDE and the pyocd debugging server package (version 0.34.3) and its client plugin (version 1.2.0). The automated script will read this configuration information, install the pyocd debugging server package through the package management tool, and install the corresponding client plugin in Eclipse, ensuring that the versions of all components are consistent with the versions specified in the strategy file.

[0081] Step S22: On the local development host, install and configure the selected debug server software package, ensuring it loads debug protocol support compatible with the target processing architecture, and start the debug server's background service process. Here, the components are: Local development host: This is the computer used by developers to write and debug code, typically equipped with necessary development tools and environments. Debug server software package: This is a software module supporting hardware debugging, such as the pyocd debug server, which enables code debugging, resource monitoring, and other functions. Target processing architecture: This is the compatible target hardware platform, such as the HC32 chip from Xiaohua Semiconductor. Debug protocol support for the target processing architecture is crucial for ensuring the debug server can communicate with the hardware. Debug protocol: This is the protocol used for communication between the debug server and the target hardware, such as the GDB protocol or a specific chip's debug protocol. The debug server needs to load debug protocol support compatible with the target hardware. Background service process: This is a background process started on the local development host when the debug server runs, continuously listening for debug requests and processing debug tasks.

[0082] The specific process is as follows: On the local development host, based on the debug server software package and its version information specified by the customized adaptation strategy, the debug server software package is installed using a package management tool (such as pip), and its support for the debug protocol matching the target processing architecture (such as the HC32 chip) is configured. Finally, a background service process is started to ensure the stable operation of the debugging function. For example, if the policy file specifies the use of the pyocd debug server (version 0.34.3), the system will automatically install this version of the pyocd software package, configure it to support the debug protocol of the HC32 chip through configuration files or command-line parameters, and then start the background service process to run continuously in the background, responding to debugging requests at any time. This process is driven by automated scripts, ensuring the consistency and accuracy of installation, configuration, and startup, providing stable support for hardware debugging.

[0083] Step S23: In the integrated development environment (IDE), install the selected client plugin, configure the communication connection parameters with the local debug server through the plugin, and load the simulation configuration file for the target processing architecture. The specific process is described below: In the IDE, install the matching client plugin according to the debug server type (e.g., pyocd) specified by the customization adaptation strategy. For example, for the pyocd debug server, search for and install the pyocd client plugin using Eclipse's plugin management function, ensuring its version is compatible with the debug server. After installation, configure the communication connection parameters with the local debug server through the client plugin, including the server address (e.g., localhost) and port number (e.g., 3333), ensuring the IDE can establish a stable connection with the debug server. Simultaneously, load the simulation configuration file for the target processing architecture (e.g., the HC32 chip). This file contains parameters such as the chip's clock frequency and peripheral initialization, enabling the IDE to simulate the target hardware environment for debugging. For example, the simulation configuration file might specify the HC32 chip's clock frequency as 200MHz, and peripheral initialization including SPI and I2C interfaces. This process is assisted by automated scripts, ensuring the accuracy of plugin installation, communication configuration, and simulation environment setup, and providing stable support for subsequent online simulation and debugging.

[0084] Step S24: A connection request is initiated to the locally running debug server via a client plugin in the integrated development environment (IDE) to establish a stable communication link with the target processing architecture flight controller board, thus forming an online simulation and debugging channel. The specific process is as follows: In the IDE, a connection request is initiated to the locally running debug server (e.g., the pyocd debug server) via an installed client plugin (e.g., the pyocd client plugin). This request is based on previously configured communication parameters (e.g., server address localhost and port number 3333) to ensure a stable connection with the debug server. After a successful connection, the client plugin further establishes a communication link with the target processing architecture flight controller board (e.g., the HC32 chip), forming an online simulation and debugging channel. For example, if the target hardware is an HC32 chip, the client plugin will connect to the HC32 chip through the debug server, allowing developers to monitor the hardware status in real time within the IDE, set breakpoints, step through the code, and test the functionality of the flight control program in the simulation environment. This process is assisted by automated scripts, ensuring connection stability and the availability of debugging functions, providing efficient support for the adaptation and development of the flight control system.

[0085] Step S25: After the online simulation and debugging channel is established, deploy a resource monitoring agent to collect and report the channel's connection status, data throughput, and simulator load information in real time, thus completing the initialization of the resource monitoring capability of the debugging channel.

[0086] For details on the specific process, please refer to steps S251 to S253, which will not be elaborated here.

[0087] Deploy a resource monitoring agent to collect and report channel connection status, data throughput, and simulator load information in real time, completing the initialization of resource monitoring capabilities for the debugging channel, including: Step S251: Inject lightweight monitoring probe code modules for collecting runtime metrics into the background service process and client plugin of the debug server software package, respectively. The monitoring probe code modules are lightweight monitoring code snippets used to collect runtime performance metrics and status information. These code modules are typically integrated into the debug server and client plugins as plugins or scripts. Runtime metrics are performance and status data generated during the operation of the debug server and client plugins, such as connection status, data throughput, and emulator load.

[0088] The necessary process is described below: 1. Inject monitoring probe code modules: Inject lightweight monitoring probe code modules for collecting runtime metrics into the background service process and client plugin of the debug server software package. For example, for the pyocd debug server, inject the monitoring probe code module by modifying its source code or using a plugin mechanism. These code modules can collect runtime metrics of the debug server and client plugin in real time, such as connection status, data throughput, and emulator load information. 2. Configure monitoring probes: Configure the monitoring probes to collect the monitoring metrics to ensure that they can collect connection status, data throughput, and emulator load information of the online simulation and debug channels. For example, configure the monitoring probes to collect connection status once per second, data throughput once every 10 seconds, and emulator load information once per minute. These configurations can be completed through configuration files or command-line parameters to ensure that the metric collection function of the monitoring probes meets the project requirements. 3. Start the metric collection function of the monitoring probes: Start the metric collection function of the monitoring probes to begin collecting runtime metrics. For example, activate the metric collection function of the monitoring probes by calling the startup interface of the monitoring probes or sending a specific startup command. The monitoring probe will collect runtime data from the debug server and client plugin in real time according to the configured frequency and metric list. A specific example is as follows: Assume the target hardware is an HC32 chip, the debug server is pyocd (version 0.34.3), and the client plugin is the pyocd plugin in Eclipse. The monitoring probe code module is injected into the background service process of the pyocd debug server by modifying its source code or using a plugin mechanism. The monitoring probe is configured to collect connection status once per second, data throughput once every 10 seconds, and emulator load information once per minute. After starting the metric collection function of the monitoring probe, it will collect runtime data from the debug server and client plugin in real time, providing basic data support for subsequent resource monitoring.

[0089] Step S252: Configure the monitoring metrics to be collected for the monitoring probe. These metrics include at least the connection status of the online simulation and debugging channels, data throughput, and emulator load information. Then, start the metric collection function of the monitoring probe. Monitoring metrics refer to the runtime data to be collected, including but not limited to the connection status of the online simulation and debugging channels, data throughput, and emulator load information. These metrics are used to evaluate the performance and stability of the debugging environment. Metric collection function: The core function of the monitoring probe, used to collect monitoring metrics at a predetermined frequency and in a predetermined manner, and transmit the data to the monitoring service process.

[0090] The necessary process is described below: 1. Configure the monitoring indicators of the monitoring probe: Configure the monitoring indicators to be collected for the monitoring probe to ensure that it can collect key operational data of the online simulation and debugging channel. The monitoring indicators should include at least: Connection Status: Real-time monitoring of whether the debug channel maintains a connection and the stability of the connection. Data Throughput: Measure the data transmission rate in the debug channel to evaluate communication efficiency. Emulator Load Information: Monitor the emulator's resource usage, such as CPU utilization and memory usage, to evaluate the emulator's operating load. For example, through configuration files or command-line parameters, the frequency of monitoring probes collecting connection status can be set to once per second, data throughput to once every 10 seconds, and emulator load information to once per minute.

[0091] 2. Activate the Monitoring Probe's Metric Collection Function: Activate the monitoring probe's metric collection function to begin collecting runtime metrics at the configured frequency. The monitoring probe will transmit the collected data to the monitoring service process in real time for further analysis and display. For example, the metric collection function can be activated by calling the monitoring probe's startup interface or sending a specific startup command. A specific example is as follows: Assume the target hardware is an HC32 chip, the debug server is pyocd (version 0.34.3), and the client plugin is the pyocd plugin in Eclipse. In the background service process of the pyocd debug server, modify its configuration file to set the monitoring probe's connection status collection frequency to once per second, data throughput frequency to once every 10 seconds, and simulator load information frequency to once per minute. After activating the monitoring probe's metric collection function, the monitoring probe will collect runtime data from the debug server and client plugin in real time and transmit this data to the monitoring service process, providing basic data support for subsequent resource monitoring.

[0092] Step S253: Start an independent monitoring service process, establish a data transmission link between the monitoring probe, the monitoring service process, and the integrated development environment (IDE) user interface, and verify that the monitoring service process can normally receive and display monitoring metrics by sending test data packets and successfully displaying them on the user interface. This completes the initialization of resource monitoring capabilities for the debug channel. The data transmission link is the communication path between the monitoring probe, the monitoring service process, and the IDE user interface, used to transmit the collected monitoring metrics. The data transmission link is typically implemented based on network protocols (such as TCP / IP) or internal message queues to ensure the real-time performance and accuracy of the data. User interface display is the process of displaying monitoring metrics in the IDE's user interface, used to verify whether the monitoring service process can normally receive and process monitoring data. User interface display is usually achieved through a graphical interface or log output, ensuring that users can view monitoring data in real time.

[0093] The necessary process is described below: 1. Start the monitoring service process: Start an independent monitoring service process, running it in the background and preparing it to receive runtime metrics sent by the monitoring probe. The monitoring service process is initialized through configuration files or command-line parameters to ensure it can correctly process and forward monitoring data. 2. Establish a data transmission link: Establish a data transmission link between the monitoring probe, the monitoring service process, and the IDE user interface. The monitoring probe sends the collected monitoring metrics to the monitoring service process via a network protocol (such as TCP / IP), and the monitoring service process then transmits this data to the IDE user interface for display. For example, the monitoring probe sends data to a specified port (such as 5000) of the monitoring service process via a TCP connection, and the monitoring service process then pushes the data to the IDE user interface through an internal message queue. 3. Verify the data transmission link: Verify whether the monitoring service process can normally receive and display monitoring metrics by sending test data packets and successfully displaying them on the user interface. For example, the monitoring probe sends a test data packet containing connection status, data throughput, and simulator load information to the monitoring service process. The monitoring service process receives and processes this data and then displays these metrics in the IDE user interface. If the user interface can correctly display the test data, it indicates that the data transmission link is working properly, and the monitoring service process can normally receive and display monitoring metrics.

[0094] Analyzing the target flight control program's hardware abstraction layer source code and automatically identifying dependencies between peripherals includes: Step S41: Synchronously parse the header configuration file and interface implementation source code of the Hardware Abstraction Layer (HAL), extract all peripheral-related configuration macro definitions, and simultaneously identify the peripheral initialization functions, data transfer functions, and interrupt handling functions associated with these macro definitions in the source code. Specifically: The header configuration file contains HAL configuration macro definitions used to enable or disable the functionality of specific peripherals. These macro definitions are key clues for identifying peripheral configurations. The interface implementation source code contains the specific code that implements the HAL functionality, including peripheral initialization, data transfer, and interrupt handling. This code is implemented through functions and is usually associated with the macro definitions in the header configuration file. Peripheral initialization functions are used to initialize peripherals, typically called during system startup, setting the basic parameters and operating mode of the peripherals. Data transfer functions are used for peripheral data transfer, responsible for sending and receiving data between the host and peripherals. Interrupt handling functions are used to handle peripheral interrupts, typically called when an interrupt occurs, executing interrupt-related processing logic.

[0095] The system synchronously parses the header configuration file and interface implementation source code of the Hardware Abstraction Layer (HAL), extracts peripheral-related configuration macro definitions, and identifies peripheral initialization functions, data transfer functions, and interrupt handling functions associated with these macro definitions in the source code. This process is implemented using code parsing tools to ensure the accuracy and completeness of the extracted information, providing foundational data support for subsequent dependency identification. Specifically, the system first reads the HAL header configuration file and identifies the peripheral-related macros defined within it. These macros are typically used to enable or disable the functionality of specific peripherals. Simultaneously, the system analyzes the interface implementation source code to find functions associated with these macro definitions. For example, for an enabled peripheral, the system identifies its initialization function, data transfer function, and interrupt handling function. The names of these functions usually follow certain naming rules, facilitating identification through static analysis techniques. By synchronously parsing the header configuration file and source code, the system can establish a complete peripheral function mapping table, recording the configuration status of each peripheral and its associated functions. This mapping table provides foundational data support for subsequent dependency analysis.

[0096] Step S42 establishes a unified symbolic mapping relationship between the peripheral identifiers extracted from the configuration macro definitions and their corresponding functions identified in the source code, forming a peripheral function symbol table. The specific process is as follows: The system establishes a unified symbolic mapping relationship between the peripheral identifiers extracted from the hardware abstraction layer configuration file and their corresponding functions identified in the source code. For example, if the configuration file defines an enable identifier for a peripheral, the system will look up the corresponding initialization, data transfer, and interrupt handling functions in the source code. This information is integrated into the peripheral function symbol table, which clearly records the correspondence between each peripheral identifier and its related functions. For example, the peripheral identifier SPI may correspond to the initialization function spi_init, the data transfer function spi_transfer, and the interrupt handling function spi_irq_handler. In this way, the system creates a clear symbolic mapping for each peripheral, providing an accurate data foundation for subsequent dependency analysis.

[0097] Step S43: Based on the peripheral function symbol table, by analyzing the call chains between functions, shared global data structures, and nested call relationships of interrupt service routines, the initialization order dependencies, runtime data dependencies, and interrupt handling dependencies between peripherals are identified. The specific process is detailed in steps S431 to S433, and will not be elaborated here.

[0098] Step S44: Integrate the identified multidimensional dependencies into a directed dependency graph, where nodes represent peripherals and edges represent dependency types and directions. Perform loop detection and consistency verification on the dependency graph and output the verified directed dependency graph as the result of automatic identification.

[0099] The specific process is as follows: The system integrates the identified multidimensional dependencies into a directed dependency graph. In this graph, nodes represent peripherals, and edges represent the type and direction of the dependency. For example, if the initialization of peripheral A depends on the completion of data transmission from peripheral B, there will be an edge in the graph pointing from B to A, marked as "initialization dependency". The system performs loop detection on this graph to ensure that there are no circular dependencies, as circular dependencies may cause the system to fail to initialize or run correctly. At the same time, consistency verification is performed to check whether the dependencies in the graph are consistent with the configuration of the hardware abstraction layer and the source code logic. For example, it verifies whether the initialization order conforms to the calling order in the code. After these verification steps, the system outputs a verified directed dependency graph as the result of automatic identification, providing accurate dependency information for subsequent adaptation and optimization.

[0100] Based on the peripheral function symbol table, by analyzing the call chains between functions, shared global data structures, and nested call relationships of interrupt service routines, the initialization order dependencies, runtime data dependencies, and interrupt handling dependencies among peripherals are identified, including: Step S431: Based on the initialization functions corresponding to each peripheral in the peripheral function symbol table, analyze the direct or indirect call relationships between these initialization functions to form an initialization function call chain, and extract the initialization order dependency between peripherals from the call chain.

[0101] The specific process is as follows: Based on the peripheral initialization functions recorded in the peripheral function symbol table, the system analyzes the direct or indirect call relationships between these functions. For example, if the initialization function of peripheral A calls the initialization function of peripheral B during execution, or indirectly calls the initialization function of B through a series of intermediate functions, the system will record this call chain. Using static code analysis tools, the system traces the function call path and constructs a complete initialization function call chain. From this call chain, the system extracts the initialization order dependencies between peripherals, clarifying which peripherals' initialization must be completed before the initialization of other peripherals. For example, if the initialization function call chain shows that the initialization function of peripheral B is called before A, the system will record the initialization order dependency of peripheral A on peripheral B. This process ensures that the initialization order of peripherals conforms to the code logic and hardware requirements during system startup, avoiding system failures caused by improper initialization order.

[0102] Step S432: Based on the data transfer functions corresponding to each peripheral in the peripheral function symbol table, identify the global data structures read and written by these functions, construct a complete data flow graph from data producer to data consumer, and extract the runtime data dependencies between peripherals from the data flow graph.

[0103] The specific process is as follows: Based on the data transfer functions of each peripheral recorded in the peripheral function symbol table, the system identifies the specific global data structures read and written by these functions. For example, if the data transfer function of peripheral A writes to the global variable `data_buffer`, and the data transfer function of peripheral B reads data from the same variable, the system will identify this data interaction relationship. Through static code analysis tools, the system tracks the read and write operations of global variables, constructs a complete data flow graph, and clarifies the data flow path from producer to consumer. From this data flow graph, the system extracts the runtime data dependencies between peripherals, clarifying which peripherals' data transfer depends on the data generation of other peripherals. For example, if the data flow graph shows that the data transfer of peripheral B depends on `data_buffer` written by peripheral A, the system will record the runtime data dependency of peripheral B on A. This process ensures that during system runtime, data read and write operations conform to the expected order and logic, avoiding runtime errors caused by data dependency issues.

[0104] Step S433: Based on the interrupt handling functions corresponding to each peripheral in the peripheral function symbol table, analyze the nested call and preemption relationships between interrupt service routines, and combine the interrupt vector table mapping to form an interrupt handling nesting relationship diagram, and extract the interrupt handling dependencies between peripherals from the nesting relationship diagram.

[0105] The specific process is as follows: Based on the peripheral interrupt handling functions recorded in the peripheral function symbol table, the system analyzes the nested calls and preemption relationships between these functions. For example, if the interrupt handling function of peripheral A calls the interrupt handling function of peripheral B during execution, or may be preempted by the interrupt handling function of peripheral B, the system will record this relationship. Through static code analysis tools, combined with interrupt vector table mapping, the system constructs a complete interrupt handling nesting relationship graph, clarifying the calling and preemption order between interrupt service routines. From this nesting relationship graph, the system extracts the interrupt handling dependencies between peripherals, clarifying which peripherals' interrupt handling depends on the completion or priority setting of other peripherals' interrupt handling. For example, if the interrupt handling nesting relationship graph shows that the interrupt handling function of peripheral B has a higher priority than peripheral A and may preempt A's interrupt handling, the system will record peripheral A's dependency on B's interrupt handling. This process ensures that during system operation, the priority and order of interrupt handling conform to hardware requirements, avoiding system instability caused by interrupt handling conflicts.

[0106] The hardware description file is parsed to extract register mappings, interrupt and clock parameters for each peripheral. Based on these parameters, a general template is matched from the driver template knowledge base, and the underlying driver framework code for each peripheral is synthesized, including: Step S3A: Parse the hardware description file and extract the hardware parameters of each peripheral in the target processing architecture. The hardware parameters include at least the register mapping address, interrupt vector parameters, and clock configuration parameters.

[0107] Step S3A discloses the core process of automatically extracting key hardware parameters from hardware description files. This step is the starting point and foundation of the driver generation process, and its key processes are as follows: 1. File parsing: The system automatically reads and parses the hardware description file (such as chip technical manual, datasheet) of the target processing architecture.

[0108] 2. Parameter identification and extraction: Through text parsing algorithms (such as regular expressions) or structured data reading, the specific hardware parameters of each peripheral (such as SPI, I2C, UART) are accurately identified and extracted from the file.

[0109] 3. Key parameter set: The extracted parameters should include at least the following: Register mapping address: The specific memory address of the peripheral control register. Interrupt vector parameters: Interrupt configuration information such as the interrupt number and priority corresponding to the peripheral. Clock configuration parameters: Timing parameters such as the clock source and divider required for the peripheral to operate.

[0110] 4. Output is structured data: The extracted parameters are organized into a structured data set, which serves as explicit input for subsequent steps.

[0111] Step S3B: For each peripheral device, based on the extracted hardware parameters, intelligent matching is performed in the driver template knowledge base to locate the driver template that is compatible with the peripheral device type and target processing architecture. Based on the mapping relationship between hardware parameters and template interfaces, parameter filling and configuration item generation are automatically completed.

[0112] Step S3B discloses the core process of intelligently converting hardware parameters into driver code logic. This step is a crucial intelligent step in automatic driver generation, and its core process is as follows: Template knowledge base query: The system uses peripheral type (such as SPI, I2C) and target processing architecture as key filtering conditions to search the driver template knowledge base.

[0113] Intelligent matching: The matching process is not a simple keyword search, but a compatibility analysis and intelligent filtering based on the template's metadata (such as the list of supported peripherals, compatible chip architectures, and parameter interface definitions) and input parameters to locate the most suitable general driver template.

[0114] Mapping and Filling: Based on the predefined mapping relationship between hardware parameters and template interfaces, the system automatically assigns the specific parameters extracted in the S3A step (such as register address 0x40013000) to the corresponding variables or configuration items in the template (such as macro definition #define SPI1_BASE_ADDRESS).

[0115] Configuration item generation: In addition to direct assignment, the system can also automatically generate or adjust relevant configuration code based on the logical relationship between parameters (such as calculating the baud rate divider value based on clock parameters and writing it into the initialization function).

[0116] In step S3C, the driver code generation tool performs syntax verification, dependency resolution, and code integration on the parameterized peripheral driver templates to generate the underlying driver framework code for each peripheral that precisely matches the target processing architecture hardware and conforms to the version control branch structure plan.

[0117] Step S3C discloses the construction and integration process for ultimately synthesizing parameterized driver templates into usable code. This step is the final output of the automatic driver generation process, and its core process is as follows: Code quality verification (syntax check): The driver code generation tool first performs static syntax checks and basic semantic analysis on the peripheral driver template code that has been filled with parameters to ensure that the generated code conforms to programming language specifications, has no syntax errors, and avoids basic compilation failures caused by parameter errors or template problems.

[0118] Context handling (dependency resolution): The tool analyzes the dependencies between peripheral driver code (such as header file inclusions, global variable references, and function calls). It ensures that the generated driver framework, as a whole, has its internal module dependencies correctly declared and linked, preparing it for subsequent joint compilation.

[0119] Project structure integration (code integration): Based on the "version control branch structure planning," the tool organizes the generated, independent peripheral driver code files according to a predetermined directory structure and project files (such as Makefile, CMakeLists.txt). This ensures that the generated code can be directly recognized and compiled by existing flight control program building systems as part of the source code tree.

[0120] Final Output: After the above processing, the system outputs the underlying driver framework code for each peripheral device that precisely matches the target processing architecture hardware. This code is not only functionally correct but also engineering-ready—it has the correct project structure and can be directly incorporated into the corresponding development branch for compilation, debugging, and integration testing.

[0121] Based on the same inventive concept, embodiments of the present invention provide a flight control program intelligent adaptation system for heterogeneous processing architectures, including a memory and a processor, wherein the memory stores programs that can run on the processor to implement, as shown in the example. Figure 1 The procedure for the method shown.

[0122] The embodiments described in this specific implementation are preferred embodiments of this application and are not intended to limit the scope of protection of this application. Therefore, all equivalent changes made in accordance with the structure, shape and principle of this application should be covered within the scope of protection of this application.

Claims

1. A method for intelligent adaptation of flight control programs to heterogeneous processing architectures, characterized in that, Executed by an adaptive decision engine, the operations include: Obtain the hardware description file of the target processing architecture, combine it with the preset set of external constraints and the historical adaptation knowledge base, and generate a customized adaptation strategy through the strategy optimization algorithm. The strategy includes at least the environment configuration, the target peripheral configuration list obtained from the hardware description file, the test and verification path, and the version control branch structure planning optimized for parallel development. Based on the environment configuration section of the strategy, the automated toolchain is invoked to deploy dedicated debugging service components on demand for the target processing architecture, and an online simulation and debugging channel with resource monitoring capabilities is established. Parse the hardware description file to extract the register mapping, interrupt and clock parameters of each peripheral. Based on the parameters, match the general template from the driver template knowledge base and synthesize the underlying driver framework code of each peripheral. According to the branch structure plan, initialize the parallel development branch in the version control system and submit the generated driver framework code to the corresponding branch. In response to the development completion event triggered by committing code on any development branch, the automated verification of ready peripheral drivers is dynamically scheduled based on the test and verification path and the real-time status of simulation resources. After the peripheral driver is verified, for each verified peripheral driver, a corresponding hardware abstraction layer configuration change instruction is generated based on the hardware description file; the debug channel is invoked to debug the hardware abstraction layer configuration file and interface code corresponding to the peripheral one by one; After the hardware abstraction layer of all necessary peripherals has been debugged, the source code of the target flight control program's hardware abstraction layer is parsed, the dependencies between peripherals are automatically identified, and the order of merging code from each development branch to the main branch is dynamically coordinated based on the relationship. The integration pipeline executes the build and test processes, and after the integration conditions defined by the strategy are met, it triggers the build and output of the final flight control program image.

2. The intelligent adaptation method for flight control programs for heterogeneous processing architectures according to claim 1, characterized in that, The generation of customized adaptation strategies through strategy optimization algorithms includes: The hardware description file is parsed to extract the hardware features of the target processing architecture, including peripheral resource list, performance parameters, interrupt vector distribution and memory mapping features. Based on the extracted hardware features, the set of external constraints is matched and analyzed with the extracted hardware features to determine the urgency of the adaptation task, the upper limit of resource input, and the key performance indicator requirements, thereby generating quantitative constraints. Based on hardware characteristics and quantitative constraints, we retrieved past adaptation cases with similar hardware characteristics and constraints from the historical adaptation knowledge base, and extracted their successful adaptation patterns and typical problem avoidance solutions as historical experience data. Using hardware characteristics, quantitative constraints, and historical experience data as input, a multi-objective optimization solution is obtained through a strategy optimization algorithm. The final result is a customized adaptation strategy that includes environment configuration, target peripheral configuration list, test and verification path, and version control branch structure planning optimized for parallel development.

3. The intelligent adaptation method for flight control programs for heterogeneous processing architectures according to claim 2, characterized in that, Using hardware characteristics, quantification constraints, and historical experience data as input, a multi-objective optimization solution is obtained through a strategy optimization algorithm. The final result is a customized adaptation strategy that includes environment configuration, a list of target peripheral configurations, test and verification paths, and a version control branch structure plan optimized for parallel development. Based on quantitative constraints, at least three parallel optimization objectives are determined, including adaptation cycle objective, driving stability objective, and supply chain risk objective. Among them, adaptation cycle objective is determined based on the urgency requirements in the quantitative constraints, driving stability objective is determined based on the peripheral resource list in the hardware characteristics, and supply chain risk objective is determined based on the preset component supply risk level mapping relationship and the component model corresponding to each peripheral in the hardware characteristics. Analyze historical experience data, and vectorize the successful adaptation cases recorded in the historical experience data into features based on the performance of each case in terms of adaptation cycle, driving stability and supply chain risk, and build a historical case feature vector library; Based on the feature vector library of historical cases, we retrieve several historical cases that have the highest similarity to the current hardware features, current quantitative constraints and supply chain risk objectives, extract the strategy decision paths corresponding to several historical cases, and encode the strategy decision paths into the initial particle swarm of the multi-objective particle swarm optimization algorithm. The multi-objective particle swarm optimization algorithm is run, and iteratively searches in the solution space with the optimization objectives of adaptation period, driving stability and supply chain risk. The position and velocity of each particle are dynamically updated according to the fitness of each particle. After reaching the preset convergence condition, a set of Pareto front candidate strategies is output. Each candidate strategy contains a combination of environment configuration, target peripheral configuration list, test and verification path and version control branch structure planning. Based on the upper limit of resource input and key performance indicators in the quantitative constraints, and combined with the optimization goal of parallel development efficiency, the Pareto frontier candidate strategy set is screened and evaluated. The candidate strategy that satisfies all constraints and is optimal in comprehensive evaluation is selected as the final customized adaptation strategy.

4. The intelligent adaptation method for flight control programs for heterogeneous processing architectures according to claim 1, characterized in that, Based on the environment configuration section of the strategy, the automated toolchain is invoked to deploy dedicated debugging service components on demand for the target processing architecture, establishing an online simulation and debugging channel with resource monitoring capabilities, including: The environment configuration section of the customized adaptation strategy is analyzed to determine the type and version of the required debugging service components, and the corresponding debugging server software package and integrated development environment client plugin are selected from the automation toolchain. On the local development host, install and configure the selected debug server software package to load debug protocol support that matches the target processing architecture, and start the background service process of the debug server. In the integrated development environment, install the selected client plugin, configure the communication connection parameters with the local debug server through the plugin, and load the simulation configuration file for the target processing architecture. By using the client plugin in the integrated development environment, a connection request is initiated to the locally running debug server to establish a stable communication link with the target processing architecture flight control board, thereby forming an online simulation and debugging channel; After the online simulation and debugging channel is established, a resource monitoring agent is deployed to collect and report the channel's connection status, data throughput, and simulator load information in real time, thus completing the initialization of the resource monitoring capabilities of the debugging channel.

5. The intelligent adaptation method for flight control programs for heterogeneous processing architectures according to claim 4, characterized in that, Deploy a resource monitoring agent to collect and report channel connection status, data throughput, and simulator load information in real time, completing the initialization of resource monitoring capabilities for the debugging channel, including: Inject lightweight monitoring probe code modules for collecting runtime metrics into the background service process and client plugin of the debugging server software package, respectively. Configure the monitoring indicators to be collected for the monitoring probe. The monitoring indicators should include at least the connection status of the online simulation and debugging channels, data throughput, and simulator load information, and start the indicator collection function of the monitoring probe. Start an independent monitoring service process, establish a data transmission link between the monitoring probe, the monitoring service process, and the integrated development environment user interface, and verify that the monitoring service process can receive and display monitoring indicators normally by sending test data packets and successfully displaying them on the user interface, thereby completing the initialization of resource monitoring capabilities for the debug channel.

6. The intelligent adaptation method for flight control programs for heterogeneous processing architectures according to claim 1, characterized in that, The hardware description file is parsed to extract register mappings, interrupt and clock parameters for each peripheral. Based on these parameters, a general template is matched from the driver template knowledge base, and the underlying driver framework code for each peripheral is synthesized, including: Parse the hardware description file and extract the hardware parameters of each peripheral in the target processing architecture. The hardware parameters include at least the register mapping address, interrupt vector parameters, and clock configuration parameters. For each peripheral device, based on the extracted hardware parameters, intelligent matching is performed in the driver template knowledge base to locate the driver template that is compatible with the peripheral device type and target processing architecture. Based on the mapping relationship between hardware parameters and template interfaces, parameter filling and configuration item generation are automatically completed. The driver code generation tool performs syntax validation, dependency resolution, and code integration on the parameterized peripheral driver templates, generating underlying driver framework code for each peripheral that precisely matches the target processing architecture hardware and conforms to the version control branch structure plan.

7. The intelligent adaptation method for flight control programs for heterogeneous processing architectures according to claim 1, characterized in that, Analyzing the target flight control program's hardware abstraction layer source code and automatically identifying dependencies between peripherals includes: The header configuration file and interface implementation source code of the hardware abstraction layer are parsed synchronously to extract all configuration macro definitions related to peripherals, and the peripheral initialization functions, data transfer functions and interrupt handling functions associated with these macro definitions in the source code are identified synchronously. Establish a unified symbol mapping relationship between the peripheral identifiers extracted from the configuration macro definitions and the corresponding functions identified in the source code to form a peripheral function symbol table; Based on the peripheral function symbol table, by analyzing the call chain between functions, the shared global data structure, and the nested call relationship of interrupt service routines, the initialization order dependency, runtime data dependency, and interrupt handling dependency between peripherals are identified. The identified multidimensional dependencies are integrated into a directed dependency graph, where nodes represent peripherals and edges represent dependency types and directions. Loop detection and consistency verification are performed on this dependency graph, and the output directed dependency graph that has been verified without error is the result of automatic identification.

8. The intelligent adaptation method for flight control programs for heterogeneous processing architectures according to claim 7, characterized in that, Based on the peripheral function symbol table, by analyzing the call chains between functions, shared global data structures, and nested call relationships of interrupt service routines, the initialization order dependencies, runtime data dependencies, and interrupt handling dependencies among peripherals are identified, including: Based on the initialization functions corresponding to each peripheral in the peripheral function symbol table, analyze the direct or indirect call relationships between these initialization functions to form an initialization function call chain, and extract the initialization order dependency between peripherals from the call chain; Based on the data transfer functions corresponding to each peripheral in the peripheral function symbol table, identify the global data structures read and written by these functions, construct a complete data flow graph from data producer to data consumer, and extract runtime data dependencies between peripherals from this data flow graph; Based on the interrupt handling functions corresponding to each peripheral in the peripheral function symbol table, the nested call and preemption relationships between interrupt service routines are analyzed. Combined with the interrupt vector table mapping, an interrupt handling nesting relationship graph is formed, and the interrupt handling dependencies between peripherals are extracted from this nesting relationship graph.

9. A flight control program intelligent adaptation system for heterogeneous processing architectures, characterized in that, It includes a memory, a processor, and a program stored in the memory and executable on the processor, which, when loaded and executed by the processor, implements a flight control program intelligent adaptation method for heterogeneous processing architectures as described in any one of claims 1 to 8.

Images