Methods, apparatus, electronic devices and storage media for generating target embedded code

Abstract

This application discloses a method, apparatus, electronic device, and storage medium for generating target embedded code, relating to the field of code generation technology. The method includes: receiving a target code generation request and parsing the request description text; extracting entity objects and their interaction relationships closely related to the target hardware from an embedded knowledge graph. This process effectively converts natural language descriptions into an understanding of hardware characteristics, thereby generating prompts that accurately reflect hardware characteristics and requirements. The generated target prompts are then input into a code generation model to obtain embedded code matching the target code generation request. This code can handle complex hardware-related details, including interaction relationships between entities and specific hardware attributes such as communication protocols, interface types, and signal parameters, thereby improving the accuracy of the generated embedded code and solving the technical problem of low accuracy in generated embedded code.

Description

Technical Field

[0001] This application relates to the field of code generation technology, and in particular to a method, apparatus, electronic device, and storage medium for generating target embedded code. Background Technology

[0002] In the current field of embedded software development, code generation typically relies on manual writing by software engineers or automated generation based on traditional templates. As embedded systems become increasingly complex, especially when it comes to controlling and managing specific hardware, manual code writing is time-consuming and labor-intensive. Furthermore, existing code generation technologies based on natural language processing suffer from lower accuracy in generating embedded code due to the lack of understanding of hardware interactions. Summary of the Invention

[0003] This application provides a method, apparatus, electronic device, and storage medium for generating target embedded code, in order to at least solve the problem of low accuracy in obtaining generated embedded code in related technologies.

[0004] This application provides a method for generating target embedded code, comprising: receiving a target code generation request, wherein the target code generation request includes a request description text, the request description text being used to indicate target embedded code applied to target hardware; determining, based on the parsing result of the request description text, at least one entity object associated with the target hardware, and the interaction relationship between at least one entity object, from an embedded knowledge graph, wherein the embedded knowledge graph includes entity nodes for respectively indicating multiple entity objects, and the connection relationship between the entity nodes is used to indicate the connection relationship between corresponding entity objects; combining the entity description information of each of the at least one entity object and the relationship description information of the interaction relationship to obtain a target prompt word; and inputting the target prompt word into a code generation model to obtain the target embedded code matching the target code generation request.

[0005] This application also provides a target embedded code generation apparatus, comprising: a receiving unit for receiving a target code generation request, wherein the target code generation request includes a request description text, the request description text being used to indicate target embedded code applied to target hardware; a determining unit for determining, based on the parsing result of the request description text, at least one entity object associated with the target hardware and the interaction relationship between at least one entity object from an embedded knowledge graph, wherein the embedded knowledge graph includes entity nodes for respectively indicating multiple entity objects, and the connection relationship between the entity nodes being used to indicate the connection relationship between corresponding entity objects; a combining unit for combining, based on the entity description information of each of the at least one entity object and the relationship description information of the interaction relationship, to obtain a target prompt word; and an input unit for inputting the target prompt word into a code generation model to obtain the target embedded code matching the target code generation request.

[0006] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of the above-described method for generating embedded code when executing the computer program.

[0007] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of any of the above-described methods for generating embedded code.

[0008] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described methods for generating embedded code for a target.

[0009] This application demonstrates how, by receiving a target code generation request and parsing its description text, entity objects and their interactions closely related to the target hardware can be extracted from an embedded knowledge graph. This process effectively transforms natural language descriptions into an understanding of hardware characteristics, thereby generating prompts that accurately reflect hardware features and requirements. The generated prompts are then input into a code generation model to obtain embedded code that matches the target code generation request. This code can handle complex hardware-related details, including interactions between entities and specific hardware attributes such as communication protocols, interface types, and signal parameters, thus improving the accuracy of the generated embedded code and solving the technical problem of low accuracy in generated embedded code. Attached Figure Description

[0010] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 A hardware structure block diagram of a server device for a method of generating target embedded code provided in an embodiment of this application;

[0012] Figure 2 This is a schematic diagram of one of the optional methods for generating target embedded code according to an embodiment of this application;

[0013] Figure 3 This is a second schematic diagram of an optional method for generating target embedded code according to an embodiment of this application;

[0014] Figure 4 This is a third schematic diagram of an optional method for generating target embedded code according to an embodiment of this application;

[0015] Figure 5 This is a fourth schematic diagram of an optional method for generating target embedded code according to an embodiment of this application;

[0016] Figure 6 This is a fifth schematic diagram of an optional method for generating target embedded code according to an embodiment of this application;

[0017] Figure 7 This is a sixth schematic diagram of an optional method for generating target embedded code according to an embodiment of this application;

[0018] Figure 8 This is a schematic diagram (seventh) of an optional method for generating target embedded code according to an embodiment of this application;

[0019] Figure 9 This is a structural block diagram of a target embedded code generation apparatus according to an embodiment of this application;

[0020] Figure 10 This is a schematic diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0021] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0022] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0023] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0024] The methods and embodiments provided in this application can be executed on a server device or a similar computing device. Taking running on a server device as an example, Figure 1 This is a hardware structure block diagram of a computer device for a method of generating target embedded code according to an embodiment of this application. For example... Figure 1 As shown, the server device may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The server device may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the server equipment described above. For example, the server equipment may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0025] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the target embedded code generation method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thus implementing the above-described method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to server devices via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0026] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider for the server device. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0027] This embodiment provides a method for generating target embedded code. Figure 2 This is a flowchart of a method for generating target embedded code according to an embodiment of this application, such as... Figure 2 As shown, the process includes the following steps:

[0028] S202, Receive target code generation request, wherein the target code generation request includes request description text, which is used to indicate the target embedded code applied to the target hardware;

[0029] Optionally, in this embodiment, the target code generation request refers to the instruction issued by the user to generate specific code. It is the starting point for triggering the code generation process, so as to clarify the needs and direction of code generation.

[0030] Optionally, in this embodiment, the request description text may refer to, but is not limited to, the specific text content in the target code generation request that describes the code requirements in detail, and is used to elaborate on the relevant information of the code to be generated, such as application scenarios, functional requirements, and compatible hardware, so as to provide a specific basis for code generation.

[0031] It should be noted that when receiving a target code generation request from a user, the system also receives the natural language description, hardware schematic diagram file, chip manual, and other materials uploaded by the user along with the target code generation request. The system performs image recognition from the hardware schematic diagram to obtain the recognition result, and combines the chip manual and the recognition result with the uploaded natural language description to obtain the requested description text.

[0032] Optionally, in this embodiment, the target embedded code refers to the embedded program code that will eventually be generated and can run on the target hardware. Its purpose is to implement specific functions so that the target hardware works as expected, such as controlling the operation of the target hardware and processing data.

[0033] Optionally, in this embodiment, when a user sends a request for generating specific code, the request contains a descriptive text that specifies the embedded code to be generated that is suitable for the target hardware device. The code requirements are clarified through the request description text, ensuring that the generated code can accurately adapt to the target hardware and meet the requirements.

[0034] S204, based on the parsing result of the request description text, determine at least one entity object associated with the target hardware and the interaction relationship between at least one entity object from the embedded knowledge graph, wherein the embedded knowledge graph includes entity nodes for indicating multiple entity objects respectively, and the connection relationship between entity nodes is used to indicate the connection relationship between the corresponding entity objects.

[0035] Optionally, in this embodiment, the parsing result refers to the result obtained after parsing the request description text, which is used to provide a basis for the entity objects and relationships contained in the target embedded code. It may be, but is not limited to, filling the data element (JavaScript Object Notation, JSON) field after obtaining the entity objects contained in the text description information, the description information of the entity objects, and the information related to the target embedded code, and using the filled data element field as the parsing result.

[0036] Optionally, in this embodiment, the embedded knowledge graph refers to a knowledge graph database established based on the hardware connection relationships and communication links in the Baseboard Management Controller (BMC) system. The entities in the embedded knowledge graph can be, but are not limited to, defined as various functional modules in the BMC system.

[0037] To further illustrate, an optional embedded knowledge graph may include entities such as a baseboard management system, expansion modules, input / output (IO) expansion modules, temperature monitoring modules, voltage monitoring modules, fan modules, and storage modules. In the established knowledge graph database, entities contain attribute information. The attributes of an entity are defined as its specific name, chip model, and function. Entity attributes may also include, for example, the entity's power supply, drive current, operating system version, kernel version, and corresponding product model.

[0038] Optionally, in one embodiment, such as Figure 3 As shown, this is an exemplary embedded knowledge graph. Figure 3In the embedded knowledge graph shown, the baseboard control manager 302 is connected to the voltage control module 306 via an analog-to-digital converter 304. The baseboard control manager 302 is also connected to the fan control module 310 via a pulse width modulation (PWM) 308, and to the voltage control module 314 via a general-purpose input / output (GPIO) port 312. Furthermore, the voltage control module 314 also has an entity attribute 316. Figure 3 Other functional modules shown also have corresponding entity attributes, which are not shown in the figure.

[0039] Optionally, in this embodiment, the entity object may refer to, but is not limited to, the specific entity object corresponding to the entity node in the embedded knowledge graph, such as "A-type chip" or "I2C protocol", which can be used as the basic building block of the knowledge graph to record the description and attributes of the corresponding functional modules.

[0040] Optionally, in this embodiment, the interaction relationship between entity objects refers to the association method between different entity objects, which is used to reflect the hardware connection relationship and communication link relationship between various functional modules in the embedded system, such as "the chip connects to the sensor through the SPI protocol".

