An embedded standardized development test method, device, equipment and medium

Abstract

This application discloses an embedded standardized development and testing method, apparatus, device, and medium, relating to the field of software development technology, and is used to solve technical problems such as non-standard task decomposition in existing embedded development processes. The method includes: acquiring embedded product development requirements, target chip information, target board connection information, and project directory information; based on the embedded product development requirements, using a management agent to call an architecture design agent to generate a sub-task list; using a specialized agent to execute each development and testing node according to a standardized specification library and the context information of each development and testing node, generating node outputs for each development and testing node; wherein, the execution includes coding, reviewing, and compiling; and using a management agent to detect and process the node outputs according to preset completion judgment rules. Therefore, this application can improve the consistency of embedded software output through "unified management by a management agent."

Description

Technical Field

[0001] This application relates to the field of software development technology, and provides an embedded standardized development and testing method, apparatus, equipment and medium. Background Technology

[0002] Currently, embedded product development typically involves multiple stages, including low-level drivers, sensor acquisition, communication protocols, low-power control, business state machines, hardware debugging, and field verification. For small and medium-sized embedded companies, the sheer number of product models, significant hardware differences, and short delivery cycles mean that the development process heavily relies on the individual experience of engineers. This often leads to problems such as duplicate development of the same function in different projects, inconsistent coding styles, inconsistent exception handling methods, and insufficient test coverage.

[0003] Most existing code generation tools or large-scale model-assisted programming tools can only perform fragment-level code completion, single-file generation, or question-and-answer debugging suggestions. These tools typically lack continuous status monitoring of the embedded project directory, compilation toolchain, target board hardware interfaces, and test logs, and cannot force the transition to the next development stage after a node is completed. Therefore, existing tools struggle to form a complete development loop from requirements decomposition, code generation, code review, compilation, flashing, testing to archiving.

[0004] While traditional R&D management processes can improve quality through reviews, flowcharts, and manual checks, these systems are costly to implement for small and medium-sized teams and struggle to technically constrain each engineer to follow uniform rules. This is especially true in embedded debugging scenarios, where results such as whether compilation was successful, programming was successful, the serial port received the expected messages, and the target board's random-access memory (RAM) status are correct still require manual judgment from engineers, easily leading to process interruptions and quality fluctuations. Summary of the Invention

[0005] This application provides a standardized development and testing method, apparatus, equipment, and medium for embedded systems, which addresses technical problems such as non-standard task breakdown in existing embedded development processes.

[0006] On the one hand, a standardized embedded development and testing method is provided, applied to an embedded development and testing environment. The method includes: Obtain embedded product development requirements, target chip information, target board connection information, and project directory information; Based on the embedded product development requirements, a management agent invocation architecture is adopted to design an agent that generates a subtask list; wherein, the subtask list includes multiple development and testing nodes with dependencies. For any given development and testing node, based on the standardized specification library and the context information of the given development and testing node, a specialized intelligent agent is used to execute the given development and testing node, generating the node output of the given development and testing node; wherein, the execution includes at least one of encoding, reviewing, compiling, burning, testing, and archiving; According to the preset completion judgment rules, the management intelligent agent is used to detect and process the output of the node.

[0007] Optionally, before obtaining embedded product development requirements, target chip information, target board connection information, and project directory information, the method further includes: Construct a standardized specification library that is executable by a machine; wherein the standardized specification library includes at least hardware pin configuration rules, peripheral driver interface rules, sensor power-on timing, function return value types, error code definitions, compilation options, communication protocol rules, code format rules, and test judgment rules.

[0008] Optionally, the step of designing the agent to generate the subtask list using a management agent invocation architecture based on the embedded product development requirements includes: Based on the embedded product development requirements, a management agent is used to call the architecture design agent to generate a subtask list in the form of a directed acyclic graph (DAG). Nodes in the DAG represent at least one development / testing node from the following categories: architecture design, low-level driver coding, business logic coding, static analysis, compilation verification, programming verification, hardware-in-the-loop testing, and archiving. Edges in the DAG represent dependencies between different development / testing nodes. Each development / testing node includes at least a node identifier, node type, dependent nodes, input outputs, output outputs, and completion criteria.

[0009] Optionally, the step of using a management agent to detect and process the node outputs according to a preset completion determination rule includes: According to the preset completion judgment rules, the management intelligent agent is used to detect the output of the node to determine whether any development and testing node has been successfully judged. If any of the development and testing nodes is determined to be successful, the next development and testing node will be automatically activated. If any of the development and testing nodes fails to pass the test, the failure information will be fed back to the professional intelligent agent for correction.

