Embedded development method, system and equipment based on artificial intelligence and storage medium
By converting components into standardized digital twin models and building a hardware middle layer, combined with a graphical interface and artificial intelligence, automation and cross-platform adaptation of embedded system development are achieved, solving the problems of manual dependence and inefficiency in traditional development, and improving development efficiency and collaborative design capabilities.
Patent Information
- Application Number
- CN202511252603.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-09-03
- Publication Date
- 2025-10-14
- Estimated Expiration
- 2045-09-03
AI Technical Summary
Traditional embedded system development relies on the professional skills of developers, resulting in long development cycles, high labor costs, difficulty in cross-platform reuse, low efficiency in software and hardware collaborative design, and difficulty in meeting market demands for rapid response.
By converting components into standardized digital twin models, building a standardized hardware module library and middle layer, using a graphical interface for configuration, generating target components and hardware information, and using artificial intelligence to automate code generation and compatibility testing.
It lowers the development threshold, improves cross-platform adaptation efficiency, enhances software and hardware collaborative design capabilities, and solves the problems of manual dependence and cross-platform adaptation difficulties in traditional development processes.
Smart Images

Figure CN120780288A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of embedded system development technology, and in particular to an artificial intelligence-based embedded development method, system, device, and storage medium. Background Art
[0002] Traditional embedded system development faces significant technical bottlenecks, primarily manifested in three key areas: First, the development process relies heavily on the developer's specialized skills, requiring deep hardware knowledge, low-level programming capabilities, and familiarity with specific chip architectures. This high barrier to entry results in long development cycles and high labor costs. Second, due to architectural differences between different hardware platforms, development results are difficult to reuse across platforms. When faced with diverse hardware environments (such as various sensors and communication protocols), adaptation code must be repeatedly developed, resulting in a waste of resources. Furthermore, the existing development model's inefficient hardware and software collaborative design and the lack of standardized specifications for functional modules make it difficult to ensure system stability. This is particularly true in application scenarios such as industrial automation and smart homes, which require rapid market response. These issues severely restrict the speed of product iteration.
[0003] With the rapid development of IoT technology, demand for edge computing devices has exploded, placing higher demands on embedded system development. The industry urgently needs a solution that digitizes hardware capabilities, standardizes development processes, and dynamically optimizes resource allocation through artificial intelligence. This solution can overcome the technical barriers of traditional development models and meet the urgent needs of intelligent manufacturing for shortened product development cycles and reduced production costs. Summary of the Invention
[0004] The purpose of the embodiments of the present application is to propose an embedded development method, system, device and storage medium based on artificial intelligence to lower the development threshold and improve cross-platform adaptation efficiency.
[0005] In order to solve the above technical problems, the present invention provides an artificial intelligence-based embedded development method, including: Convert components into standardized digital twin models; Building a standardized hardware module library based on the standardized digital twin model and building a hardware middle layer; Creating a component template through a graphical interface and obtaining configuration information of the user-configured component based on the standardized digital twin model; Performing configuration processing on the component template based on the configuration information to generate target components, and saving the target components into a component library; Creating a hardware template through the graphical interface, determining a main control chip from the component library, and obtaining hardware configuration parameters through the hardware middle layer; According to the hardware configuration parameters and the master chip, the hardware template is configured, target hardware information is generated, and writable firmware information and hardware physical list are generated based on the target hardware information.
[0006] To solve the above technical problems, the embodiment of the application provides an embedded development system based on artificial intelligence, which comprises: A digital twin model construction module is configured to convert components into standardized digital twin models. A hardware module library construction module is configured to construct a standardized hardware module library based on the standardized digital twin models and to construct a hardware intermediate layer. A component template creation module is configured to create a component template through a graphical interface and to obtain configuration information of a user-configured component based on the standardized digital twin models. A target component generation module is configured to configure the component template based on the configuration information, to generate a target component, and to save the target component in a component library. A hardware template creation module is configured to create a hardware template through the graphical interface, to determine a master chip from the component library, and to obtain hardware configuration parameters through the hardware intermediate layer. A target hardware information generation module is configured to configure the hardware template according to the hardware configuration parameters and the master chip, to generate target hardware information, and to generate writable firmware information and a hardware physical list based on the target hardware information.
[0007] To solve the above technical problems, the application employs a technical solution, which is to provide an electronic device, comprising one or more processors, and a memory configured to store one or more programs, so that the one or more processors implement the artificial intelligence-based embedded development method described in any of the above.
[0008] To solve the above technical problems, the application employs a technical solution, which is a computer-readable storage medium, and the computer-readable storage medium stores a computer program, and the computer program is executed by a processor to implement the artificial intelligence-based embedded development method described in any of the above.
[0009] The embodiment of the application provides an embedded development method, system, device and storage medium based on artificial intelligence. The method comprises the following steps: converting a component into a standardized digital twin model; constructing a standardized hardware module library based on the standardized digital twin model, and constructing a hardware intermediate layer; creating a component template through a graphical interface, and obtaining configuration information of a user-configured component based on the standardized digital twin model; performing configuration processing on the component template based on the configuration information, generating a target component, and saving the target component into a component library; creating a hardware template through the graphical interface, determining a master control chip from the component library, and obtaining hardware configuration parameters through the hardware intermediate layer; performing configuration on the hardware template according to the hardware configuration parameters and the master control chip, generating target hardware information, and generating burnable firmware information and a hardware physical list based on the target hardware information. The embodiment of the application constructs a hardware module library and an intermediate layer through a standardized digital twin model, realizes hardware configuration automation in combination with a graphical interface, solves the problems of dependence on manual experience and difficulty in cross-platform adaptation in a traditional development process, and has the advantages of reducing development threshold, improving cross-platform adaptation efficiency, and enhancing the ability of soft and hardware collaborative design. BRIEF DESCRIPTION OF DRAWINGS
[0010] In order to more clearly illustrate the scheme in the present application, the drawings needed in the description of the embodiments of the present application will be briefly introduced. Obviously, the drawings in the following description are some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.
[0011] Figure 1 is the implementation flowchart of the embedded development method based on artificial intelligence provided by the embodiment of the present application; Figure 2 is the implementation flowchart of the first sub-process in the embedded development method based on artificial intelligence provided by the embodiment of the present application; Figure 3 is the implementation flowchart of the second sub-process in the embedded development method based on artificial intelligence provided by the embodiment of the present application; Figure 4 is the implementation flowchart of the third sub-process in the embedded development method based on artificial intelligence provided by the embodiment of the present application; Figure 5 is the implementation flowchart of the fourth sub-process in the embedded development method based on artificial intelligence provided by the embodiment of the present application; Figure 6 is the implementation flowchart of the fifth sub-process in the embedded development method based on artificial intelligence provided by the embodiment of the present application; Figure 7is a flowchart of implementation of a sixth sub-process in the artificial intelligence-based embedded development method provided by the embodiments of the present application; Figure 8 is a schematic diagram of an artificial intelligence-based embedded development system provided by the embodiments of the present application; Figure 9 is a schematic diagram of an electronic device provided by the embodiments of the present application. DETAILED DESCRIPTION
[0012] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs; the terminology used in the description herein is for describing particular embodiments only and is not intended to be limiting of the application; the description and the drawings are to be regarded as illustrative in nature and are not intended to limit the application; the terminology used in the description and the claims of the present application and the above description of the drawings includes the terms specifically mentioned above as well as their derivatives.
[0013] Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the application. The appearances of the phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are they necessarily mutually exclusive of one another. It is expressly understood that the embodiments described herein are merely examples and are not a complete list of alternatives.
[0014] For those skilled in the art to better understand the scheme of the present application, the technical solutions in the embodiments of the present application will be described clearly and completely in conjunction with the drawings.
[0015] The present application will be described in detail below in conjunction with the drawings and embodiments.
[0016] It should be noted that the artificial intelligence-based embedded development method provided by the embodiments of the present application is generally executed by an electronic device, and accordingly, the artificial intelligence-based embedded development system is generally configured in the electronic device.
[0017] In the prior art, embedded system development has long relied on manual writing of underlying driver code and hardware configuration, and developers need to be proficient in multiple chip architectures and hardware protocols, resulting in long development cycles and high labor costs. Under the traditional development mode, there is a lack of unified standards for the description of hardware component parameters, and compatibility verification between devices of different manufacturers consumes a lot of time, and functional modules are difficult to reuse across projects. Especially in the development scenario of smart home devices, in the face of the combination and configuration of dozens of sensors and communication modules, engineers need to repeatedly debug hardware interface protocols and manually generate device driver code, and there is a problem of low efficiency of software and hardware collaborative design.
[0018] To solve the above problems, it is found that the lack of standardization of hardware parameters is a key factor leading to low development efficiency, and then a physical component is converted into an interactive digital model to form a unified hardware abstraction layer. To solve the cross-platform adaptation problem, a middle layer is built to decouple hardware capabilities and software calls. To solve the technical bottleneck of graphical configuration and automatic generation, a parameter mapping mechanism based on digital twin model is designed, so that hardware function selection can be converted into visual operation. Therefore, the present application proposes an embedded development method based on artificial intelligence, including: converting components into standardized digital twin models; building a standardized hardware module library based on the standardized digital twin models, and building a hardware middle layer; creating a component template through a graphical interface, and obtaining configuration information of the user-configured components based on the standardized digital twin models; configuring the component template based on the configuration information, generating a target component, and saving it to a component library; creating a hardware template through a graphical interface, determining a master chip from the component library, and obtaining hardware configuration parameters through the hardware middle layer; configuring the hardware template according to the hardware configuration parameters and the master chip, generating target hardware information, and generating burnable firmware information and a hardware physical list based on the target hardware information. Specifically, after physical components are digitally modeled, a standard parameter library is formed, and when a developer selects a required functional module on a graphical interface, the system automatically retrieves the parameter constraint range of the corresponding digital twin model. The hardware middle layer real-time analyzes the communication protocol differences between the master chip and the peripheral module, and automatically completes the interface protocol conversion during the configuration of the hardware template. When the user completes the hardware topology design, the system automatically generates the burnable firmware according to the drive logic in the digital twin model, and outputs the bill of materials required for manufacturing based on the physical property model. The compatibility detection module real-time checks the pin level matching degree and bus load capacity during the configuration process to ensure the feasibility of the hardware scheme.
[0019] Please refer to Figure 1 , Figure 1 a specific embodiment of the embedded development method based on artificial intelligence is shown.
[0020] It should be noted that the method of the present application does not exclude Figure 1The flow sequence shown is limited, and the method comprises the following steps: S1: converting components into standardized digital twin models.
[0021] Specifically, the present application provides a low-code visual development platform, which abstracts hardware operations into graphical modules, and users can complete function configuration without directly writing underlying code. An AI-driven automatic code generation engine is introduced to automatically generate adaptive code according to hardware models and requirements, reducing the workload of manual transplantation. In the platform, a hardware abstraction layer (HAL) and a standardized component library are designed, encapsulating the general interfaces of common sensors and communication protocols to realize “one development, multiple platform deployment”. Through AI model analysis of historical project data, the optimal component combination is intelligently recommended, and the module reuse rate is improved to more than 70%. The present application constructs an embedded special low-code framework, supports NVIDIARKRTOSbare machine and other embedded running environments, and provides graphical operations of hardware configuration guides.
[0022] In the embodiments of the present application, the attributes, functions, etc. of each component are converted into standardized digital twin models, which are convenient for calling and combining during design. The standardized digital twin model includes physical attributes (pin definition / electrical parameters / protocol standard), functional attributes (thing model / driving interface / energy consumption model), and production data (supplier / quality inspection standard / historical failure rate).
[0023] The standardized digital twin model refers to a structured data set formed by digitizing the physical attributes, pin functions and driving logic of components, which can be specifically implemented by parsing component data sheets to extract basic parameters and generating function mapping files in combination with chip pin definition diagrams. The model provides a unified benchmark for the standardized description of hardware modules.
[0024] Please refer to Figure 2 , Figure 2 A specific embodiment of step S1 is shown, which is described in detail as follows: S11: obtaining component data sheets, chip pin definition diagrams and business requirement documents; S12: parsing the component data sheets to extract the basic attributes of the components, generating a structured parameter table, and performing physical attribute digitization modeling based on the structured parameter table to generate a physical attribute model file; S13: performing pin function mapping based on the chip pin definition diagram to generate a pin function mapping file, and constructing a thing model description file based on the business requirement document; S14: generating a driving file according to the data sheet register description and historical driving library; S15: encapsulating a digital twin model based on the physical property model file, the pin function mapping file and the driver file, generating the standardized digital twin model, and storing the standardized digital twin model to the component library.
[0025] Specifically, the component data manual is converted into a structured parameter table through automatic analysis, the physical property model file is constructed by using the key fields in the parameter table, and the error risk of manual interpretation is eliminated. The pin function mapping file is generated by image recognition and function mapping processing of the chip pin definition diagram, and the semantic alignment of hardware interface and business function is realized by combining the physical model attributes extracted from the business requirement document. The driving code fragments stored in the historical driving library are matched with the register description in the data manual, and the driving file adapted to the current component is automatically generated to avoid repeated development. Finally, the physical property model, the pin function mapping file and the driving file are integrated and encapsulated into a standardized digital twin model, which is stored in the component library for subsequent development and calling, so as to ensure the model consistency of the same component in different projects.
[0026] Among them, the component data manual refers to a technical document containing electrical characteristics and working parameters of the component, and the PDF parsing tool can be used to extract text and table data for constructing the basic attributes of the standardized model. The chip pin definition diagram refers to a schematic diagram describing the physical pin layout and function allocation of the chip, and the image recognition algorithm can be used to extract pin numbers and function labels to realize semantic mapping of pin function and business requirements. The business requirement document refers to an instruction file describing the function scene of the device, and the natural language processing technology can be used to extract key physical model attributes to generate a device function description file. The structured parameter table refers to the conversion of unstructured technical parameters into machine-readable table data, and the regular expression matching technology can be used to extract key fields to provide input for physical property modeling. The physical property model file refers to a digital model describing the size, power consumption and interface type of the component, and the parameterized modeling tool can be used to generate a standardized three-dimensional model to realize unified description of hardware properties. The driving file refers to software code for controlling hardware operation, and similar code fragments in the historical driving library can be matched to automatically generate the driving file, reducing the amount of manual coding.
[0027] S2: constructing a standardized hardware module library based on the standardized digital twin model, and constructing a hardware intermediate layer.
[0028] In an embodiment of the present application, a standardized hardware module library is established, which can support: interaction between modules through a unified communication protocol; automatic generation of hardware topology and dependency relationships by dragging and dropping modules through a graphical interface. A version compatibility engine is introduced to ensure the stability of mixed use of new and old modules. Establishing a standardized hardware module library improves reuse rate, development efficiency and fault location efficiency. The hardware middleware layer can provide a unified device API and a dynamic adaptation engine. The unified device API can shield hardware differences (such as sensors from different manufacturers are unified as "data acquisition services"). The dynamic adaptation engine can automatically load drivers and configuration parameters according to the actual hardware.
[0029] The hardware midlayer is an abstract interface layer that encapsulates differences in underlying hardware. It uses a unified device API to encapsulate register operation instructions for different chips, and a dynamic adaptation engine automatically matches communication protocols. This midlayer eliminates the impact of hardware differences on upper-layer applications.
[0030] See also Figure 3 , Figure 3 A specific implementation of step S2 is shown, which is described in detail as follows: S21: Perform functional dimension decomposition and module label generation based on historical project hardware solutions and industry equipment topology diagrams to create a module classification tree structure; S22: performing pin interface standardization and communication protocol unification on the modules in the module classification tree structure to obtain a target module classification tree structure; S23: Encapsulating the modules in the target module classification tree structure to generate the standardized hardware module library; S24: Construct the hardware intermediate layer based on the hardware parameters of the standardized digital twin model.
[0031] Specifically, by analyzing the circuit topology and functional configuration in the hardware solutions of historical projects, the functional dimension characteristics of modules such as sensors and communication units are extracted to form a tree index structure classified by functions such as power management and data acquisition. For example, for the temperature sensor module in industrial control equipment, by analyzing its pin definition and protocol type in different projects, a level conversion chip is used to unify the pin voltage standard, and the communication protocol is standardized through Modbus to MQTT protocol conversion. The standardized modules are encapsulated as callable library units containing driver files and interface definitions and stored in the module library. The hardware middle layer generates a standardized API interface for upper-level applications to call by parsing the register address and clock frequency parameters contained in the digital twin model. For example, the sampling rate parameters of different ADC modules are mapped to a unified numerical acquisition interface.
[0032] The function dimension decomposition refers to decomposing historical project schemes according to the hardware function type, and can be implemented by extracting function keywords by using a semantic analysis algorithm, and is used to eliminate the problem of chaotic function division. The module label generation refers to adding a function attribute label to each module, and can be implemented by extracting common features of an industry device topology by using a natural language processing technology, and is used to establish a unified function classification system. The pin interface standardization refers to unifying the physical connection specifications of modules, and can be implemented by using a protocol converter to adapt the electrical parameters of different pin interfaces, and is used to solve the problem of physical connection incompatibility between hardware modules. The communication protocol unification refers to converting different protocols into a standard format recognizable by an intermediate layer, and can be implemented by using a protocol conversion middleware, and is used to eliminate the interaction obstacles caused by communication protocol differences. The module classification tree structure refers to a module index system organized according to function levels, and can be implemented by storing module labels and function dimension information by using a tree data structure, and is used to realize fast retrieval and calling of modules. The target module classification tree structure refers to the module organization structure after the interface and protocol standardization, and can be implemented by using version control technology to retain the module relationship of different standard versions, and is used to support the compatible adaptation of multi-version hardware platforms. The standardized hardware module library refers to a set of hardware components encapsulating unified interfaces, and can be implemented by storing module drivers and configuration parameters in the form of binary library files, and is used to improve the module reuse efficiency. The hardware intermediate layer refers to an abstract interface layer connecting hardware modules and an application layer, and can be implemented by using dynamic link library technology to realize semantic mapping of hardware parameters, and is used to shield the differences between underlying hardware.
[0033] Please refer to Figure 4 , Figure 4 An embodiment of step S24 is shown as follows: S241: functionally semantic mapping of hardware parameters of the standardized digital twin model is performed to generate a hardware capability list; S242: a unified device API and a dynamic adaptation engine are constructed according to the hardware capability list to construct the hardware intermediate layer.
[0034] Specifically, in the process of constructing the hardware intermediate layer, the function attributes of hardware parameters in the digital twin model are first extracted by semantic mapping to generate a hardware capability list containing hardware function description, interface specification, performance index and other elements. The unified device API constructed based on the list establishes a standardized interface calling specification, for example, the differentiated data formats of temperature sensors and humidity sensors are uniformly converted into JSON format output. The dynamic adaptation engine automatically detects hardware configuration and loads the corresponding driver module by analyzing the function description and interface parameters in the hardware capability list when the device starts, for example, the optimal interrupt processing strategy is automatically selected for different types of master control chips. When the hardware configuration changes, the adaptation engine re-establishes the interface mapping relationship through the reflection mechanism without manually modifying the application layer code.
[0035] Functional semantic mapping refers to converting discrete hardware parameters in the digital twin model into functional descriptions with business semantics. This can be achieved using semantic label matching algorithms and knowledge graph technology. For example, mapping GPIO pin voltage parameters to the semantic label "switch control interface" can be used. This process converts underlying hardware characteristics into functional units recognizable by upper-layer applications, bridging the semantic gap between hardware parameters and application requirements. A unified device API is an application programming interface that provides standardized encapsulation of heterogeneous hardware interfaces. Specifically, middleware technology can be used to implement protocol conversion and interface abstraction, for example, unifying different sensor communication protocols into a standardized data acquisition interface. This interface shields underlying hardware differences and provides a consistent calling method for upper-layer services. A dynamic adaptation engine is a runtime component that automatically adjusts resource allocation based on actual hardware configuration. This can be implemented using a rules engine and reflection mechanisms, for example, dynamically loading matching drivers based on a hardware capability list. This component automatically matches hardware and software interfaces by analyzing hardware capabilities in real time.
[0036] S3: Create a component template through a graphical interface, and obtain configuration information of the user-configured components based on the standardized digital twin model.
[0037] Specifically, users can design a single component on a graphical interface, which includes basic component information, pin quantity, pin serial number, pin function, object model attributes (events, properties, telemetry, instructions), and driver upload of the adapted system.
[0038] Among them, creating component templates through a graphical interface means generating hardware configuration prototypes by visually dragging components. Specifically, a node-based editor is used to achieve visual configuration of pin connection relationships. This method lowers the technical threshold for hardware design.
[0039] See also Figure 5 , Figure 5 A specific implementation of step S3 is shown, which is described in detail as follows: S31: receiving a template creation request from a user, and creating the component template on the graphical interface according to the template creation request; S32: Obtain configuration information of the user-configured components according to the standardized digital twin model, wherein the configuration information includes basic component information, pin quantity, pin serial number, pin function, and physical model attributes.
[0040] Specifically, after the user selects the component type through the graphical interface, the system automatically loads the predefined parameters of the component based on the standardized digital twin model, such as the pin function mapping file and the physical model description file. The user fills in basic information such as the component name and model through a visual form, and selects the pin number and function assignment based on the pin layout diagram provided by the system, such as configuring the GPIO pin as input or output mode. During this process, the physical model properties are presented in the form of drop-down menus or checkboxes, such as setting the sensor range or communication protocol type. After the configuration is completed, the system automatically verifies the logical consistency of the pin function and the physical model properties, such as detecting whether the I2C pin is incorrectly assigned to the UART function, thereby generating configuration information that conforms to the actual characteristics of the hardware.
[0041] Among them, creating component templates through a graphical interface refers to the visual design of component templates through drag-and-drop operations or parameterized forms. Specifically, it can be implemented using HTML5 canvas technology or a graphical configuration engine, which is used to convert hardware configuration operations from code writing to graphical interaction, reducing the complexity of user operations. Among them, the number of pins and the pin sequence number refer to the standard pin layout data generated by parsing the chip pin definition diagram. Specifically, it can be implemented using a pin mapping table or a pin coordinate system to automatically map the relationship between physical pins and logical functions to prevent hardware connection errors. Among them, the physical model attributes refer to the device function description data defined based on the business requirements document. Specifically, it can be implemented using attribute-value pairs or state-event models to abstract hardware functions into standardized interfaces that can be called by software, supporting the subsequent automatic generation of firmware. Physical model attributes include events, attributes, telemetry, instructions and other attributes.
[0042] S4: performing configuration processing on the component template based on the configuration information, generating target components, and saving the target components into a component library.
[0043] Specifically, the component template is configured with basic information (such as name, signal, and category), pin information (such as number of n, electrical characteristics), and physical model definition. After configuration is complete, driver management, code upload, and component generation are performed to generate the target component. The target component is saved in the component library. The target component can be reviewed. If it fails the review, the component template creation process is repeated to re-design the component. If it passes the review, the target component can be published to the marketplace platform.
[0044] S5: creating a hardware template through the graphical interface, determining a main control chip from the component library, and obtaining hardware configuration parameters through the hardware middle layer.
[0045] Specifically, after the design of components is completed, smart hardware assembly can be carried out, which includes creating a smart hardware template, selecting the required components (main control chip + peripherals), defining the smart hardware information (basic product information, terminal information, component information, device model attribute information), generating a burnable BSP, generating a BOM list of smart hardware, and publishing the smart hardware template to the mall platform.
[0046] Among them, the graphical interface refers to the human-computer interaction interface that realizes the construction of hardware topology structure through a visual operation panel. It can be implemented by using a drag-and-drop component library and a connection editor. By converting the hardware connection relationship into a combination of graphic elements, the complexity of user operations is reduced.
[0047] See also Figure 6 , Figure 6 A specific implementation of step S5 is shown, which is described in detail as follows: S51: receiving a hardware template creation request from a user, and creating the hardware template on the graphical interface according to the hardware template creation request; S52: Determine the main control chip from the component library and receive the target peripheral module determined by the user; S53: Acquire the hardware configuration parameters through the hardware middle layer, wherein the hardware configuration parameters include basic product information, terminal information, component information, and device object model attribute information.
[0048] Specifically, after the user initiates a hardware template creation request through the graphical interface, the system automatically generates a blank hardware topology canvas. When the main control chip is selected from the component library, its pin definition, driver file and communication protocol have been standardized and packaged through the digital twin model, avoiding manual reference to the data manual. The selection process of the peripheral module is displayed through a pre-classified tree structure. The user drags the target module to the canvas according to the functional requirements, and the system automatically calls the hardware middle layer to verify the interface matching between modules. In the process of obtaining hardware configuration parameters, the basic product information defines the device application scenario, the terminal information is associated with the deployment environment parameters, the component information integrates the physical size and electrical characteristics, and the physical model attribute information describes the business function logic. The four types of parameters are converted by the semantics of the hardware middle layer to form a unified format configuration instruction set. This process converts the traditional operation that requires writing register configuration code into visual parameter settings, and at the same time eliminates cross-platform differences through the protocol adaptation capabilities of the middle layer.
[0049] Among them, the main control chip refers to the core processor unit of the embedded system, which can be selected from the component library of the pre-set standardized digital twin model, and plug-and-play can be achieved through the packaged pin definition and driver file. The target peripheral module refers to the auxiliary function unit such as the sensor and communication module selected by the user, which is specifically screened through the pre-classified tags of the standardized hardware module library to ensure that the interface protocol is compatible with the main control chip. The hardware middle layer refers to the protocol conversion layer that connects the physical hardware and the upper-level application. It is specifically implemented using a unified device API and a dynamic adaptation engine, and converts heterogeneous hardware parameters into standardized configuration instructions through semantic mapping. Hardware configuration parameters refer to a set of constraints including device type, deployment environment, physical properties and business functions. They are generated by parsing the structured parameters of the digital twin model to provide complete input data for firmware generation.
[0050] S6: configuring the hardware template according to the hardware configuration parameters and the main control chip to generate target hardware information, and generating burnable firmware information and a hardware physical list based on the target hardware information.
[0051] See also Figure 7 , Figure 7 A specific implementation of step S6 is shown, which is described in detail as follows: S61: Add the peripheral module and the main control chip to the hardware template and perform compatibility testing; S62: If the compatibility check passes, the hardware template is configured based on the hardware configuration parameters to generate the target hardware information; S63: Generate the burnable firmware information and the hardware physical list according to the target hardware information.
[0052] Specifically, the hardware template pre-sets interface definitions and connection rules, receives the topological relationship between the peripheral modules and the main control chip, and then starts the automatic detection process. During the compatibility detection phase, the operating voltage, communication protocol version, and pin assignment logic of each module will be cross-verified. When it is detected that the I2C bus rate exceeds the support range of the main control chip or the SPI chip select signal is not correctly mapped, the system will return an error code and mark the conflicting node. The configuration parameters that pass the test will be injected into the hardware template to generate a complete circuit description file. The compilation tool calls the standardized driver library based on this file to generate a directly deployable firmware program. At the same time, the material management module extracts the specification parameters of all components to form a structured hardware inventory document.
[0053] The compatibility detection refers to matching verification of interface protocols and electrical parameters between the master control chip and the peripheral module, and can be specifically implemented by using a protocol consistency verification tool combined with a hardware parameter comparison algorithm, and is used for preventing signal level mismatch or communication protocol conflict. The hardware template refers to an editable framework of predefined hardware connection relationship, and can be specifically constructed by graphically dragging components to build a topology structure, and is used for carrying hardware configuration parameters to form a complete hardware scheme. The burnable firmware information refers to a compiled binary executable file, and can be specifically generated by using a cross-compilation tool chain combined with a driver adaptation layer, and can be directly written into a target device memory for running. The hardware physical inventory refers to a collection of a bill of materials and interface definition documents, and can be specifically automatically output by using a BOM generator combined with an interface mapping table, and is used for guiding component selection and assembly in a production link.
[0054] In the embodiment of the application, the components are converted into a standardized digital twin model; a standardized hardware module library is constructed based on the standardized digital twin model, and a hardware intermediate layer is constructed; a component template is created through a graphical interface, and configuration information of a user-configured component is obtained based on the standardized digital twin model; the component template is configured based on the configuration information, a target component is generated, and the target component is saved into a component library; a hardware template is created through the graphical interface, a master control chip is determined from the component library, and hardware configuration parameters are obtained through the hardware intermediate layer; the hardware template is configured according to the hardware configuration parameters and the master control chip, target hardware information is generated, and burnable firmware information and a hardware physical inventory are generated based on the target hardware information. The embodiment of the application constructs a hardware module library and an intermediate layer through a standardized digital twin model, realizes hardware configuration automation in combination with a graphical interface, solves the problems of relying on manual experience and difficulty in cross-platform adaptation in a traditional development process, and has the advantages of reducing development threshold, improving cross-platform adaptation efficiency, and enhancing soft and hardware collaborative design capability.
[0055] Please refer to Figure 8 , as an implementation of the method shown in Figure 1 , the application provides an embodiment of an embedded development system based on artificial intelligence. The device embodiment corresponds to the method embodiment shown in Figure 1 , and the device can be specifically applied to various electronic devices.
[0056] As shown in Figure 8 , the embedded development system based on artificial intelligence in the embodiment includes a digital twin model construction module 71, a hardware module library construction module 72, a component template creation module 73, a target component generation module 74, a hardware template creation module 75, and a target hardware information generation module 76, wherein: The digital twin model construction module 71 is configured to convert the component into a standardized digital twin model. The hardware module library construction module 72 is configured to construct a standardized hardware module library based on the standardized digital twin model, and to construct a hardware intermediate layer. The component template creation module 73 is configured to create a component template through a graphical interface, and to obtain configuration information of a user-configured component based on the standardized digital twin model. The target component generation module 74 is configured to configure the component template based on the configuration information, to generate a target component, and to save the target component into a component library. The hardware template creation module 75 is configured to create a hardware template through the graphical interface, to determine a master control chip from the component library, and to obtain hardware configuration parameters through the hardware intermediate layer. The target hardware information generation module 76 is configured to configure the hardware template according to the hardware configuration parameters and the master control chip, to generate target hardware information, and to generate burnable firmware information and a hardware physical list based on the target hardware information.
[0057] Further, the digital twin model construction module 71 includes: A data acquisition unit is configured to acquire component data manuals, chip pin definition diagrams, and business requirement documents. A modeling unit is configured to parse the component data manuals to extract basic attributes of the component, to generate a structured parameter table, and to perform physical attribute digital modeling based on the structured parameter table to generate a physical attribute model file. A mapping unit is configured to perform pin function mapping based on the chip pin definition diagrams to generate a pin function mapping file, and to construct a physical model description file based on the business requirement documents. A driver file generation unit is configured to generate a driver file according to data manual register descriptions and a historical driver library. A standardized digital twin model generation unit is configured to perform digital twin model packaging based on the physical attribute model file, the pin function mapping file, and the driver file to generate the standardized digital twin model, and to store the standardized digital twin model into the component library.
[0058] Further, the hardware module library construction module 72 includes: A module classification tree structure generation unit is configured to perform function dimension decomposition and module label generation according to historical project hardware schemes and industry device topology diagrams to generate a module classification tree structure. A standardization unit is configured to standardize pin interfaces of the modules in the module classification tree structure and to unify communication protocols to obtain a target module classification tree structure. a standardized hardware module library generation unit configured to encapsulate modules in the target module classification tree structure to generate the standardized hardware module library; a hardware intermediate layer construction unit configured to construct the hardware intermediate layer based on hardware parameters of the standardized digital twin model.
[0059] Further, the hardware intermediate layer construction unit includes: a hardware capability list generation unit configured to perform functional semantic mapping on the hardware parameters of the standardized digital twin model to generate a hardware capability list; a dynamic adaptation unit configured to construct a unified device API and a dynamic adaptation engine according to the hardware capability list to construct the hardware intermediate layer.
[0060] Further, the component template creation module 73 includes: a template creation request receiving unit configured to receive a template creation request of a user and create the component template on the graphical interface according to the template creation request; a configuration information generation unit configured to obtain configuration information of the user-configured component according to the standardized digital twin model, wherein the configuration information includes component basic information, pin quantity, pin serial number, pin function, and physical model attribute.
[0061] Further, the hardware template creation module 75 includes: a hardware template creation request receiving unit configured to receive a hardware template creation request of a user and create the hardware template on the graphical interface according to the hardware template creation request; a master control chip determination unit configured to determine the master control chip from the component library and receive a target peripheral module determined by the user; a hardware configuration parameter acquisition unit configured to acquire the hardware configuration parameter through the hardware intermediate layer, wherein the hardware configuration parameter includes product basic information, terminal information, component information, and device physical model attribute information.
[0062] Further, the target hardware information generation module 76 includes: a compatibility detection unit configured to add the peripheral module and the master control chip to the hardware template and perform compatibility detection; a configuration unit configured to, if the compatibility detection passes, configure the hardware template based on the hardware configuration parameter to generate the target hardware information; a burnable firmware information generation unit configured to generate the burnable firmware information and the hardware physical list according to the target hardware information.
[0063] To solve the above technical problems, the embodiment of the present application further provides an electronic device. For details, please refer to Figure 9 , Figure 9 The basic structure block diagram of the electronic device of the embodiment is shown in FIG. 1.
[0064] The electronic device 8 comprises a memory 81, a processor 82, and a network interface 83 which are connected to each other through a system bus. It should be noted that, Figure 9 The electronic device 8 with three components, i.e., the memory 81, the processor 82, and the network interface 83 is shown in the figure, but it should be understood that all the components shown are not required to be implemented, and more or less components can be alternatively implemented. It can be understood by those skilled in the art that the electronic device herein is a device capable of automatically performing numerical calculation and / or information processing according to pre-set or stored instructions, and the hardware thereof includes but is not limited to a microprocessor, an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a digital signal processor (DSP), an embedded device, etc.
[0065] The electronic device can be a desktop computer, a notebook computer, a palm computer, a cloud server, and the like. The electronic device can interact with a user through a keyboard, a mouse, a remote controller, a touchpad, a voice control device, and the like.
[0066] The memory 81 includes at least one type of readable storage medium, such as a flash memory, a hard disk, a multimedia card, a card-type memory (e.g., an SD or DX memory, etc.), a random access memory (RAM), a static random access memory (SRAM), a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), a programmable read-only memory (PROM), a magnetic memory, a magnetic disk, an optical disk, etc. In some embodiments, the memory 81 can be an internal storage unit of the electronic device 8, such as a hard disk or a memory of the electronic device 8. In other embodiments, the memory 81 can also be an external storage device of the electronic device 8, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the electronic device 8. Of course, the memory 81 can also include both the internal storage unit and the external storage device of the electronic device 8. In this embodiment, the memory 81 is generally used to store an operating system and various application software installed on the electronic device 8, such as program codes of the above-mentioned artificial intelligence-based embedded development method, etc. In addition, the memory 81 can also be used to temporarily store various data that have been output or will be output.
[0067] The processor 82 can be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip in some embodiments. The processor 82 is generally used to control the overall operation of the electronic device 8. In this embodiment, the processor 82 is used to run program codes or process data stored in the memory 81, such as running program codes of the above-mentioned artificial intelligence-based embedded development method, to implement various embodiments of the artificial intelligence-based embedded development method.
[0068] The network interface 83 can include a wireless network interface or a wired network interface, and is generally used to establish a communication connection between the electronic device 8 and other electronic devices.
[0069] The present application also provides another implementation, i.e., to provide a computer readable storage medium storing a computer program, which can be executed by at least one processor to make the at least one processor execute the steps of an artificial intelligence-based embedded development method as described above.
[0070] Those skilled in the art can clearly understand the above-mentioned embodiment method can be realized by means of software and the necessary general hardware platform, of course, can also be through hardware, but in many cases the former is a better implementation. Based on such understanding, the technical solutions of the present application essentially or say the part of the prior art to make contributions can be in the form of a software product, the computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disc), including a number of instructions to make a terminal device (may be a mobile phone, computer, server, air conditioner, or network equipment, etc.) to execute the method of each embodiment of the present application.
[0071] Obviously, the above-described embodiments are only a part of the embodiments of the present application, rather than all the embodiments, the preferred embodiments of the present application are given in the drawings, but do not limit the scope of the present application. The present application can be implemented in many different forms, and contrary, the purpose of providing these embodiments is to make the disclosure of the present application more thorough and comprehensive. Although the present application is described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions recorded in the foregoing specific embodiments, or make equivalent replacement for some technical features. Any equivalent structure made by using the contents of the present application specification and drawings, directly or indirectly used in other related technical fields, are also within the scope of the present application.
Claims
1. An embedded development method based on artificial intelligence, characterized in that: include: Convert components into standardized digital twin models; Building a standardized hardware module library based on the standardized digital twin model and building a hardware middle layer; Creating a component template through a graphical interface and obtaining configuration information of the user-configured component based on the standardized digital twin model; Performing configuration processing on the component template based on the configuration information to generate target components, and saving the target components into a component library; Creating a hardware template through the graphical interface, determining a main control chip from the component library, and obtaining hardware configuration parameters through the hardware middle layer; The hardware template is configured according to the hardware configuration parameters and the main control chip to generate target hardware information, and burnable firmware information and a hardware physical list are generated based on the target hardware information.
2. The artificial intelligence-based embedded development method according to claim 1, characterized in that: The conversion of components into standardized digital twin models includes: Obtain component data sheets, chip pin definition diagrams, and business requirements documents; Parsing the component data sheet to extract basic properties of the component, generating a structured parameter table, and performing digital modeling of physical properties based on the structured parameter table to generate a physical property model file; Perform pin function mapping based on the chip pin definition diagram to generate a pin function mapping file, and construct an object model description file based on the business requirement document; Generate driver files based on the datasheet register description and historical driver library; The digital twin model is packaged based on the physical property model file, the pin function mapping file and the driver file to generate the standardized digital twin model, and the standardized digital twin model is stored in the component library.
3. The artificial intelligence-based embedded development method according to claim 1, characterized in that: The standardized hardware module library is constructed based on the standardized digital twin model, and the hardware middle layer is constructed, including: Based on historical project hardware solutions and industry equipment topology diagrams, functional dimension disassembly and module label generation are performed to create a module classification tree structure; Standardizing pin interfaces and unifying communication protocols of modules in the module classification tree structure to obtain a target module classification tree structure; Encapsulating the modules in the target module classification tree structure to generate the standardized hardware module library; The hardware middle layer is constructed based on the hardware parameters of the standardized digital twin model.
4. The artificial intelligence-based embedded development method according to claim 3, characterized in that: The step of constructing the hardware intermediate layer based on the parameters of the standardized digital twin model includes: Performing functional semantic mapping on the hardware parameters of the standardized digital twin model to generate a hardware capability list; A unified device API and a dynamic adaptation engine are constructed according to the hardware capability list to construct the hardware middle layer.
5. The artificial intelligence-based embedded development method according to claim 1, characterized in that: The step of creating a component template through a graphical interface and obtaining configuration information of user-configured components based on the standardized digital twin model includes: receiving a template creation request from a user, and creating the component template on the graphical interface according to the template creation request; The configuration information of the user-configured components is obtained according to the standardized digital twin model, wherein the configuration information includes basic component information, pin quantity, pin serial number, pin function and physical model attributes.
6. The artificial intelligence-based embedded development method according to any one of claims 1 to 5, characterized in that: The step of creating a hardware template through the graphical interface, determining a main control chip from the component library, and obtaining hardware configuration parameters through the hardware middle layer includes: receiving a hardware template creation request from a user, and creating the hardware template on the graphical interface according to the hardware template creation request; Determine the main control chip from the component library and receive the target peripheral module determined by the user; The hardware configuration parameters are obtained through the hardware middle layer, wherein the hardware configuration parameters include basic product information, terminal information, component information, and device object model attribute information.
7. The artificial intelligence-based embedded development method according to claim 6, characterized in that: The configuring the hardware template according to the hardware configuration parameters and the main control chip to generate target hardware information, and generating burnable firmware information and a hardware physical list based on the target hardware information includes: Adding the peripheral module and the main control chip to the hardware template and performing compatibility testing; If the compatibility test passes, configuring the hardware template based on the hardware configuration parameters to generate the target hardware information; The burnable firmware information and the hardware physical list are generated according to the target hardware information.
8. An embedded development system based on artificial intelligence, characterized in that: include: A digital twin model building module for converting components into standardized digital twin models; A hardware module library construction module is used to build a standardized hardware module library based on the standardized digital twin model and to build a hardware middle layer; A component template creation module, configured to create a component template through a graphical interface and obtain configuration information of user-configured components based on the standardized digital twin model; a target component generation module, configured to perform configuration processing on the component template based on the configuration information, generate target components, and save the target components into a component library; A hardware template creation module, configured to create a hardware template through the graphical interface, determine a main control chip from the component library, and obtain hardware configuration parameters through the hardware middle layer; The target hardware information generation module is used to configure the hardware template according to the hardware configuration parameters and the main control chip to generate target hardware information, and generate burnable firmware information and a hardware physical list based on the target hardware information.
9. An electronic device, characterized in that: The method comprises a memory and a processor, wherein a computer program is stored in the memory, and when the processor executes the computer program, the artificial intelligence-based embedded development method according to any one of claims 1 to 7 is implemented.
10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the embedded development method based on artificial intelligence as described in any one of claims 1 to 7 is implemented.
Citation Information
Patent Citations
Visual software and hardware collaborative development method
CN105183485A
Internet of things application digital twinning method with block chain features
CN115495485A
Target controller digital twin system
CN117056025A
Firmware configuration method, system, equipment and medium
CN119127287A
Architecture system applied to embedded system development
CN120371268A