[0041] Optionally, in this embodiment, based on the parsing results of the request description text, at least one entity object associated with the target hardware and at least one interaction relationship between these entity objects are found from the embedded knowledge graph. This process clarifies the process from requirement parsing to knowledge graph query. By extracting entities and interaction relationships related to the target hardware, specific hardware association information and collaboration logic are provided for embedded code generation, so that the generated code conforms to the actual interaction rules between hardware.

[0042] S206, Target prompt words are obtained by combining the entity description information of at least one entity object and the relationship description information of the interaction relationship;

[0043] Optionally, in this embodiment, the entity description information of the entity object refers to the detailed description of each entity object in the embedded knowledge graph, which may include, but is limited to, the entity's attributes (such as hardware model and parameters), functions (such as sensor measurement type), characteristics (such as the transmission rate of the communication protocol), etc., and is used to provide basic information for constructing prompt words by providing specific features of the entity object.

[0044] Optionally, in this embodiment, the relationship description information of the interaction relationship refers to a specific description of the interaction relationship between entity objects, which is used to clarify the cooperation method and rules between entities and supplement the content of the interaction logic in the prompt words, and may include, but is not limited to, hardware connection relationship and communication link relationship.

[0045] It's important to note that hardware connectivity refers to the physical or electrical connections between different hardware entities. This defines the physical interfaces and connection paths between hardware components, forming the foundation of the embedded system's physical architecture. It directly impacts hardware layout design and wiring implementation, and serves as the basis for hardware initialization configuration in the code. For example, "The sensor is connected to the controller via pin A." Communication link connectivity refers to the logical connections between hardware entities that exchange data via communication protocols. This defines the rules and paths for data exchange between hardware components, determining the data transmission format and rate, enabling different hardware components to correctly parse and respond to each other's data. For instance, "The microcontroller communicates with the humidity sensor via bus A."

[0046] Optionally, in this embodiment, the target prompt word refers to the instruction text formed by integrating information such as entity object description and interaction relationship, which is used to convey the generation requirements of the target embedded code to the code generation model. It may include, but is not limited to, hardware information such as hardware adaptation, function implementation, and interaction logic.

[0047] Optionally, in this embodiment, detailed descriptions of at least one entity object obtained from the embedded knowledge graph are integrated with specific descriptions of the interaction relationships between these entity objects to form prompts for generating target embedded code. This clarifies the transformation process from knowledge graph information to code generation prompts. By integrating entity features and interaction logic, the prompts contain both specific hardware information and collaboration rules between entities, enabling the embedded code generated based on the prompts to accurately adapt to the interaction requirements of the target hardware and related entities.

[0048] S208, Input the target prompt word into the code generation model to obtain the target embedded code that matches the target code generation request.

[0049] Optionally, in this embodiment, the code generation model refers to a large language model with code generation capabilities, which receives target prompt words and automatically generates compliant embedded code based on its own trained embedded domain knowledge, so as to transform the requirements described in natural language into correct and executable embedded code.

[0050] Optionally, in this embodiment, the target embedded code refers to the embedded program output by the code generation model that matches the target code generation request.

[0051] Optionally, in this embodiment, the constructed target prompt words are input into the code generation model. Through the model's processing and generation capabilities, target embedded code that can meet the initially proposed code generation request is obtained. The transformation steps from requirement information to final embedded code are clarified. The structured prompt words are transformed into executable embedded code through the code generation model, realizing the automated generation from requirement description to actual code, improving the efficiency of embedded code development, and ensuring that the generated code meets the user's needs.

[0052] Through the embodiments of this application, by receiving a target code generation request and parsing the request description text, entity objects closely related to the target hardware and their interaction relationships can be extracted from the embedded knowledge graph. This process effectively converts natural language descriptions into an understanding of hardware characteristics, thereby generating prompts that accurately reflect hardware characteristics and requirements. The generated target prompts are then input into the code generation model to obtain embedded code that matches the target code generation request. This code can handle complex hardware-related details, including interaction relationships between entities and specific hardware attributes such as communication protocols, interface types, and signal parameters, thereby improving the accuracy of the generated embedded code.

[0053] As an optional approach, before determining at least one entity object associated with the target hardware and the interaction relationships between at least one entity object from the embedded knowledge graph based on the parsing results of the request description text, the method further includes:

[0054] S1, each of the at least one functional module of at least one reference hardware is determined as at least one reference entity object;

[0055] S2, determine the connection relationship between at least one reference entity object from the reference entity description information of each of the at least one reference entity object, wherein the reference entity description information is used to indicate the module type and module function of the functional module;

[0056] S3, based on at least one reference entity object and the connection relationship between at least one reference entity object, constructs an embedded knowledge graph.

[0057] Optionally, in this embodiment, reference hardware refers to an example hardware device used to construct a knowledge graph, which provides the source of entity objects and provides actual hardware basis for the construction of the knowledge graph, such as a certain type of microcontroller, temperature sensor and other hardware devices.

[0058] Optionally, in this embodiment, a functional module refers to a component in the reference hardware that has an independent function and can serve as a basic unit of knowledge graph entity objects, reflecting the functional composition of the hardware, such as a microcontroller's general-purpose input / output (GPIO) module, a sensor's data acquisition module, etc.

[0059] Optionally, in this embodiment, the reference entity object refers to the basic element of the knowledge graph transformed from the functional module of the reference hardware. It is used to represent the specific hardware functional module in the knowledge graph and is the basic node for constructing the graph.

[0060] Optionally, in this embodiment, the reference entity description information refers to the attribute information used to describe the reference entity object, so as to define the characteristics of the reference entity object and provide a basis for determining the relationship between entities. It may include, but is not limited to, module classes such as communication modules and computing modules, as well as module functions such as data transmission and logical operations.

[0061] It should be noted that the functional modules of the reference hardware are identified as reference entity objects in the knowledge graph; secondly, based on the descriptive information of these entity objects, such as module type and function, the connections between them are determined; finally, based on the entity objects and connections, a complete embedded knowledge graph is constructed. This clarifies the construction process of the embedded knowledge graph. By extracting functional modules and their relationships from specific reference hardware, scattered hardware knowledge is structured and networked to form reusable domain knowledge resources. This provides stable knowledge support for generating embedded code according to requirements, improving the accuracy of the generated embedded code.

[0062] In this embodiment, at least one functional module of each of at least one reference hardware is identified as at least one reference entity object. The connection relationships between the at least one reference entity objects are determined from their respective reference entity description information, where the reference entity description information indicates the module type and function of the functional module. An embedded knowledge graph is constructed based on the at least one reference entity object and the connection relationships between them. By extracting functional modules and their relationships from specific reference hardware, fragmented hardware knowledge is structured and networked to form reusable domain knowledge resources. This provides stable knowledge support for generating embedded code according to requirements, improving the accuracy of the generated embedded code.

[0063] As an optional approach, the connection relationship between at least one reference entity object is determined from the reference entity description information of each of the at least one reference entity object, including at least one of the following:

[0064] S1, determine at least one basic control connection relationship between at least one reference entity object from the reference entity description information of each of at least one reference entity object, wherein the connection relationship includes the basic control connection relationship;

[0065] S2, determine the data transmission connection relationship between at least one reference entity object from the reference entity description information of each of the at least one reference entity object, wherein the connection relationship includes the data transmission connection relationship;

[0066] S3, determine at least one system extended connection relationship between at least one reference entity object from the reference entity description information of each of the at least one reference entity object, wherein the connection relationship includes system extended connection relationship;

[0067] S4, determine the debugging interface connection relationship between at least one reference entity object from the reference entity description information of each of the at least one reference entity object, wherein the connection relationship includes the debugging interface connection relationship.

[0068] Optionally, in this embodiment, the basic control connection relationship refers to the connection method between reference entity objects used to implement control functions, which is used to ensure the transmission of control instructions in the system and realize basic hardware operation. It may include, but is not limited to, GPIO port connection, physical interface (Pin Connection, PIN) pin connection, digital-to-analog converter (DAC) pin connection, etc.

[0069] Optionally, in this embodiment, the data transmission connection relationship refers to the connection method used between reference entity objects to transmit data, enabling the effective transmission of data between different functional modules and providing support for data processing and analysis, and may include, but is not limited to, the following:

[0070] Optionally, in this embodiment, the system extension connection relationship refers to the connection method between reference entity objects used for system function extension, providing a hardware connection foundation for subsequent system function extension, enhancing the system's flexibility and scalability, and may include, but is not limited to, Serial Peripheral Interface (SPI) bus connection, Low Pin Count (LPC) interface connection, etc.

[0071] Optionally, in this embodiment, the debugging interface connection relationship refers to the connection method between reference entity objects for debugging purposes, which facilitates developers to debug, test and troubleshoot the system, and ensures the normal development and operation of the system. It may include, but is not limited to, Joint Test Action Group (JTAG) interface connection, In-System Programming (ISP) interface connection, etc.

[0072] Optionally, in this embodiment, the connections between reference entity objects used to implement control functions are identified based on their description information, so as to clarify the path and method of control command transmission in the system and provide a basis for the design of control logic in the embedded code.

[0073] Optionally, in this embodiment, the connection between reference entity objects for data transmission is determined based on their description information, so as to clarify the data transmission path between different modules and provide a reference for the implementation of data interaction logic in the code.

[0074] Optionally, in this embodiment, the connection for system function expansion is found based on the description information of the reference entity object, providing a basis for hardware connection for future system function expansion and ensuring that the expanded function can be successfully implemented.

[0075] Optionally, in this embodiment, the connection used for debugging is determined based on the description information of the reference entity object, so as to clarify the data interaction path during the debugging process and provide hardware connection support for developers to perform system debugging.