[0010] Optionally, the step of feeding back the failure information to the specialized intelligent agent for correction includes: A management agent is used to merge failure information with the context information of any of the development and testing nodes into a correction task; The correction task is sent to the specialized intelligent agent for correction. Determine whether the number of consecutive failures of any of the development and testing nodes has reached a preset number; If it is determined that the number of consecutive failures of any development and testing node reaches a preset number, the management agent will mark the development and testing node as an abnormal suspended state and generate information to transfer it to manual processing.

[0011] Optionally, after the management agent detects and processes the node outputs according to preset completion determination rules, the method further includes: Determine whether all development and testing nodes have reached the successful final state; If all development and testing nodes reach the successful final state, the management agent archives the code files, configuration files, test logs, and version information to generate an embedded software delivery package.

[0012] Optionally, the preset completion determination rule includes at least one of the following: Check if a specified type of file has been generated in the project directory; Check if the number of errors in the build log exceeds the error threshold; Check if the target file or burning file output by the detection toolchain exists; Check whether the expected message output by the target board has been captured; Detect whether a status flag exists in the target board's memory; Check whether the pass rate of test cases in the hardware-in-the-loop test report exceeds the pass rate threshold.

[0013] On the one hand, an embedded standardized development and testing device is provided, the device comprising: The requirement acquisition unit is used to acquire embedded product development requirements, target chip information, target board connection information, and project directory information. A management intelligent agent unit is used to generate a subtask list based on the embedded product development requirements; wherein the subtask list includes multiple development and testing nodes with dependencies. A specialized intelligent agent unit is used to execute on any given development and testing node based on a standardized specification library and the context information of the given development and testing node, thereby generating the node output of the given development and testing node; wherein, the execution includes at least one of encoding, reviewing, compiling, burning, testing, and archiving; The management intelligent agent unit is also used to detect and process the output of the node according to the preset completion judgment rules.

[0014] On one hand, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement any of the methods described above.

[0015] On the one hand, a storage medium is provided that stores computer program instructions thereon, which, when executed by a processor, implement any of the methods described above.

[0016] Compared with the prior art, the beneficial effects of this application are as follows: In this application, during embedded standardized development and testing, firstly, embedded product development requirements, target chip information, target board connection information, and project directory information can be obtained. Then, based on the embedded product development requirements, a management agent can call an architecture design agent to generate a subtask list. This subtask list includes multiple development and testing nodes with dependencies. Next, for any given development and testing node, a specialized agent can execute the execution based on the standardized specification library and the context information of that node, generating the node output for that node. This execution includes at least one of encoding, review, compilation, flashing, testing, and archiving. Finally, based on preset completion judgment rules, a management agent can detect and process the node output.

[0017] Based on this, in this application, since the development and testing nodes are uniformly disassembled, scheduled, and transferred through a management agent, compared with the prior art, this application can reduce the dependence of the R&D process on the experience of individual engineers and improve the consistency of embedded software output. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of an application scenario provided by an embodiment of this application; Figure 2 A flowchart illustrating an embedded standardized development and testing method provided in an embodiment of this application; Figure 3 A directed acyclic graph for development and testing nodes provided in the embodiments of this application; Figure 4 A schematic diagram of hardware-in-the-loop testing provided in an embodiment of this application; Figure 5 This is a schematic diagram of an embedded standardized development and testing device provided in an embodiment of this application.

[0020] The diagram is labeled as follows: 10-Embedded Standardized Development and Testing Equipment, 101-Processor, 102-Memory, 103-I / O Interface, 104-Database, 50-Embedded Standardized Development and Testing Device, 501-Requirements Acquisition Unit, 502-Management Agent Unit, 503-Specialized Agent Unit, 504-Specification Library Construction Unit, 505-Archiving Unit. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Unless otherwise specified, the embodiments and features in the embodiments of this application can be arbitrarily combined with each other. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0022] Currently, embedded product development typically involves multiple stages, including low-level drivers, sensor acquisition, communication protocols, low-power control, business state machines, hardware debugging, and field verification. For small and medium-sized embedded companies, the sheer number of product models, significant hardware differences, and short delivery cycles mean that the development process heavily relies on the individual experience of engineers. This often leads to problems such as duplicate development of the same function in different projects, inconsistent coding styles, inconsistent exception handling methods, and insufficient test coverage.

[0023] Most existing code generation tools or large-scale model-assisted programming tools can only perform fragment-level code completion, single-file generation, or question-and-answer debugging suggestions. These tools typically lack continuous status monitoring of the embedded project directory, compilation toolchain, target board hardware interfaces, and test logs, and cannot force the transition to the next development stage after a node is completed. Therefore, existing tools struggle to form a complete development loop from requirements decomposition, code generation, code review, compilation, flashing, testing to archiving.