[0076] It should be noted that, starting from the description information of the reference entity objects, four types of connection relationships are identified between the reference entity objects: basic control, data transmission, system expansion, and debugging interfaces. At least one of these connection relationships is also defined. By extracting different types of connection relationships from the reference entity description information and clarifying these four types of connection relationships, the association information between entities in the embedded knowledge graph is enriched. This allows the knowledge graph to more comprehensively reflect the connection status of the hardware system, providing more detailed and comprehensive knowledge support for the subsequent generation of embedded code based on the knowledge graph that meets the actual hardware connection requirements, thus improving the accuracy of the generated target embedded code.

[0077] Through the embodiments of this application, basic control connection relationships between at least one reference entity object are determined from the reference entity description information of each of the at least one reference entity object, wherein the connection relationships include basic control connection relationships; data transmission connection relationships between at least one reference entity object are determined from the reference entity description information of each of the at least one reference entity object, wherein the connection relationships include data transmission connection relationships; system extension connection relationships between at least one reference entity object are determined from the reference entity description information of each of the at least one reference entity object, wherein the connection relationships include system extension connection relationships; and debug interface connection relationships between at least one reference entity object are determined from the reference entity description information of each of the at least one reference entity object, wherein the connection relationships include debug interface connection relationships. By clarifying these four types of connection relationships, the association information between entities in the embedded knowledge graph is enriched, enabling the knowledge graph to more comprehensively reflect the connection status of the hardware system. This provides more detailed and comprehensive knowledge support for subsequent generation of embedded code based on the knowledge graph that meets the actual hardware connection requirements, improving the accuracy of the generated target embedded code.

[0078] As an optional approach, target prompts are obtained by combining entity description information of at least one entity object with relationship description information of interaction relationships, including:

[0079] S1, retrieve the first code fragment that matches the parsing result from the code database, wherein the code database contains code fragments that match at least one entity object respectively;

[0080] S2, from the code database, determine at least one first reference code segment preceding the first code segment and at least one second reference code segment following the first code segment, as well as the first code segment;

[0081] S3, determine the target storage path based on at least one first reference code segment, at least one second reference code segment and the code storage path corresponding to each of the first code segments;

[0082] S4. Target prompt words are obtained based on the entity description information of at least one entity object, the relationship description information of the interaction relationship, and the combination of multiple target storage paths.

[0083] Optionally, in this embodiment, the code database refers to a collection that stores a large number of embedded code fragments. These code fragments correspond to entity objects in the knowledge graph, providing reusable code resources for code generation and serving as the basis for obtaining reference code.

[0084] Optionally, in this embodiment, the first code fragment refers to the code fragment selected from the code database that directly matches the parsing result. It can also be understood as a relevant code fragment that meets the requirements of the code acquisition request, serving as the basic fragment for generating the target code and directly associated with the core functionality of the requirement. In this embodiment, the first code fragment can be one or multiple first code fragments.

[0085] Optionally, in this embodiment, the first reference code segment refers to the code segment located before the first code segment, which may be code that has a prerequisite dependency or association with the first code segment, such as the initialization code of the first code segment.

[0086] Optionally, in this embodiment, the second reference code segment refers to the code segment located after the first code segment, which may be the subsequent logic or associated extended code of the first code segment, such as the execution code after data processing.

[0087] Optionally, in this embodiment, the code storage path refers to the storage location information of the code fragment in the database, which is used to identify the storage location of the code and provide a basis for determining the target storage path.

[0088] Optionally, in this embodiment, the target storage path refers to the comprehensive path determined based on the storage paths of the first code segment and its preceding and following reference code segments, which is used to locate the complete code logic chain related to the requirements, so as to improve the relevance and completeness of the code segment.

[0089] Optionally, in this embodiment, a first code fragment matching the request parsing result is selected from a database storing a large number of code fragments. These code fragments correspond to entity objects in the knowledge graph, providing basic fragments for subsequent code generation.

[0090] Next, in the code database, the preceding reference code located before the first code snippet is identified as the first reference code snippet, and the following reference code located after it is identified as the second reference code snippet. The first code snippet itself is also included, which can improve the dependencies and relevance of the code.

[0091] Then, based on the storage paths of the first code snippet and its preceding and following reference code snippets, the target storage path is determined comprehensively. This allows for the integration of related code snippets through path association, clarifying the code's organizational logic and calling relationships, and providing a structural reference for generating complete code.

[0092] Finally, the description information of the entity objects, the description of the interaction relationships between entities, and multiple target storage paths are integrated to form target prompts for code generation. This integrates hardware characteristics, interaction logic, and code resource paths into instructions, so that the generated code not only conforms to hardware characteristics but also has complete logical connections.

[0093] It's important to note that the process involves first selecting core code snippets, then extracting their related code, determining the code logic chain through storage paths, and finally generating prompts by combining entity information and interaction relationships. This completes the logical process from code resource extraction to prompt generation. By associating code snippets and integrating hardware knowledge with code paths, the generated prompts not only include hardware characteristics and interaction rules but also relate to actual, reusable code resources. This provides more specific and actionable guidance for the code generation model, ensuring that the generated code meets requirements and possesses completeness and executability.

[0094] In this embodiment, a first code fragment matching the parsing result is obtained from a code database, wherein the code database contains code fragments that match at least one entity object respectively. From the code database, at least one first reference code fragment preceding the first code fragment and at least one second reference code fragment following the first code fragment are determined, along with the first code fragment itself. A target storage path is determined based on the code storage paths corresponding to the at least one first reference code fragment, the at least one second reference code fragment, and the first code fragment. A target prompt word is obtained by combining the entity description information of each of the at least one entity object, the relationship description information of the interaction relationship, and multiple target storage paths. By associating code fragments and integrating hardware knowledge with code paths, the generated prompt word includes both hardware characteristics and interaction rules, and is associated with practically reusable code resources, providing more specific and operable guidance for the code generation model, ensuring that the generated code meets requirements and possesses completeness and executability.

[0095] As an optional approach, target prompts are obtained based on entity description information of at least one entity object, relationship description information of interaction relationships, and combinations of multiple target storage paths, including:

[0096] S1, combine the entity description information of at least one entity object, the relationship description information of the interaction relationship, and multiple code storage paths to obtain combined information;

[0097] S2, input the combined information into the natural language processing model, where the natural language processing model is used to perform natural language processing;

[0098] S3 determines the output of the natural language processing model as the target prompt word.

[0099] Optionally, in this embodiment, the combined information refers to the comprehensive information set formed by integrating entity description information, relationship description information, and code storage path, which is used to gather various types of information required to generate prompt words and serve as the input basis for the natural language processing model.

[0100] Optionally, in this embodiment, the natural language processing model refers to a large language model that has the ability to process and generate natural language. It is used to process, integrate and optimize combined information at the language level, and transform scattered information into standardized and coherent natural language text.

[0101] Optionally, in this embodiment, the description information of entity objects, the description of interaction relationships between entities, and multiple code storage paths are integrated to form a combined information containing multiple types of key information. Its function is to aggregate scattered hardware knowledge, interaction logic, and code resource clues, providing a comprehensive information foundation for subsequent generation of prompt words.

[0102] Next, the combined information is input into a natural language processing model. The model's function is to process natural language, such as integrating, optimizing, and standardizing it. By leveraging the model's language processing capabilities, the combined information is transformed into structured and natural language, thus solving the problems of fragmented information and non-standardized expression.

[0103] Finally, the output of the natural language processing model is defined as the target prompt word, which clarifies the instruction text used to guide code generation, making the target prompt word highly readable and instructive, and able to be accurately understood by the code generation model.

[0104] It should be noted that, firstly, entity descriptions, interaction relationships, and code storage paths are integrated to form combined information; then, this combined information is input into a natural language processing model for processing; finally, the model's output is determined as the target prompt word. Through systematic information integration and natural language processing, multi-source and fragmented information is transformed into standardized prompt words. This ensures that the prompt words can fully cover hardware characteristics, interaction logic, and code resource associations, and can guide the code generation model in a clear natural language format, thereby improving the accuracy and applicability of the generated code.

[0105] In this embodiment, entity description information, interaction relationship description information, and multiple code storage paths of at least one entity object are combined to obtain combined information. This combined information is then input into a natural language processing (NLP) model, which performs NLP processing. The output of the NLP model is determined as the target prompt word. Through systematic information integration and NLP processing, multi-source and fragmented information is transformed into standardized prompt words. These prompt words comprehensively cover hardware characteristics, interaction logic, and code resource associations, and guide the code generation model in a clear natural language format, improving the accuracy and applicability of the generated code.

[0106] As an optional approach, the target storage path is determined based on at least one first reference code segment, at least one second reference code segment, and the code storage path corresponding to each of the first code segments, including:

[0107] S1, determine at least one second code segment that satisfies the filtering criteria from the first code segment, at least one first reference code segment, and at least one second reference code segment;

[0108] S2, determine at least one third reference code segment and a fourth reference code segment corresponding to each of the second code segments, wherein the third reference code segment is the code segment located before the second code segment, and the fourth reference code segment is the code segment located after the second code segment;

[0109] S3. Determine the target storage path based on the code paths of the third reference code fragment, the fourth reference code fragment, and the second code fragment.

[0110] Optionally, in this embodiment, the filtering criteria are standards used to select code snippets that better meet the requirements from existing code snippets (such as functional matching degree, hardware compatibility, etc.), which are used to accurately locate high-quality and highly relevant code resources.

[0111] Optionally, in this embodiment, the second code snippet refers to the code snippet obtained after filtering from the first code snippet and the reference code snippets before and after it, as a core code candidate that is closer to the requirements, thereby improving the accuracy of code generation.

[0112] Optionally, in this embodiment, the third reference code segment refers to the preceding code segment located before the second code segment. It is a dependency or preceding logic of the second code segment to ensure the prerequisites and logical coherence required for the second code segment to run.