[0024] While traditional R&D management processes can improve quality through reviews, flowcharts, and manual checks, these systems are costly to implement for small and medium-sized teams and struggle to technically constrain each engineer to follow uniform rules. This is especially true in embedded debugging scenarios, where results such as successful compilation, successful programming, receipt of expected messages via serial port, and correct target board RAM status still require manual judgment from engineers, easily leading to process interruptions and quality fluctuations.

[0025] Based on this, this application provides an embedded standardized development and testing method. In this method, firstly, embedded product development requirements, target chip information, target board connection information, and project directory information can be obtained. Then, based on the embedded product development requirements, a management agent calls an architecture design agent to generate a subtask list. The subtask list includes multiple development and testing nodes with dependencies. Next, for any given development and testing node, a specialized agent executes the node based on the standardized specification library and the context information of that node, generating the node output of that node. The execution includes at least one of encoding, review, compilation, burning, testing, and archiving. Finally, a management agent detects and processes the node output according to preset completion judgment rules. Therefore, in this application, because the development and testing nodes are uniformly disassembled, scheduled, and transferred through a management agent, compared to existing technologies, this application can reduce the reliance on the experience of individual engineers in the R&D process and improve the consistency of embedded software output.

[0026] After introducing the design concept of the embodiments of this application, the following is a brief introduction to the application scenarios to which the technical solutions of the embodiments of this application can be applied. It should be noted that the application scenarios described below are only for illustrating the embodiments of this application and are not intended to limit the scope. In specific implementation, the technical solutions provided by the embodiments of this application can be flexibly applied according to actual needs.

[0027] like Figure 1 The diagram shown illustrates an application scenario provided by an embodiment of this application. This application scenario may include an embedded standardized development and testing device 10.

[0028] The embedded standardization development and testing equipment 10 can be used for embedded standardization development and testing, and can be, for example, a personal computer (PC), server, or laptop. The embedded standardization development and testing equipment 10 may include one or more processors 101, memory 102, I / O interfaces 103, and databases 104. Specifically, the processor 101 may be a central processing unit (CPU) or a digital processing unit, etc. The memory 102 may be volatile memory, such as random access memory (RAM); the memory 102 may also be non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); or the memory 102 may be any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but is not limited thereto. The memory 102 may be a combination of the above-mentioned memories. The memory 102 can store some program instructions of the embedded standardized development and testing method provided in the embodiments of this application. When these program instructions are executed by the processor 101, they can be used to implement the steps of the embedded standardized development and testing method provided in the embodiments of this application, so as to solve technical problems such as non-standard task decomposition in the existing embedded development process. The database 104 can be used to store data such as embedded product development requirements, target chip information, target board connection information, and project directory information involved in the solution provided in the embodiments of this application.

[0029] In this embodiment, the embedded standardized development and testing device 10 can obtain test instructions through the I / O interface 103. Then, the processor 101 of the embedded standardized development and testing device 10 will solve technical problems such as non-standard task decomposition in the existing embedded development process according to the program instructions of the embedded standardized development and testing method provided in this embodiment in the memory 102. In addition, embedded product development requirements, target chip information, target board connection information, and project directory information can be stored in the database 104.

[0030] Of course, the methods provided in the embodiments of this application are not limited to... Figure 1 The application scenarios shown can also be used in other possible scenarios, and this application embodiment does not impose any limitations. Figure 1 The functions that the various devices in the application scenarios shown can achieve will be described in subsequent method embodiments, and will not be elaborated on here. Below, the methods of the embodiments of this application will be described in conjunction with the accompanying drawings.

[0031] like Figure 2 The diagram shown is a flowchart of an embedded standardized development and testing method provided in this application. This method can be applied to an embedded development and testing environment, which includes a management agent, at least two specialized agents, a standardized specification library, an embedded toolchain, and a target board test interface. The management agent does not simply perform text judgment but determines nodes based on objective signals such as the embedded toolchain, programming tools, serial port monitoring, RAM flags, and hardware-in-the-loop test reports. The specialized agents are responsible for executing specific nodes, while the management agent is responsible for node decomposition, scheduling, failure retries, exception suspension, breakpoint continuation, and archive transfer. In this application, the method can... Figure 1 The embedded standardized development and testing equipment 10 is used to execute the method. Specifically, the process of this method is described as follows.

[0032] Step 201: Build a standardized specification library that can be executed by machines.

[0033] The standardized specification library includes at least hardware pin configuration rules, peripheral driver interface rules, sensor power-on timing, function return value types, error code definitions, compilation options, communication protocol rules, code format rules, and test judgment rules.

[0034] In addition, the standardized specification library is stored in at least one machine-readable form among JSON schema (JavaScript Object Notation Schema, JSON Schema), YAML configuration files, regular expression rules, code formatting configuration files, interface templates, and test scripts.

[0035] Step 202: Obtain embedded product development requirements, target chip information, target board connection information, and project directory information.

[0036] Step 203: Based on the requirements of embedded product development, design the agent to generate a list of subtasks using a management agent invocation architecture.

[0037] The subtask list includes multiple development and testing nodes with dependencies.

[0038] Specifically, based on the embedded product development requirements, a management agent can call an architecture design agent to generate a list of subtasks in the form of a directed acyclic graph (DAG). Nodes in the DAG represent at least one development / testing node from the following categories: architecture design, low-level driver coding, business logic coding, static analysis, compilation verification, flashing verification, hardware-in-the-loop testing, and archiving. Figure 3The diagram shows a directed acyclic graph (DAG) of development and testing nodes provided in this application embodiment. The development and testing nodes may include hardware initialization nodes, driver coding nodes, protocol implementation nodes, static review nodes, compilation verification nodes, programming verification nodes, hardware-in-the-loop testing nodes, and archiving nodes. The edges in the DAG structure are used to represent the dependencies between different development and testing nodes. Each development and testing node includes at least a node identifier, node type, dependent nodes, input outputs, output outputs, and completion determination conditions.

[0039] Step 204: For any development and test node, based on the standardized specification library and the context information of any development and test node, a professional intelligent agent is used to execute the operation on any development and test node to generate the node output of any development and test node.

[0040] The execution includes at least one of encoding, reviewing, compiling, burning, testing, and archiving; the node outputs include at least one of code files, review reports, compilation logs, burning results, serial port test logs, or hardware-in-the-loop test reports.

[0041] Specifically, the management agent can distribute any development and test node to a specialized agent, such as a coding agent, a review agent, or a testing agent, based on the node type of the development and test node (this can greatly improve node execution efficiency by having different specialized agents perform coding, review, and testing separately). The management agent then transmits the relevant rules from the standardized specification library and the context information of the current node to the specialized agent. Subsequently, the specialized agent can execute the code based on the standardized specification library and the context information of the development and test node to generate the node output of that development and test node.

[0042] Step 205: According to the preset completion judgment rules, the management agent is used to detect and process the node outputs.

[0043] Specifically, firstly, according to preset completion judgment rules, a management agent can be used to detect the output of the nodes to determine whether any development and testing node has been successfully judged; then, if any development and testing node is determined to be successfully judged, the next development and testing node is automatically activated; otherwise, if any development and testing node is determined to be unsuccessful, the failure information is fed back to the professional agent for correction.

[0044] Furthermore, when feeding back failure information to the specialized intelligent agent for correction, firstly, a management intelligent agent can be used to merge the failure information with the context information of any development and testing node into a correction task; then, the correction task can be sent to the specialized intelligent agent for correction; next, it can be determined whether the number of consecutive failures of any development and testing node has reached a preset number; then, if it is determined that the number of consecutive failures of any development and testing node has reached the preset number, the management intelligent agent marks the any development and testing node as an abnormal suspended state and generates a transfer to manual processing information; otherwise, if it is determined that the number of consecutive failures of any development and testing node has not reached the preset number, the specialized intelligent agent continues to execute on the any development and testing node.

[0045] In one possible implementation, the preset completion determination rule includes at least one of the following: Check if a specified type of file has been generated in the project directory; Check if the number of errors (or warnings) in the compilation log exceeds the error threshold; Check if the target file or burning file output by the detection toolchain exists; Detect whether the expected message output by the target board is captured through interfaces such as serial port, Inter-Integrated Circuit (I²C), Serial Peripheral Interface (SPI), Serial Wire Debug (SWD), or Joint Test Action Group (JTAG); Detect whether a status flag (RAM flag bit) exists in the target board's memory; Check whether the pass rate of test cases in the hardware-in-the-loop test report exceeds the pass rate threshold.

[0046] In one possible implementation, after the node output is detected and processed by a management agent according to a preset completion determination rule, the test-related information can also be "archived" to facilitate subsequent process traceability and reuse.

[0047] Specifically, first, it can be determined whether all development and testing nodes have reached a successful final state. This successful final state does not include the abnormal pending state corresponding to archiving.

[0048] Next, if all development and testing nodes reach a successful final state, a management agent archives the code files, configuration files, test logs, and version information to generate an embedded software delivery package. Conversely, if not all development and testing nodes reach a successful final state, execution continues on the remaining development and testing nodes.

[0049] In one possible implementation, the coding agent may further include multiple heterogeneous code generation agents; the management agent calls multiple heterogeneous code generation agents to generate candidate code for the same development and testing node, and selects one of the candidate codes as the code output of the current node based on the specification verification score, the number of compilation errors, the number of compilation warnings, the test pass rate, or the code difference evaluation result.

[0050] In one possible implementation, the management agent may also be equipped with a heartbeat detection mechanism, a timeout detection mechanism, and a breakpoint continuation mechanism; when the professional agent fails to return node output within a preset time, the management agent resends the start command; when the development and testing process is interrupted, the management agent continues execution from the most recent successful node based on the persistent node state.