[0113] Optionally, in this embodiment, the fourth reference code segment refers to a subsequent code segment located after the second code segment, which is the subsequent logic or extension of the second code segment to ensure the integrity and relevance of the subsequent logic of the second code segment.

[0114] Optionally, in this embodiment, the code path refers to the storage location identifier of the code fragment in the database, which is used to locate the storage location of the code fragment and provides a basis for determining the target storage path.

[0115] Optionally, in this embodiment, the target storage path refers to the path determined by comprehensively considering the code paths of the second code segment and its preceding and following reference code segments, such as the third and fourth reference code segments, identifying a complete code logic chain that highly matches the requirements, and providing accurate resource location for code generation.

[0116] Optionally, in this embodiment, at least one second code segment that meets preset conditions is selected from the first code segment, its preceding first reference code segment, and its following second reference code segment. The purpose is to extract code segments that better match the requirements through a selection mechanism, thereby improving the relevance and quality of code resources.

[0117] Next, for each second code snippet, a third reference code snippet preceding it and a fourth reference code snippet following it are found to obtain the complete logical context of the second code snippet, ensuring the dependencies and logical coherence between code snippets.

[0118] Finally, based on the storage paths of the second code snippet and its corresponding third and fourth reference code snippets, the target storage path is determined comprehensively. By integrating the complete logical chain of high-quality code snippets through path association, the code's organizational structure and calling relationships are clarified, providing a location basis for the subsequent generation of complete and related code.

[0119] It's important to note that the process of selecting multiple code snippets that best meet the requirements from existing code snippets, obtaining their complete logical context, and ultimately determining the target storage path involves: first, selecting a second code snippet that better meets the criteria from the initial code snippets; then, finding the related reference code; and finally, determining the target storage path based on the paths of these code snippets. By filtering multiple code segments and integrating their logical chains, the quality and relevance of code resources are improved, ensuring that the code logic chain pointed to by the target storage path highly matches the requirements. This provides a reliable resource location foundation for subsequently generating accurate, complete, and reusable embedded code, further improving the efficiency and accuracy of code generation.

[0120] Through the embodiments of this application, at least one second code segment that meets the filtering criteria is determined from a first code segment, at least one first reference code segment, and at least one second reference code segment; a third reference code segment and a fourth reference code segment corresponding to each of the at least one second code segment are determined, wherein the third reference code segment is the code segment located before the second code segment, and the fourth reference code segment is the code segment located after the second code segment; based on the third reference code segment and the fourth reference code segment, the target storage path is determined for the code path of each second code segment. By filtering and integrating multiple code segments and their logical chains, the quality and relevance of code resources are improved, ensuring that the code logical chain pointed to by the target storage path is highly matched with the requirements, providing a reliable resource location basis for the subsequent generation of accurate, complete, and reusable embedded code, and further improving the efficiency of code generation.

[0121] As an optional approach, in the process of obtaining target prompt words by combining entity description information of at least one entity object and relationship description information of interaction relationships, the method further includes:

[0122] S1, if no reference embedded code related to the target embedded code is found, obtain a hardware knowledge set based on the parsing results, wherein the hardware knowledge set is used to describe at least one functional module included in the parsing results;

[0123] S2, determine the reference hardware information associated with the analysis results from the hardware knowledge set;

[0124] S3, combine the entity description information of at least one entity object, the relationship description information of the interaction relationship, and the reference hardware information to obtain the target prompt word.

[0125] Optionally, in this embodiment, the reference embedded code refers to existing reference code in the code database that is related to the target embedded code, which can provide a basis for reference and reuse in the generation of the target code.

[0126] Optionally, in this embodiment, the hardware knowledge set is a set of knowledge that provides specifications, specific descriptions, etc. of functional modules when reference code is lacking, providing a basis for understanding hardware characteristics and generating adaptation code. It may be, but is not limited to, a chip manual, or an official document containing detailed information such as the functional modules, pin definitions, communication protocols, and register configurations of the target hardware.

[0127] Optionally, in this embodiment, the reference hardware information refers to hardware details related to the parsing results extracted from the hardware knowledge set. It is used to provide hardware reference when there is no reference code to assist in the construction of prompt words. It may include, but is not limited to, reference information such as the characteristics and functional module configuration of similar hardware.

[0128] Optionally, in this embodiment, when it is determined that the target code request has no relevant reference code, the corresponding hardware knowledge set, such as a chip manual, is obtained based on the parsing result of the request. This manual is used to describe in detail the functional modules involved in the parsing result. The chip manual supplements the hardware details of the functional modules, such as pin functions and operating parameters, providing the hardware technical basis for subsequent prompt word generation.

[0129] Next, relevant reference hardware information, such as the module and hardware model corresponding to the functional requirements, is filtered out from the chip manual. This includes timing requirements and configuration steps of the module. In this way, the hardware technical details directly related to the current requirements are extracted from the manual, avoiding information redundancy.

[0130] Finally, the descriptions of entity objects, the explanations of interactions between entities, and the reference hardware information extracted from the chip manual are integrated to form target prompts. By combining the hardware details in the chip manual with the entity relationships in the knowledge graph, the prompts include both the technical parameters of the hardware and the interaction logic, ensuring that the code generation model can generate embedded code that conforms to the physical characteristics of the chip.

[0131] It's important to note that the process begins by retrieving the corresponding chip datasheet based on the parsing results. Hardware technical information relevant to the requirements is then extracted from this datasheet. Finally, this information is combined with entity descriptions and interaction relationships to generate prompts. This ensures that the chip datasheet serves as the core information source when reference code is lacking. By extracting hardware details from the datasheet, the gaps in code reference are filled, ensuring that the generated prompts accurately reflect the physical characteristics and technical requirements of the hardware. Ultimately, this guides the generation of embedded code adapted to the target chip, improving the accuracy of embedded code generation.

[0132] In this embodiment, when no reference embedded code related to the target embedded code is found, a hardware knowledge set is obtained based on the parsing results. This hardware knowledge set describes at least one functional module included in the parsing results. Reference hardware information associated with the parsing results is determined from the hardware knowledge set. The entity description information and interaction relationship description information of at least one entity object are combined with the reference hardware information to obtain the target prompt. By extracting hardware details from the manual, gaps in code reference are filled, ensuring that the generated prompt accurately reflects the physical characteristics and technical requirements of the hardware. Ultimately, this guides the generation of embedded code adapted to the target chip, improving the accuracy of embedded code generation.

[0133] As an alternative approach, reference hardware information associated with the parsing results is determined from a hardware knowledge set, including:

[0134] S1. Based on the directory information, parsing results, entity description information of at least one entity object, and relationship description information of interaction relationships of the hardware knowledge set, determine the chapter identifier information and page number identifier information from the hardware knowledge set.

[0135] S2, determine the reference hardware information from the hardware knowledge set based on the chapter identifier information and page number identifier information.

[0136] Optionally, in this embodiment, the directory information refers to the directory structure of the hardware knowledge set, which records the topics of each chapter and the corresponding page numbers, so as to quickly locate the content area related to the requirements in the manual.

[0137] Optionally, in this embodiment, the chapter identification information refers to the chapter number or title in the hardware knowledge set, in order to identify a specific content section in the manual and accurately locate the chapter where the relevant hardware information is located.

[0138] Optionally, in this embodiment, the page number identification information refers to the page number corresponding to the content in the hardware knowledge set, so as to further refine the information to a specific page and quickly find the required hardware-related information.

[0139] Optionally, in this embodiment, by combining the chip manual's table of contents, request parsing results, entity object descriptions, and interaction relationship explanations, the chapter number and specific page number of the relevant content can be found in the manual. Through multi-dimensional information matching, the location of the content related to the requirement in the manual can be accurately located, avoiding blind searching and improving information extraction efficiency.

[0140] Next, based on the found chapters and page numbers, the corresponding hardware technical details are extracted from the chip manual. Based on the location, hardware information highly relevant to the needs is obtained, ensuring that the extracted content is related to the user's code retrieval request, thus providing reliable technical support for the subsequent generation of prompt words.

[0141] It should be noted that, firstly, the chapters and page numbers of relevant content are determined by combining the table of contents, parsing results, entity descriptions, and interaction relationships. Then, reference hardware information is extracted from the manual based on this information, thus establishing a process for extracting the required information from the chip. Through table of contents navigation and multi-dimensional information matching, hardware technical details related to the requirements are located and obtained, ensuring the accuracy and relevance of the reference hardware information. This provides a basis for subsequently generating prompts that conform to hardware characteristics, improving the accuracy of obtaining the target embedded code.

[0142] Through the embodiments of this application, based on the directory information of the hardware knowledge set, the parsing results, and the entity description information of at least one entity object, as well as the relationship description information of the interaction relationship, chapter identifier information and page number identifier information are determined from the hardware knowledge set; reference hardware information is then determined from the hardware knowledge set based on the chapter identifier information and page number identifier information. By using directory navigation and multi-dimensional information matching, hardware technical details related to the requirements are located and obtained, ensuring the accuracy and relevance of the reference hardware information. This provides a basis for subsequently generating prompts that conform to hardware characteristics, improving the accuracy of obtaining the target embedded code.

[0143] As an optional approach, in the process of determining at least one entity object associated with the target hardware and the interaction relationships between at least one entity object from the embedded knowledge graph based on the parsing results of the request description text, the method further includes:

[0144] Based on the parsing results, guide information is determined from the hardware vector knowledge base. The guide information is used to represent the specifications corresponding to the target hardware. The hardware vector knowledge base includes guide information that is related to the target hardware.