[0051] In one possible implementation, the embedded toolchain may further include an embedded compilation toolchain, a programming tool, a debugging tool, and a log parsing tool, used to encapsulate the calling interfaces of external tools such as Keil, GNU Compiler Collection (GCC), Cross-platform Make (CMake), Open On-Chip Debugger (OpenOCD), J-Link Commander, or serial port monitoring scripts; the hardware interface may also be at least one of a serial port interface, J-Link interface, SWD interface, JTAG interface, I²C interface, or SPI interface, used to obtain the target board's operating status, perform target board programming, operation monitoring, RAM flag reading, or message capture.

[0052] In one possible implementation, the management agent is a process scheduling software module running on a computing device, used to maintain task queues, node dependencies, agent states, failure retries, timeout states, and archiving states. The specialized agents are software modules that complete specific R&D nodes, and may include architecture design agents, coding agents, review agents, testing agents, archiving agents, etc. Different specialized agents can be implemented by different large models, rule engines, scripting tools, or automated testing programs; this application does not limit the specific model name. In this application, the management agent does not directly rely on natural language judgment, but instead reads toolchain return codes, compilation logs, burning results, serial port messages, or target board RAM flags, and uses these objective signals as the basis for node flow.

[0053] like Figure 4 The diagram illustrates a hardware-in-the-loop test provided in this embodiment of the application. The management agent can call the toolchain to generate a programming file, program the target board via the hardware interface, and then read the test results via serial port messages (containing RAM status flags). For example, the test agent can send query commands such as STATUS to provide feedback on failure information such as status bytes or expected messages. Specific Implementation Example 1: Step 1: Construction of a standardized specification library.

[0055] Establish a standardized specification library that is executable by the machine in advance. Taking pressure sensor driver development as an example, the specification library can include rules such as using the PA4 pin as the power supply control pin for the pressure sensor, using PA2 / PA3 as I²C communication pins, the driver function returning an int32_t, using enumerated values ​​for error codes, and requiring communication reporting frames to include a 9001 registration frame and a 9031 data reporting frame.

[0056] Taking pin naming rules as an example, the specification library can store regular expression rules. For instance, it may require General-Purpose Input / Output (GPIO) pin names to conform to the format of uppercase port followed by a number, such as PA4 or PB12. When inspecting code, the review agent extracts all GPIO pin macro definitions or initialization parameters and performs regular expression matching. If PRESSURE_VDD_PIN is detected to be written as pA4, PA_4, or other forms that do not conform to the preset rules, a specification violation report is generated. The report may include rule_id, file name, line number, expected format, and actual value. In this way, the specification library is not a manually read policy text, but a set of machine-executable rules that can be directly invoked by the review agent and the management agent.

[0057] Step 2: Task injection.

[0058] Users can upload requirement documents, or the upstream system can generate requirement forms. Requirement documents can be in Markdown, Word, JavaScript Object Notation (JSON), or database records, and include information such as the target chip, board type, sensor model, communication protocol, power consumption requirements, and testing requirements.

[0059] Step 3: Task breakdown.

[0060] The management agent invokes the architecture design agent to generate a list of subtasks based on the requirements document and specification library. The subtask list can be in JSON format, with each subtask containing a task number, node type, task description, input file, output file, dependent nodes, and completion conditions.

[0061] In this embodiment, the subtask list output by the architecture design agent is preferably in structured JSON format, rather than a plain text list. Each node may include fields such as node_id, node_type, deps, input_files, output_files, and completion_criteria. Node_type can represent node types such as coding, review, compile, burn, verify, or archive; deps records the preceding dependent nodes; and completion_criteria records the completion criteria, such as compile_log_contains:'0 Error(s)', serial_expected:'9031', or ram_flag_equals:'TEST_PASS'. Because this output is a machine-parseable structure, the management agent can automatically schedule tasks based directly on dependencies and completion criteria.

[0062] Step 4: Develop test node distribution.

[0063] The management agent distributes tasks to the corresponding specialized agents according to node type. For example, tasks such as hardware initialization, I²C read / write, data verification, and business state machine are distributed to the coding agent; tasks such as code style checks, static analysis, and interface consistency checks are distributed to the review agent; and tasks such as unit testing, compilation verification, flashing verification, and serial port monitoring are distributed to the testing agent.

[0064] Step 5: Development and testing node completion determination.

[0065] The management agent does not simply rely on the professional agent returning a "complete" status, but instead reads the objective output to make judgments. For encoding nodes, it checks whether .c / .h files have been generated; for compilation nodes, it parses the compilation log to see if it contains 0Error(s); for hardware testing nodes, it checks whether the serial port has received the expected message, or reads the status flags in the target board's RAM.