[0145] Optionally, in this embodiment, the hardware vector knowledge base refers to a vector knowledge base that converts hardware-related documents into vector form for storage and supports semantic retrieval through vectors. It may, but is not limited to, a vector knowledge base built based on Retrieval-Augmented Generation (RAG) technology, which provides a foundation for structured storage and fast querying of hardware specification information and improves the accuracy of obtaining hardware specification information.

[0146] Optionally, in this embodiment, the guide information refers to information used to represent the technical specifications, interface requirements, communication rules, etc. corresponding to the target hardware. It may include, but is not limited to, unstructured text data such as adaptation guidance documents, application programming interface (API) documents, protocol documents, and chip manuals, providing hardware adaptation standards and operational guidelines for embedded code generation.

[0147] It should be noted that, based on the parsing results of the code generation request, the specification information corresponding to the target hardware is quickly retrieved from the RAG vector knowledge base of unstructured text related to storage hardware, such as manuals and protocol documents, as guide information. This guide information clarifies the technical standards and adaptation requirements of the target hardware, thereby optimizing the generation of target prompt words. This ensures that the obtained prompt words follow the guide information, further improving the accuracy and efficiency of the obtained embedded code.

[0148] In this embodiment of the application, guideline information is determined from a hardware vector knowledge base based on the parsing results. This guideline information represents the specifications corresponding to the target hardware, and the hardware vector knowledge base includes guideline information related to the target hardware. Based on the parsing results of the code generation request, specification information corresponding to the target hardware is quickly retrieved from a RAG vector knowledge base containing unstructured text related to hardware, such as manuals and protocol documents, as guideline information. This guideline information clarifies the technical standards and adaptation requirements of the target hardware, thereby optimizing the generation of target prompts and ensuring that the obtained prompts follow the guideline information, further improving the accuracy and efficiency of the obtained embedded code.

[0149] As an optional approach, after receiving the target code generation request, the following is also included:

[0150] S1, Perform a requirement determination operation on the request description text to obtain the requirement determination result;

[0151] S2, if the requirement determination result indicates that the request description text meets the target requirement conditions, input the request description text into the code generation model to obtain the target code that matches the request target code generation request, wherein the target requirement conditions are used to indicate that the request description text is used to generate non-embedded code.

[0152] Optionally, in this embodiment, the requirement determination operation refers to the process of analyzing and judging the request description text to determine the code generation requirement type pointed to by the text, so as to filter and classify the code generation requirements and provide a basis for the selection of subsequent processing methods.

[0153] Optionally, in this embodiment, the requirement determination result is the conclusion obtained after the requirement determination operation, which is used to clarify whether the request description text meets specific conditions, such as whether it is a non-embedded code generation requirement, so as to guide the subsequent code generation process.

[0154] Optionally, in this embodiment, the target requirement condition refers to a preset standard used to define the type of request description text, used to indicate that the request description text is used to generate non-embedded code, and is the basis for determining whether to directly use the code generation model to generate target code.

[0155] Optionally, in this embodiment, the user's request description text is judged to determine the type of requirement, and the requirement determination result is obtained. This determination clarifies whether the request belongs to the requirement of generating non-embedded code, providing a basis for decision-making on whether to directly call the code generation model and avoiding the use of inappropriate processing procedures for embedded code requirements.

[0156] Next, when the requirement determination result shows that the request description text meets the target requirement conditions for generating non-embedded code, the request description text is input into the code generation model to generate target code that matches the user's requirements. This allows for the direct and rapid generation of corresponding code for non-embedded code requirements, simplifying the process and improving the efficiency of non-embedded code generation.

[0157] It's important to note that the request description text is first assessed for its suitability. If the assessment determines that the text pertains to generating non-embedded code, it is directly input into the code generation model to generate matching target code, thus clarifying the processing path for non-embedded code generation requests. By differentiating request types through the requirement assessment process and directly calling the model to generate eligible non-embedded code requests, the targeting and efficiency of code generation are improved, ensuring that different types of code generation requests are handled appropriately.

[0158] In this embodiment, a requirement determination operation is performed on the request description text to obtain a requirement determination result. If the requirement determination result indicates that the request description text meets the target requirement conditions, the request description text is input into the code generation model to obtain the target code that matches the target code generation request. The target requirement conditions are used to indicate that the request description text is used to generate non-embedded code. By distinguishing requirement types through the requirement determination operation, and directly calling the model to generate non-embedded code that meets the conditions, the efficiency of code generation is improved.

[0159] As an optional approach, before determining at least one entity object associated with the target hardware and the interaction relationships between at least one entity object from the embedded knowledge graph based on the parsing results of the request description text, the method further includes:

[0160] S1, if the first validity check result of the parsed result does not meet the check conditions, display a check failure message;

[0161] S2, if the number of rewrites is less than or equal to the target number, the request description text is rewritten based on the first legality check result to obtain the rewritten request description text, wherein the number of rewrites is used to indicate the number of times the request description text has been rewritten.

[0162] Optionally, in this embodiment, the first legality verification result refers to the conclusion drawn after performing a legality check on the parsing result, in order to determine whether the request description text meets the conditions for further processing. It may include, but is not limited to, parameter legality verification such as regular expression format legality verification, numerical range legality verification, and string spelling legality verification.

[0163] Optionally, in this embodiment, the rewrite count refers to the number of times the request description text has been rewritten, limiting the maximum number of rewrites to avoid infinite loop rewriting. The target count refers to the preset maximum number of times the request description text is allowed to be rewritten, controlling the termination condition of the rewrite process and ensuring that the code generation process is efficient.

[0164] Optionally, in this embodiment, the rewritten request description text refers to the text obtained by modifying the original request description text based on the first legality verification result, so as to correct the problems in the original text and make it more likely to pass the legality verification.

[0165] Optionally, in this embodiment, when the validity check of the parsing result fails to meet the preset check conditions, a prompt message indicating that the check has failed is displayed to the user, so as to provide timely feedback on the problems in the request description text, prompt the user with error information, and automatically modify it based on the error to ensure that subsequent processing can be based on valid input.

[0166] Next, if the number of rewrites performed has not exceeded the maximum allowed target number, the request description text is modified according to the first validity check result to obtain the rewritten text. This allows for attempts to correct the original text within the allowed number of times, increasing the probability that the request description text passes the validity check and improving the accuracy of generating the target embedded code.

[0167] It should be noted that, initially, a message indicating that the validation failed is displayed; if the number of rewrites has not exceeded the target number, the request description text is rewritten based on the validation result. By establishing an error correction mechanism for the request description text, guiding the user or system to make corrections based on the prompts, and setting a limit on the number of rewrites to avoid invalid rewrites, it is ensured that the input request description text ultimately meets the legality requirements, providing qualified basic data for subsequent processes such as code generation.

[0168] In this embodiment, if the first validity check result of the parsed result does not meet the verification conditions, a verification failure message is displayed. If the number of rewrites is less than or equal to the target number, the request description text is rewritten based on the validity check result to obtain the rewritten request description text. The number of rewrites indicates the number of times the request description text has been rewritten. By establishing an error correction mechanism for the request description text, guiding the user or system to make corrections based on prompts, and setting a limit on the number of rewrites to avoid invalid rewrites, it is ensured that the input request description text ultimately meets the validity requirements, providing qualified basic data for subsequent code generation and other processes.

[0169] As an optional approach, after rewriting the request description text based on the first validity check result to obtain the rewritten request description text, the following steps are also included:

[0170] S1, perform parameter validity verification on the parsing result of the rewritten request description text to obtain the second validity verification result;

[0171] S2, if the second legality verification result does not meet the verification conditions and the number of rewrites is greater than the target number, an exception report is displayed, wherein the exception report is used to indicate that the target embedded code generation failed and that the parameters in the rewritten request description text failed the parameter legality verification.

[0172] S3, the rewritten request description text is sent to the description text review node, wherein the text review node is used to review the rewritten request description text.

[0173] Optionally, in this embodiment, the exception report refers to the report generated when the number of rewrites exceeds the target number and the verification still fails, so as to provide feedback to the system on the result of the failure to generate the target embedded code and the specific parameters of the failure to pass the verification, thereby clarifying the problem.

[0174] Optionally, in this embodiment, the description text review node may refer to, but is not limited to, the link or system module responsible for reviewing the rewritten request description text, and is used to manually review text that has failed verification after multiple rewrites to determine whether it can be further processed or needs to be resubmitted by the user.

[0175] Optionally, in this embodiment, the parsing result of the rewritten request description text is subjected to parameter validity verification to obtain a second validity verification result. By verifying whether the rewritten text solves the parameter-level problem, it is determined whether it meets the conditions for subsequent processing, providing a basis for the next step.

[0176] If the second validity check result does not meet the validation conditions and the number of rewrites exceeds the target number, an exception report is displayed. This report indicates that the target embedded code generation failed and that the parameters in the rewritten request description text failed the parameter validity check. If multiple corrections are ineffective, the automatic rewrite process is terminated. The exception report clearly indicates the reason for the failure and the specific problematic parameters, avoiding resource waste and providing clear correction directions for users or reviewers.

[0177] Finally, the rewritten request description text is sent to the description text review node for review. This step serves to introduce a dedicated review process for text that fails validation after multiple rewrites, potentially involving manual intervention to determine if there are special circumstances or if the user needs to redescribe their requirements.

[0178] It should be noted that by ensuring input quality through parameter validation, avoiding invalid loops through limit on the number of iterations, clarifying problems through exception reports, and providing further processing possibilities through review nodes, we can ensure that user needs can be properly handled even in complex situations, thereby improving the success rate of generating target embedded code.