[0066] Step 6: Develop test node failure feedback and retry.

[0067] If the development and testing node fails, the management agent will automatically merge the compilation errors, review comments, serial port logs, or test failure information into the original task context and resend it to the corresponding specialized agent for correction. If the number of consecutive failures exceeds a preset number, such as 3, the task will be suspended and a human engineer will be notified.

[0068] Step 7: Develop automatic workflow and archiving for test nodes.

[0069] After the current development and testing node succeeds, the management agent activates the next development and testing node based on dependencies. Once all development and testing nodes are completed, the system automatically packages and generates code, configuration files, test logs, flashing files, version information, and execution records, forming a traceable delivery package. Specific Implementation Example 2: Development of PA4 pressure sensor driver and 9001 / 9031 business modules.

[0071] In a specific project, it is necessary to develop logic for power control of the PA4 pressure sensor, I²C pressure reading, 9001 registration processing, and 9031 pressure data reporting. The management agent first reads the requirements document and specification library, breaking down the requirements into multiple sub-tasks. For example: initializing PA4 as an output and pulling it high, implementing I²C read / write functions, implementing pressure sensor data reading and verification, implementing 9001 registration processing, implementing 9031 reporting logic, generating unit tests, and executing hardware verification.

[0072] After the coding agent generates code for each subtask, the management agent automatically calls the review agent to perform specification checks. Once the review is passed, the management agent calls an embedded compilation toolchain, such as the Keil command line, Makefile, or CMake toolchain, to compile the code and parse the compilation logs. When the number of errors in the compilation logs is 0 and a flashing file is generated, the management agent triggers the test agent to perform flashing and serial port monitoring.

[0073] The test agent writes the programming file to the target board via J-Link, SWD, or other debugging interfaces and listens to the target board's output via serial port. When the target board output contains a 9001 registration message and a 9031 data reporting message, or when the test status flag in the target board's RAM is "passed," the management agent determines that the hardware-in-the-loop test has passed. If the expected message is not received via serial port, the serial port log, compilation log, and current code path are fed back to the coding agent or test agent for correction.

[0074] In another implementation, test stub code can be pre-configured in the target board firmware, or injected into the test version firmware by the test agent using a template. After flashing, the test agent sends a status query command (e.g., STATUS?) via serial port, and the target board returns a status byte or status string; where bit 0 indicates pressure sensor initialization is complete, bit 1 indicates 9001 registration is complete, and bit 2 indicates 9031 reporting is complete. If the test agent does not receive the expected status response within a preset time, it determines that the hardware-in-the-loop test has failed and feeds back the serial port log, status byte, and current code version to the management agent. Therefore, the test stub code can serve as a fixed test interface for the target board firmware, or it can be automatically added to the test version by the test agent according to the current development test node, avoiding complete reliance on manually pre-written test stubs.

[0075] In this embodiment, the human engineer is primarily responsible for providing requirements documents, a specification library, and the target board connectivity environment. The management agent drives the coding, review, compilation, flashing, and testing processes unattended. This preserves the engineer's control over the specifications and hardware environment while reducing repetitive coding and low-level debugging work. Specific Implementation Example 3: A detailed introduction to the selection of candidate codes for multiple models is provided.

[0077] In this application, the coding agent may include multiple heterogeneous code generation agents. The management agent simultaneously invokes multiple coding agents to generate candidate code for the same driver development task, and then performs specification verification, compilation verification, and unit testing on each agent. The management agent can select the optimal candidate code based on the number of specification violations, the number of compilation warnings, test pass rate, changes in lines of code, and interface consistency score.

[0078] This approach leverages the advantages of different code-generated models without binding to a single model. If the code output by a certain model can compile but does not conform to the naming rules in the specification library, the management agent can choose another candidate code or provide feedback to the original coding agent requesting corrections.

[0079] For example, in a pressure sensor driver development task, the management agent simultaneously calls upon both coding agents A and B to generate candidate code. Candidate code A compiles successfully, but the review agent finds issues such as non-standard function naming and inconsistent error codes. Candidate code B not only compiles successfully but also has zero specification violations and passes unit tests. The management agent can then select candidate code B as the output for the current node or provide the review report for candidate code A back to coding agent A for correction. This process relies on objective metrics such as specification verification, compilation results, and test results, rather than relying on the model to declare the code's quality. Specific Implementation Example 4: This section provides a detailed introduction to breakpoint continuation and exception handling.

[0081] After each node completes, the management agent can write information such as node status, input files, output files, log paths, failure counts, and timestamps to persistent storage. If the development and testing process is interrupted due to a computing device restart, network interruption, model interface malfunction, or target board power failure, the management agent can read the persistent state after recovery and continue execution from the most recent successful node without having to start from the beginning.