[0179] In this embodiment, parameter validity verification is performed on the parsing result of the rewritten request description text to obtain a second validity verification result. If the second validity verification result does not meet the verification conditions and the number of rewrites exceeds the target number, an exception report is displayed. This exception report indicates that the target embedded code generation failed and that parameters in the rewritten request description text failed the parameter validity verification. The rewritten request description text is then sent to a description text review node, which reviews the rewritten request description text. This approach ensures input quality through parameter verification, avoids invalid loops through number limit, clarifies problems through exception reports, and provides further processing possibilities through review nodes. This ensures that user needs can be properly handled even in complex situations, thereby improving the success rate of target embedded code generation.

[0180] As an optional approach, in order to better understand the process of generating the target embedded code described above, the following description of the execution flow of the method for generating the target embedded code is further illustrated with reference to optional embodiments, but this is not intended to limit the technical solutions of the embodiments of this application.

[0181] It should be noted that, taking the development of the baseboard management controller software as an example, the development process exhibits a high degree of hardware-software coupling. Physical layer information such as hardware topology, board connection relationships, and interface protocols needs to be expressed through unstructured data carriers such as hardware schematics and wiring diagrams. Since current multimodal large-scale models have not yet achieved breakthroughs in areas such as image semantic understanding and cross-modal information fusion, relying solely on traditional text-based prompting is insufficient to accurately translate complex hardware constraints into executable code requirements.

[0182] To address the above issues, this embodiment proposes an innovative engineering solution. Through a structured input system, key information such as hardware connection topology and interface protocols are formally modeled to ensure accurate expression and effective transmission of hardware semantics. Simultaneously, a Behavior Tree control mechanism is introduced. By imposing fine-grained constraints on the execution path of the large model, the development task can be broken down into stages and the execution nodes precisely controlled. This allows the large model to focus on implementing simple tasks, improving the accuracy of code implementation.

[0183] Optionally, such as Figure 4 As shown, this is the behavior tree flow provided in this embodiment, such as... Figure 4 As shown, it includes the following steps:

[0184] S402, Execute the root node (sequential node);

[0185] S404, execute the decorator node, and you can initiate a retry (limited number of times).

[0186] S406, the requirements analysis is performed by agent A;

[0187] S408, Agent B prepares knowledge;

[0188] S410, Agent E prepares knowledge;

[0189] S412, agent G generates prompt words;

[0190] S414, agent H generates code.

[0191] Optional, such as Figure 5 As shown, S408 also includes the following steps:

[0192] S408, Agent B prepares knowledge and executes child nodes sequentially;

[0193] S502, the decorator node, can initiate retries (with a limited number of attempts), and agent C extracts parameters;

[0194] S504, Perform parameter validity verification on the content extracted by agent C;

[0195] S506, Perform regular expression validation on the content extracted by agent C;

[0196] S508, Performs a numerical range validity check on the content extracted by agent C;

[0197] S510 performs string spelling validity verification on the content extracted by agent C;

[0198] S512, Knowledge Base Retrieval;

[0199] S514, extracted from the codebase of agent D, is executed twice.

[0200] Optional, such as Figure 6 As shown, S410 further includes the following steps:

[0201] S410, Agent E prepares knowledge and executes child nodes sequentially;

[0202] S602, the decorator node, can initiate retries (with a limited number of attempts), and agent C extracts parameters;

[0203] S604, Perform parameter validity verification on the content extracted by agent C;

[0204] S606, Perform regular expression validation on the content extracted by agent C;

[0205] S608, Perform a numerical range validity check on the content extracted by agent C;

[0206] S610 performs string spelling validity verification on the content extracted by agent C;

[0207] S612, Knowledge Base Retrieval;

[0208] S614, Extract the document directory;

[0209] S616, Agent F obtains the chapter name;

[0210] S618, Extract chapter content;

[0211] S620, the intelligent agent F performs knowledge condensation.

[0212] The specific steps of the entire behavior tree are as follows:

[0213] S1, user input: natural language description, hardware schematic file (such as a file generated by EDA software like Altium Designer or Allegro, optional), and chip datasheet (optional). The behavior tree proceeds to the root node – sequential nodes. The root node will execute all its child nodes sequentially, starting with the left child node – the decorator node.

[0214] S2, the decorator node is a retry node. Its function is to append error information to the prompt after the task execution of this node fails, and then continue to initiate a retry. The execution order of the decorator node is the same as that of the sequence node. After the retry operation is completed, the behavior tree enters the left child node of the decorator node - the selector node;

[0215] S3, the selector node is the processing node for agent A. Agent A will analyze and summarize the problem based on the input prompts, dividing it into three categories of requirements:

[0216] 1) Existing code is adapted for different device models;

[0217] 2) No relevant code is available; the original code needs to be generated based on the manual.

[0218] 3) Other code generation tasks that do not fall into the above two categories.

[0219] When agent A determines the requirement to be S3-1 or S3-2, it executes the left child node and the right child node respectively; when agent A determines the requirement to be S3-3, it directly returns True, then returns to the root node and enters the right child node agent G.

[0220] S3-1, when the requirement is determined to be 1), proceed to the knowledge preparation node of agent B. This node is a sequential node, which will execute all its child nodes sequentially and summarize the execution results of all child nodes. Then, proceed to the child node agent C to extract parameters.

[0221] In S3-1-1, agent C is responsible for extracting key information from the user's input. An example prompt word is as follows:

[0222] "Based on user input, extract keywords to populate JSON fields. Leave unknown information blank (e.g., if the user does not mention the processor model, then 'Processor Signal' will be empty). If the user mentions 'BMC Environment,' automatically fill in the runtime environment as 'BMC.' The JSON fields are as follows: {"Task Type":"Code Adaptation","Device Information":{"Processor Model":"","Development Environment":"","Runtime Environment":""},"Functional Requirements":{"Chip Name":"","Core Functions":"","Communication Bus":"","Communication Address":"","Communication Link":"","Other Parameters":{}},"Code Adaptation":{"Reference Code Retrieval":{"Keywords":[],"File Path":""},"Functions to be Retained":[],"Modify Parameters":{}}}."

[0223] After extracting key information, the system proceeds to the left and right child nodes to perform parameter validity checks. These checks include, but are not limited to, regular expression format validation, numerical range validation, and string spelling validation. A successful validation returns True, otherwise False. It's important to note that parameter validity checks only verify the validity of parameters, not empty parameters. The JSON fields returned by the agent may still contain a significant amount of empty data. For example, when the user provides the prompt "Write code to implement temperature monitoring for TMP112," the agent may not be able to infer most of the fields in "Functional Requirements" and "Code Adaptation," and may only obtain the "Chip Name" field.

[0224] S3-1-2, After completing the extraction of key information, begin searching the knowledge base. The knowledge base includes a RAG vector knowledge base and a server BMC hardware knowledge graph. The RAG vector knowledge base contains unstructured text data such as adaptation guidance documents, API documents, protocol documents, and chip manuals. The RAG vector knowledge base is constructed using conventional methods and approaches; this embodiment does not specify detailed requirements for the establishment, composition, and retrieval methods of the RAG knowledge base.

[0225] The server BMC hardware knowledge graph is a knowledge graph database built upon the hardware connection relationships and communication links within the server BMC system. Entities are defined as various functional modules within the BMC system; for example, one definition format is:

[0226] Correspondingly, these represent the baseboard management system, expansion module, IO expansion module, temperature monitoring module, voltage monitoring module, fan module, and storage module, respectively.

[0227] In the established knowledge graph database, entities contain attribute information. The attributes of an entity are defined as its specific name, chip model, and function. Entity attributes may also include, for example, the entity's power supply (if any), drive current (if any), operating system version (if any), kernel version (if any), and corresponding product model.

[0228] In this embodiment, the entities and their corresponding attributes are as follows: when the entity is a baseboard management system, the corresponding attributes are the entity name, chip model, operating system, kernel version, product model corresponding to the BMC, and chip manual name; when the entity is an input / output (Input / Output) system, the corresponding attributes are: entity name, chip model, operating system, kernel version, product model corresponding to the BMC, and chip manual name; when the entity is an input / output system, the corresponding attributes are: input / output system, chip model ... Expansion modules, Inter-Integrated Circuit (IIC) When implementing expansion modules, temperature monitoring modules, voltage monitoring modules, fan modules, and storage modules, the entity implementation can include the entity name, chip model, chip datasheet name, and module functional description. Relationships exist between entities; one type of relationship definition is as follows (used for modeling communication links in a hardware system): Correspondingly, these represent GPIO port connection, bus connection, expansion module connection, LPC interface connection, IO expansion module connection, SPI bus connection, PIN pin connection, and JTAG interface connection, respectively.

[0229] In this embodiment, the relationship includes the attributes of the relationship. For example, in GPIO port connection, bus connection, expansion module connection, LPC interface connection, IO expansion module connection, SPI bus connection, PIN pin connection, and JTAG interface connection, the attributes can be the name of the relationship, the communication address, the communication direction, the supported communication protocol, the name of the manual document corresponding to the communication protocol, etc.

[0230] A well-defined server BMC hardware communication link knowledge graph, such as Figure 7As shown, the baseboard control manager 702 is connected to the chip 706 via the integrated circuit bus 704. The baseboard control manager 702 is also connected to the fan control module 710 via the speed feedback signal 708, the voltage control module 714 via the analog-to-digital converter 712, the fan control module 718 via pulse width modulation 716, and the voltage control module 722 via the general purpose input / output port 720. The chip 706 is connected to the temperature sensor module 726 via the general purpose input / output port 724, and the voltage control module 730 via the integrated circuit bus 728. In addition, each entity in the figure has corresponding entity information, which is not shown in the figure.