[0082] For anomalies requiring manual confirmation, such as damaged hardware interfaces, unresponsive target boards, sensor material replacements, or missing specification libraries, the management agent generates a message for manual processing, along with necessary context, to help engineers quickly locate the problem. After manual processing is completed, the node can be reset to the pending execution state to allow the process to continue.

[0083] In summary, this application has the following advantages: (1) By managing the state determination, abnormal retry, unified disassembly, scheduling and transfer of development and testing nodes of intelligent agents, it is possible not only to reduce the dependence of the R&D process on the experience of individual engineers and improve the consistency of embedded software output, but also to realize the automatic closed loop of the R&D process.

[0084] (2) By using a standardized specification library to impose machine-executable constraints on code style, hardware pins, protocol format and test judgment, the output differences between different engineers can be reduced, and redundant development, interface inconsistencies and hidden defects can be reduced.

[0085] (3) By using compilation log parsing, burning result detection, serial port message capture and hardware-in-the-loop test results as the basis for node completion judgment, AI code generation can be connected with real embedded toolchain and target board hardware, avoiding only staying at the text generation level.

[0086] (4) Through automatic failure feedback, retry, timeout suspension and breakpoint continuation mechanism, it can achieve continuous progress in unattended situations and retain the manual intervention entry point.

[0087] (5) By archiving outputs, logs and version information, a traceability chain of the R&D process can be formed, which facilitates subsequent auditing, review and iteration of the specification library.

[0088] Based on the same inventive concept, embodiments of this application provide an embedded standardized development and testing device 50, such as... Figure 5 As shown, the embedded standardized development and testing device 50 can be deployed on a local server, industrial control computer, R&D workstation, or cloud server, and connects to the target board testing environment via interfaces such as network, serial port, J-Link, SWD, and JTAG, including: The requirement acquisition unit 501 is used to acquire embedded product development requirements, target chip information, target board connection information, and project directory information; The management intelligent agent unit 502 is used to generate a subtask list according to the embedded product development requirements; wherein the subtask list includes multiple development and testing nodes with dependencies. The professional intelligent agent unit 503 is used to execute on any development and test node based on the standardized specification library and the context information of any development and test node, and generate the node output of any development and test node; wherein, the execution includes coding, review and testing. The management intelligent agent unit 502 is also used to detect and process the node outputs according to the preset completion judgment rules.

[0089] Optionally, the embedded standardization development and testing apparatus 50 also includes a specification library building unit 504, used for: Construct a standardized specification library that is executable by the machine; the standardized specification library shall include at least the following: hardware pin configuration rules, peripheral driver interface rules, sensor power-on timing, function return value types, error code definitions, compilation options, communication protocol rules, code format rules, and test judgment rules.

[0090] Optionally, the management agent unit 502 is also used for: Based on the development requirements of embedded products, a management agent is used to call the architecture design agent to generate a list of subtasks in the form of a directed acyclic graph (DAG). Nodes in the DAG represent at least one development / testing node from the following categories: architecture design, low-level driver coding, business logic coding, static analysis, compilation verification, programming verification, hardware-in-the-loop testing, and archiving. Edges in the DAG represent the dependencies between different development / testing nodes. Each development / testing node includes at least a node identifier, node type, dependent nodes, input outputs, output outputs, and completion criteria.

[0091] Optionally, the management agent unit 502 is also used for: Based on the preset completion judgment rules, a management intelligent agent is used to detect the output of the nodes and determine whether any development and testing node has been judged as successful. If any development test node is determined to be successful, the next development test node will be automatically activated. If any development and testing node fails to pass the test, the failure information will be fed back to the specialized intelligent agent for correction.

[0092] Optionally, the management agent unit 502 is also used for: A management agent is used to merge failure information with the context information of any of the development and testing nodes into a correction task; Send the correction task to a specialized intelligent agent for correction; Determine whether the number of consecutive failures of any development and testing node has reached the preset number; If it is determined that the number of consecutive failures of any development and testing node reaches a preset number, the management agent will mark the development and testing node as an abnormal suspended state and generate a message to transfer it to manual handling.

[0093] Optionally, the embedded standardized development and testing apparatus 50 also includes an archiving unit 505, used for: Determine whether all development and testing nodes have reached the successful final state; If all development and testing nodes reach the successful final state, the management agent archives the code files, configuration files, test logs, and version information to generate an embedded software delivery package.

[0094] This embedded standardized development and testing device 50 can be used to perform... Figure 2 The method performed in the illustrated embodiment is therefore relevant to the functions that each functional module of the embedded standardized development and testing device 50 can achieve. Figure 2 The embodiments shown are described in detail below.

[0095] In some possible implementations, various aspects of the methods provided in this application can also be implemented as a program product comprising program code that, when run on a computer device, causes the computer device to perform the steps of the methods according to the various exemplary embodiments of this application described above. For example, the computer device may perform actions such as... Figure 2 The method performed in the illustrated embodiment.