[0231] Based on key information from the JSON fields obtained in S3-1-1, such as the "chip name" field, the server's BMC hardware communication link knowledge graph is retrieved to obtain the communication link, communication address, and communication protocol from the BMC to the specified chip. All obtained information is structured JSON text. For example, to query the communication link from the BMC to Inlet Temp0, the following query statement can be used: `MATCH path=(bmc:BMC{name:"BMC"})-[r*]->(temp:temperature{name:"InletTemp0"})RETURN path`, which will return information such as... Figure 8 The figure is based on Figure 7 The communication link for querying and its corresponding description information (JSON format) are as follows: The baseboard control manager 702 is connected to the chip 706 through the integrated circuit bus 704, and the chip 706 is connected to the temperature sensor module 726 through the general-purpose input / output port 724.

[0232] In summary, after completing the knowledge base retrieval, structured text information of hardware connection data is obtained. In this embodiment, neo4j is used to construct a graph database.

[0233] In step S3-1-3, after completing the knowledge base retrieval, the behavior tree enters the agent D node. This node is a recurring execution node, executed twice. The first input is the key information provided by agent C. Agent D extracts keywords from the reference code, initiates a query request to the code repository management software, and retrieves relevant code snippets and context information. Then, agent D analyzes the relevant code snippets and context information to locate the top K code snippets most relevant to the requirement. The second retrieval then begins, searching a wider range of context based on the top K code snippets to obtain the most relevant code file paths.

[0234] S3-1-4, Based on all the retrieved content from S3-1-1 to S3-1-4 above, input the information into agent G for natural language processing. Agent G organizes the structured text information into natural language prompts so that agent H can generate code in the future.

[0235] S3-1-5, finally entering the code generation node of agent H, agent H generates code based on the natural language prompts organized by agent G, and then calls the tool to write the generated code to a file.

[0236] S3-2, when the requirement is determined to be 2), proceed to the knowledge preparation node of agent E. This node is a sequential node, which will execute all its child nodes sequentially and summarize the execution results of all child nodes. Then, proceed to the child node agent C to extract parameters.

[0237] Step S3-2-1 is exactly the same as S3-1-1, where agent C is responsible for extracting key information from the user's input, filling it in according to the same JSON template, and validating the parameters.

[0238] Step S3-2-2 is exactly the same as S3-1-2, that is, after completing the extraction of key information, start searching the knowledge base containing the RAG vector knowledge base and the server BMC hardware knowledge graph.

[0239] S3-2-3 Since there is no relevant code for this task, the original code needs to be generated based on the manual. Therefore, the directory of the chip manual file is extracted first based on the JSON fields obtained from the key information.

[0240] In step S3-2-4, the extracted directory from the previous step, the user-inputted prompts, the key information extracted by agent C, and the relevant information retrieved from the knowledge base in step S3-2-2 are input into agent F. Agent F determines the manual chapter names and page numbers that may contain relevant information in the directory, as well as the key content that needs attention (such as the register addresses and communication protocol content that need to be read).

[0241] S3-2-5, Extract the corresponding chapter content based on the chapter name and page number determined by agent F.

[0242] S3-2-6, input the extracted chapter content into agent F, and agent F will summarize and condense the required content.

[0243] S3-2-7: Input the contents of S3-2-1 to S3-2-6 into agent G for knowledge summarization. Agent G then organizes the structured text information into natural language prompts.

[0244] S3-2-8, finally entering the code generation node of agent H, agent H generates code based on the natural language prompts organized by agent G, and then calls the tool to write the generated code to a file.

[0245] It should be noted that embedded code generation faces four core challenges: the ambiguity of natural language makes it difficult for string-type prompts to accurately and comprehensively express requirements; chip manuals are complex and contain a huge amount of text, far exceeding the context processing capabilities of current large models; circuit schematics have complex data structures that cannot be directly input into large models; in reference code application scenarios, adapting old code requires precise retrieval of massive code libraries, while developing new devices relies on chip manual information processing.

[0246] This embodiment proposes an innovative method that uses a behavior tree model to break down the code generation task into simple sub-tasks such as structured querying and text content summarization. By formally modeling multimodal data into structured text data and combining it with a behavior tree model that clearly defines input, output, and logical switching, this embodiment embeds the large model into a "code generation pipeline," effectively reducing task complexity and significantly improving the success rate of code generation.

[0247] Through the embodiments of this application, the innovative applications of behavior tree models are as follows: Behavior trees are extended from traditional control logic (such as game AI and robot collaboration) to code generation process management, reducing the processing complexity of large models through structured task decomposition. Formal modeling of multimodal data: Unstructured data such as chip manuals and schematics are transformed into structured text, especially by combining knowledge graphs to achieve accurate retrieval of hardware link information. Pipeline-style generation mechanism: Automated and robust code generation is achieved through logical switching of behavior tree nodes (such as retry nodes and selection nodes), significantly improving the success rate.

[0248] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0249] Based on this understanding, the technical solution of this application, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.

[0250] This embodiment also provides a target embedded code generation apparatus for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0251] Figure 9 This is a structural block diagram of a target embedded code generation apparatus according to an embodiment of this application; as shown... Figure 9 As shown, it includes:

[0252] The receiving unit 902 is configured to receive a target code generation request, wherein the target code generation request includes a request description text, which is used to indicate the target embedded code applied to the target hardware;

[0253] The determining unit 904 is used to determine, based on the parsing result of the request description text, at least one entity object associated with the target hardware and the interaction relationship between at least one entity object from the embedded knowledge graph. The embedded knowledge graph includes entity nodes for indicating multiple entity objects respectively, and the connection relationship between entity nodes is used to indicate the connection relationship between the corresponding entity objects.

[0254] The combination unit 906 is used to combine the entity description information of at least one entity object and the relationship description information of the interaction relationship to obtain the target prompt word;

[0255] Input unit 908 is used to input target prompt words into the code generation model to obtain target embedded code that matches the target code generation request.

[0256] As an optional solution, the determining unit 904 includes: a first determining module, configured to determine at least one functional module of each of the at least one reference hardware as at least one reference entity object before determining at least one entity object associated with the target hardware and the interaction relationship between the at least one entity object from the embedded knowledge graph based on the parsing result of the request description text; a second determining module, configured to determine the connection relationship between the at least one reference entity object from the reference entity description information of each of the at least one reference entity object, wherein the reference entity description information is used to indicate the module type and module function of the functional module; and a building module, configured to build the embedded knowledge graph based on the at least one reference entity object and the connection relationship between the at least one reference entity object.

[0257] As an optional approach, the construction module includes: a first determining submodule, used to determine the basic control connection relationship between at least one reference entity object from the reference entity description information of each of the at least one reference entity object, wherein the connection relationship includes the basic control connection relationship; a second determining submodule, used to determine the data transmission connection relationship between at least one reference entity object from the reference entity description information of each of the at least one reference entity object, wherein the connection relationship includes the data transmission connection relationship; a third determining submodule, used to determine the system extension connection relationship between at least one reference entity object from the reference entity description information of each of the at least one reference entity object, wherein the connection relationship includes the system extension connection relationship; and a fourth determining submodule, used to determine the debug interface connection relationship between at least one reference entity object from the reference entity description information of each of the at least one reference entity object, wherein the connection relationship includes the debug interface connection relationship.

[0258] As an optional solution, the combining unit 906 includes: a first acquisition module, used to acquire a first code fragment matching the parsing result from a code database, wherein the code database contains code fragments that match at least one entity object respectively; a third determination module, used to determine from the code database at least one first reference code fragment preceding the first code fragment and at least one second reference code fragment following the first code fragment, as well as the first code fragment; a fourth determination module, used to determine a target storage path based on the code storage paths corresponding to at least one first reference code fragment, at least one second reference code fragment, and the first code fragment respectively; and a first combining module, used to combine the entity description information of at least one entity object, the relationship description information of the interaction relationship, and multiple target storage paths to obtain a target prompt word.

[0259] As an optional solution, the first combination module includes: a combination submodule, used to combine entity description information, relationship description information of interaction relationships, and multiple code storage paths based on at least one entity object to obtain combined information; an input submodule, used to input the combined information into a natural language processing model, wherein the natural language processing model is used to perform natural language processing; and a fifth determination submodule, used to determine the output of the natural language processing model as the target prompt word.

[0260] As an optional approach, the fourth determining module includes: a sixth determining submodule, used to determine at least one second code segment that satisfies the filtering criteria from the first code segment, at least one first reference code segment, and at least one second reference code segment; a seventh determining submodule, used to determine a third reference code segment and a fourth code segment corresponding to each of the at least one second code segment, wherein the third reference code segment is a code segment located before the second code segment, and the fourth reference code segment is a code segment located after the second code segment; and an eighth determining submodule, used to determine the target storage path based on the code paths of the third reference code segment, the fourth code segment, and the respective code paths of the second code segment.

[0261] As an optional solution, the combination unit 906 includes: a second acquisition module, used to acquire a hardware knowledge set based on the parsing result when no reference embedded code related to the target embedded code is found, wherein the hardware knowledge set is used to describe at least one functional module included in the parsing result; a fifth determination module, used to determine reference hardware information associated with the parsing result from the hardware knowledge set; and a second combination module, used to combine the entity description information of at least one entity object, the relationship description information of the interaction relationship, and the reference hardware information to obtain the target prompt word.

[0262] As an optional solution, the fifth determining module includes: a ninth determining submodule, used to determine chapter identifier information and page number identifier information from the hardware knowledge set based on the directory information, parsing results, and entity description information of at least one entity object, as well as relationship description information of interaction relationships; and a tenth determining submodule, used to determine reference hardware information from the hardware knowledge set based on the chapter identifier information and page number identifier information.