[0096] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks. Alternatively, if the integrated units of this application are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to the prior art, can be embodied in the form of software products. These computer software products are stored in a storage medium and include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

[0097] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0098] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. An embedded standardized development and testing method, characterized in that, The method, applied in an embedded development and testing environment, includes: Obtain embedded product development requirements, target chip information, target board connection information, and project directory information; Based on the embedded product development requirements, a management agent invocation architecture is adopted to design an agent that generates a subtask list; wherein, the subtask list includes multiple development and testing nodes with dependencies. For any given development and testing node, based on the standardized specification library and the context information of the given development and testing node, a specialized intelligent agent is used to execute the given development and testing node, generating the node output of the given development and testing node; wherein, the execution includes at least one of encoding, reviewing, compiling, burning, testing, and archiving; According to the preset completion judgment rules, the management intelligent agent is used to detect and process the output of the node.

2. The method as described in claim 1, characterized in that, Before obtaining embedded product development requirements, target chip information, target board connection information, and project directory information, the method further includes: Construct a standardized specification library that is executable by a machine; wherein the standardized specification library includes at least hardware pin configuration rules, peripheral driver interface rules, sensor power-on timing, function return value types, error code definitions, compilation options, communication protocol rules, code format rules, and test judgment rules.

3. The method as described in claim 1, characterized in that, The step of designing an agent to generate a subtask list using a management agent invocation architecture based on the embedded product development requirements includes: Based on the embedded product development requirements, a management agent is used to call the architecture design agent to generate a subtask list in the form of a directed acyclic graph (DAG). Nodes in the DAG represent at least one development / testing node from the following categories: architecture design, low-level driver coding, business logic coding, static analysis, compilation verification, programming verification, hardware-in-the-loop testing, and archiving. Edges in the DAG represent dependencies between different development / testing nodes. Each development / testing node includes at least a node identifier, node type, dependent nodes, input outputs, output outputs, and completion criteria.

4. The method as described in claim 1, characterized in that, The step of using a management agent to detect and process the node outputs according to preset completion judgment rules includes: According to the preset completion judgment rules, the management intelligent agent is used to detect the output of the node to determine whether any development and testing node has been successfully judged. If any of the development and testing nodes is determined to be successful, the next development and testing node will be automatically activated. If any of the development and testing nodes fails to pass the test, the failure information will be fed back to the professional intelligent agent for correction.

5. The method as described in claim 4, characterized in that, The step of feeding back the failure information to the specialized intelligent agent for correction includes: A management agent is used to merge failure information with the context information of any of the development and testing nodes into a correction task; The correction task is sent to the specialized intelligent agent for correction. Determine whether the number of consecutive failures of any of the development and testing nodes has reached a preset number; If it is determined that the number of consecutive failures of any development and testing node reaches a preset number, the management agent will mark the development and testing node as an abnormal suspended state and generate information to transfer it to manual processing.

6. The method as described in claim 1, characterized in that, After the node outputs are detected and processed by a management agent according to preset completion determination rules, the method further includes: Determine whether all development and testing nodes have reached the successful final state; If all development and testing nodes reach the successful final state, the management agent archives the code files, configuration files, test logs, and version information to generate an embedded software delivery package.

7. The method as described in claim 1, characterized in that, The preset completion determination rule includes at least one of the following: Check if a specified type of file has been generated in the project directory; Check if the number of errors in the build log exceeds the error threshold; Check if the target file or burning file output by the detection toolchain exists; Check whether the expected message output by the target board has been captured; Detect whether a status flag exists in the target board's memory; Check whether the pass rate of test cases in the hardware-in-the-loop test report exceeds the pass rate threshold.

8. An embedded standardized development and testing device, characterized in that, The device, used in an embedded development and testing environment, includes: The requirement acquisition unit is used to acquire embedded product development requirements, target chip information, target board connection information, and project directory information. A management intelligent agent unit is used to generate a subtask list based on the embedded product development requirements; wherein the subtask list includes multiple development and testing nodes with dependencies. A specialized intelligent agent unit is used to execute on any given development and testing node based on a standardized specification library and the context information of the given development and testing node, thereby generating the node output of the given development and testing node; wherein, the execution includes at least one of encoding, reviewing, compiling, burning, testing, and archiving; The management intelligent agent unit is also used to detect and process the outputs of the nodes according to preset completion judgment rules.

9. An electronic device, characterized in that, The device includes: Memory, used to store program instructions; A processor is configured to invoke program instructions stored in the memory and execute the method described in any one of claims 1-7 according to the obtained program instructions.

10. A storage medium, characterized in that, The storage medium stores computer-executable instructions for causing a computer to perform the method described in any one of claims 1-7.

Images