[0263] As an optional solution, the determining unit 904 includes: a sixth determining module, used to determine guide information from the hardware vector knowledge base based on the parsing results, wherein the guide information is used to represent the specifications corresponding to the target hardware, and the hardware vector knowledge base includes guide information that is related to the target hardware.

[0264] As an optional solution, the receiving unit 902 includes: a determination module, used to perform a requirement determination operation on the request description text to obtain a requirement determination result; and an input module, used to input the request description text into the code generation model when the requirement determination result indicates that the request description text meets the target requirement conditions, to obtain the target code that matches the request target code generation request, wherein the target requirement conditions are used to indicate that the request description text is used to generate non-embedded code.

[0265] As an optional solution, the determining unit 904 includes: a display module, used to display a verification failure message if the validity verification result of the parsing result does not meet the verification conditions before determining at least one entity object associated with the target hardware and the interaction relationship between at least one entity object from the embedded knowledge graph based on the parsing result of the request description text; and a rewriting module, used to rewrite the request description text based on the validity verification result if the rewriting number is less than or equal to the target number, to obtain the rewritten request description text, wherein the rewriting number is used to indicate the number of times the request description text has been rewritten.

[0266] As an optional solution, the determining unit 904 includes: an execution module, used to perform parameter validity verification on the parsing result of the rewritten request description text to obtain a second validity verification result;

[0267] The display module is used to display an exception report when the second legality verification result does not meet the verification condition and the number of rewrites is greater than the target number. The exception report is used to indicate that the target embedded code generation failed and that the parameters in the rewritten request description text failed the parameter legality verification.

[0268] The sending module is used to send the rewritten request description text to the description text review node, wherein the text review node is used to review the rewritten request description text.

[0269] For a description of the features in the embodiment corresponding to the target embedded code generation device, please refer to the relevant description in the embodiment corresponding to the target embedded code generation method, which will not be repeated here.

[0270] Embodiments of this application also provide an electronic device. Figure 10 This is a schematic diagram of an electronic device according to an embodiment of this application, such as... Figure 10 As shown, the electronic device includes a memory and a processor, the memory storing a computer program, and the processor being configured to run the computer program to perform the steps in any of the above-described embodiments of the method for generating embedded code for the target.

[0271] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0272] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0273] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in the above-described embodiments of the method for generating embedded code of any of the objectives.

[0274] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0275] Embodiments of this application also provide a computer program product, including a computer program that, when executed by a processor, implements the steps of the methods in various embodiments of this application; the computer program product further includes a non-volatile computer-readable storage medium storing the computer program, which, when executed by a processor, implements the steps of the target embedded code generation method in various embodiments of this application.

[0276] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0277] The above provides a detailed description of a method for generating embedded target code provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for generating target embedded code, characterized in that, include: Receive a target code generation request, wherein the target code generation request includes a request description text, the request description text being used to indicate the target embedded code to be applied to the target hardware; Based on the parsing result of the request description text, at least one entity object associated with the target hardware and the interaction relationship between at least one of the entity objects are determined from the embedded knowledge graph. The embedded knowledge graph includes entity nodes for indicating multiple entity objects respectively, and the connection relationship between the entity nodes is used to indicate the connection relationship between the corresponding entity objects. The target prompt word is obtained by combining the entity description information of at least one of the entity objects and the relationship description information of the interaction relationship. The target prompt word is input into the code generation model to obtain the target embedded code that matches the target code generation request. The entity description information includes at least one of the attributes, functions, and characteristics of the entity object, and the relationship description information includes at least one of the hardware connection relationship and the communication link relationship. The target prompt word is obtained by combining the entity description information of at least one of the entity objects and the relationship description information of the interaction relationship, including: Obtain a first code fragment that matches the parsing result from a code database, wherein the code database contains code fragments that match at least one of the entity objects respectively; From the code database, at least one first reference code segment preceding the first code segment and at least one second reference code segment following the first code segment, as well as the first code segment, are determined; The target storage path is determined based on at least one first reference code segment, at least one second reference code segment, and the code storage path corresponding to each of the first code segments; The target prompt word is obtained by combining the entity description information of at least one of the entity objects, the relationship description information of the interaction relationship, and multiple target storage paths.

2. The method according to claim 1, characterized in that, Before determining, based on the parsing result of the request description text, at least one entity object associated with the target hardware and the interaction relationships between at least one of the entity objects from the embedded knowledge graph, the method further includes: Each of the at least one functional module of at least one reference hardware is defined as at least one reference entity object; The connection relationship between at least one of the reference entity objects is determined from the reference entity description information of each of the at least one reference entity object, wherein the reference entity description information is used to indicate the module type and module function of the functional module; The embedded knowledge graph is constructed based on at least one of the reference entity objects and the connection relationships between at least one of the reference entity objects.

3. The method according to claim 2, characterized in that, Determining the connection relationship between at least one of the reference entity objects from the reference entity description information of each of the at least one of the reference entity objects includes at least one of the following: A basic control connection relationship between at least one of the reference entity objects is determined from the reference entity description information of each of the at least one of the reference entity objects, wherein the connection relationship includes the basic control connection relationship; A data transmission connection relationship between at least one of the reference entity objects is determined from the reference entity description information of each of the at least one reference entity object, wherein the connection relationship includes the data transmission connection relationship; A system extended connection relationship between at least one of the reference entity objects is determined from the reference entity description information of each of the at least one of the reference entity objects, wherein the connection relationship includes the system extended connection relationship; A debugging interface connection relationship between at least one of the reference entity objects is determined from the reference entity description information of each of the at least one reference entity object, wherein the connection relationship includes the debugging interface connection relationship.

4. The method according to claim 1, characterized in that, The step of obtaining target prompt words based on the entity description information of at least one of the entity objects, the relationship description information of the interaction relationship, and the combination of multiple target storage paths includes: The combined information is obtained by combining the entity description information of at least one of the entity objects, the relationship description information of the interaction relationship, and the multiple code storage paths. The combined information is input into a natural language processing model, wherein the natural language processing model is used to perform natural language processing; The output of the natural language processing model is determined as the target prompt word.

5. The method according to claim 1, characterized in that, The step of determining the target storage path based on at least one first reference code segment, at least one second reference code segment, and the code storage path corresponding to each of the first code segments includes: From the first code segment, at least one first reference code segment, and at least one second reference code segment, determine at least one second code segment that satisfies the filtering criteria; Identify at least one third reference code segment and a fourth reference code segment corresponding to each of the second code segments, wherein the third reference code segment is a code segment located before the second code segment, and the fourth reference code segment is a code segment located after the second code segment; The target storage path is determined based on the code paths of the third and fourth reference code fragments, respectively.

6. The method according to claim 1, characterized in that, In the process of obtaining the target prompt word by combining the entity description information of at least one of the entity objects and the relationship description information of the interaction relationship, the method further includes: If no reference embedded code related to the target embedded code is found, a hardware knowledge set is obtained based on the parsing result, wherein the hardware knowledge set is used to describe at least one functional module included in the parsing result; Determine reference hardware information associated with the parsing result from the hardware knowledge set; The target prompt word is obtained by combining the entity description information of at least one of the entity objects, the relationship description information of the interaction relationship, and the reference hardware information.

7. The method according to claim 6, characterized in that, The step of determining the reference hardware information associated with the parsing result from the hardware knowledge set includes: Based on the directory information of the hardware knowledge set, the parsing results, the entity description information of each of the at least one entity object, and the relationship description information of the interaction relationship, chapter identification information and page number identification information are determined from the hardware knowledge set. The reference hardware information is determined from the hardware knowledge set based on the chapter identifier information and page number identifier information.

8. The method according to any one of claims 1 to 7, characterized in that, In the process of determining at least one entity object associated with the target hardware from the embedded knowledge graph based on the parsing result of the request description text, and the interaction relationship between at least one of the entity objects, the method further includes: Based on the parsing results, guide information is determined from the hardware vector knowledge base, wherein the guide information is used to represent the specifications corresponding to the target hardware, and the hardware vector knowledge base includes guide information that is associated with the target hardware.

9. The method according to any one of claims 1 to 7, characterized in that, After receiving the target code generation request, it also includes: Perform a requirement determination operation on the request description text to obtain the requirement determination result; If the requirement determination result indicates that the request description text meets the target requirement conditions, the request description text is input into the code generation model to obtain the target code that matches the target code generation request, wherein the target requirement conditions are used to indicate that the request description text is used to generate non-embedded code.

10. The method according to any one of claims 1 to 7, characterized in that, Before determining, based on the parsing results of the request description text, at least one entity object associated with the target hardware from the embedded knowledge graph, and the interaction relationships between at least one of the entity objects, the method further includes: If the first validity check result of the parsed result does not meet the check conditions, a check failure message will be displayed; If the number of rewrites is less than or equal to the target number, the request description text is rewritten based on the first legality verification result to obtain the rewritten request description text, wherein the number of rewrites is used to indicate the number of times the request description text has been rewritten.

11. The method according to claim 10, characterized in that, After rewriting the request description text based on the first validity check result to obtain the rewritten request description text, the method further includes: Perform parameter validity verification on the parsing result of the rewritten request description text to obtain a second validity verification result; If the second validity check result does not meet the check condition and the number of rewrites is greater than the target number, an exception report is displayed. The exception report is used to indicate that the target embedded code generation failed and that the parameters in the rewritten request description text failed the parameter validity check. The rewritten request description text is sent to the description text review node, wherein the text review node is used to review the rewritten request description text.

12. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the method for generating the target embedded code as described in any one of claims 1 to 11 when executing the computer program.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, it implements the steps of the method for generating the target embedded code as described in any one of claims 1 to 11.

14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method for generating the target embedded code as described in any one of claims 1 to 11.

Images