A graphical programming method and system for embedded equipment
By using graphical programming methods to draw flowcharts and generate code, the complexity of traditional embedded equipment development is solved, achieving simplified development and efficient code management.
Patent Information
- Application Number
- CN202411706683.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-26
- Publication Date
- 2026-11-03
AI Technical Summary
Traditional embedded device development is complex, requiring a high level of hardware and software knowledge, making code maintenance difficult, firmware updates cumbersome, and code reuse rate low.
A graphical programming approach is adopted, which involves drawing flowcharts of fieldbus communication operations, creating a database and generating code, and using a data structure of nodes and connections to achieve integrated programming of graphics and text code.
It simplifies the embedded development process, reduces dependence on hardware and software, improves code reusability, and simplifies debugging and update processes.
Smart Images
Figure CN123030169A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the technical field of embedded software, and more specifically, relates to a graphical programming method and system for embedded devices. Background Technology
[0002] Embedded equipment refers to equipment that acquires, processes, and outputs control data. Its core is a circuit that can operate various sensors and control components. Such a circuit is generally composed of an MCU, a power supply, and various sensor interfaces.
[0003] Traditionally, developing such controllers requires using embedded C language in a specific development environment. Engineers complete the code, generate firmware, download it to the board, and then debug and install it. This process demands a high level of skill from developers, is complex, and requires engineers to be familiar with various hardware and software operations. Furthermore, during the debugging phase, each change necessitates generating and downloading firmware, making troubleshooting difficult. The firmware also targets a single board, resulting in poor project inheritance and low code reusability.
[0004] Currently, there are some solutions that can simplify embedded development, such as some companies providing SDK development packages to assist engineers in development. However, these solutions still require engineers to write corresponding code, which is troublesome to maintain. Summary of the Invention
[0005] In view of the problems in related technologies, this invention proposes a graphical programming method and system for embedded devices to overcome the aforementioned technical problems existing in the prior art.
[0006] Therefore, the specific technical solution adopted by the present invention is as follows: a graphical programming method for embedded devices, comprising the following steps:
[0007] The fieldbus communication operations are subdivided according to the hierarchical relationship between processes, tasks, and nodes, and corresponding flowcharts are drawn. A database is pre-created, which contains process tables, task tables, node tables, and operation tables. The following steps are performed on the flowcharts to generate corresponding code:
[0008] Obtain the data structure of each node, as well as the data structure of the connection relationship between nodes, and input them into the database and store them according to the corresponding storage structure;
[0009] The nodes are retrieved from the database and pushed onto a stack according to their storage connection status; the corresponding nodes are retrieved from the stack to generate node text; based on the node text and the node's location, subtree text is generated, and the subtree texts are finally connected to form the overall process text.
[0010] In a further embodiment, the hierarchical relationship is specifically as follows:
[0011] Fieldbus communication operations are defined as processes, and fieldbus communication operations are sets of procedures; the process consists of several tasks.
[0012] The task is a process of executing a certain sequence of operations, consisting of several nodes;
[0013] The node is an execution unit within a task, and the node includes at least an execution body, a decision body, and a loop body.
[0014] In a further embodiment, the flowchart is drawn as follows:
[0015] Each of the execution body, decision body, and loop body is assigned a unique graphical design and corresponding operation instructions; the flowchart is then drawn based on the hierarchical relationship.
[0016] The operation instructions of the executor include at least: assignment instructions, arithmetic operation instructions, DSP operations, IO operations, and AD / DA operations;
[0017] The operation instruction for the judgment body is a condition judgment instruction;
[0018] The operation instructions of the loop body are determined by the loop condition, which determines the number of times the execution body within the loop body is executed.
[0019] In a further embodiment, the data structure of the node is S nodes , represented as:
[0020] S nodes ={eType,shape,x,y,len,height,eName,eText};
[0021] In the formula, eType is the node type, shape is the shape assigned to the node, x and y are the coordinates of the node's position on the interface, len and height are the length and width of the node's shape, Name is the node name, and eText is the text content of the node.
[0022] In a further embodiment, the data structure of the connection relationship is S. relation , means as follows:
[0023] S reiation ={iStNode,iEndNode,s x s y ,e x e y ,s eText e eText r Text};
[0024] In the formula, iStNode and iEndNode represent the starting node and ending node of the connection relationship, respectively, and s x s y e represents the coordinates of the starting node's position on the interface. x e y s represents the position coordinates of the end node in the interface. eText The text content of the starting node, e eText For the text content of the ending node, r Text A textual description of the connection relationship.
[0025] In a further embodiment, the storage structure of the node table includes the following fields: primary key, node name, node type, left node, right node, number of operations, and task ID;
[0026] The storage structure of the task table includes the following fields: primary key, task name, task function, number of nodes, process ID, and trigger condition.
[0027] The storage structure of the operation table includes the following fields: primary key, operation name, operation type, node ID, and order.
[0028] In a further embodiment, the process of pushing the node onto the stack is as follows:
[0029] Read in the node and determine if it is an execution body:
[0030] If it is not an execution body, then further determine whether it is a judgment body or a loop body. If it is a judgment body or a loop body, then push it onto the stack along the left subtree until the left subtree is traversed. Push the nodes that have not been traversed in the up stack along the right subtree.
[0031] If it is an execution body, it is added to the execution node array and pushed onto the stack by traversing the right subtree.
[0032] In a further embodiment, the process of retrieving the corresponding node from the stack to generate node text is as follows: When the stack is not empty, repeat the following steps:
[0033] Take a node from the stack as the current node, embed the text of the left subtree that is connected to it, and then fill in the text of the right subtree that is connected to it to generate the node text.
[0034] A graphical programming system for embedded devices, used to implement the graphical programming method described above, includes:
[0035] The first module is configured to subdivide fieldbus communication operations according to the hierarchical relationship between processes, tasks, and nodes, and draw corresponding flowcharts; a database is pre-created, which contains process tables, task tables, node tables, and operation tables; the following steps are executed on the flowcharts to generate corresponding code:
[0036] The second module is set up to obtain the data structure of each node and the data structure of the connection relationship between nodes, and input them into the database and store them according to the corresponding storage structure.
[0037] The third module is configured to retrieve the nodes from the database and push them onto a stack according to the storage connection status of the nodes; retrieve the corresponding nodes from the stack to generate node text; generate subtree text based on the node text and the location of the nodes, and finally connect the subtree texts into a whole process text.
[0038] The beneficial effects of this invention are as follows: This invention provides a graphical programming method to assist embedded engineers in developing devices. By generating executable code through flowcharts, users only need to focus on the process and adjust the device's actions according to external conditions. The logical operations of these actions can be edited graphically, providing a clear overview of the entire process without needing to concern themselves with the specific hardware implementation, thus avoiding extensive prior embedded systems training.
[0039] In other words, users can develop programs using graphical editing tools, focusing their main efforts on logic design and avoiding excessive effort on hardware circuits and MCU structures; the integrated programming implementation of graphics and text code allows for online updates to the board's execution mode without needing to update the board's firmware. Attached Figure Description
[0040] Figure 1 This is a graphical design template of the node in Example 1.
[0041] Figure 2 This is a graphical representation of the process in Example 1.
[0042] Figure 3 This is the operation flow of pushing nodes onto the stack in Example 1.
[0043] Figure 4 This is a flowchart of generating node text by retrieving the corresponding node from the stack. Detailed Implementation
[0044] To further illustrate the various embodiments, the present invention provides accompanying drawings, which are part of the disclosure of the present invention. These drawings are mainly used to illustrate the embodiments and can be used in conjunction with the relevant descriptions in the specification to explain the operating principles of the embodiments. With reference to these drawings, those skilled in the art should be able to understand other possible implementation methods and the advantages of the present invention.
[0045] Example 1
[0046] This embodiment provides a graphical programming method for embedded devices, including the following steps:
[0047] The fieldbus communication operations are subdivided according to the hierarchical relationship between processes, tasks, and nodes, and corresponding flowcharts are drawn. A database is pre-created, which contains process tables, task tables, node tables, and operation tables. The following steps are performed on the flowcharts to generate corresponding code:
[0048] Obtain the data structure of each node, as well as the data structure of the connection relationship between nodes, and input them into the database and store them according to the corresponding storage structure;
[0049] The nodes are retrieved from the database and pushed onto a stack according to their storage connection status; the corresponding nodes are retrieved from the stack to generate node text; based on the node text and the node's location, subtree text is generated, and the subtree texts are finally connected to form the overall process text.
[0050] For ease of understanding and practical operation, the terminology used in this embodiment is explained as follows: Fieldbus communication operations are defined as processes, and fieldbus communication operations are sets of procedures, such as executed I / O operations, digital signal processing algorithms, AD acquisition, DA output, and fieldbus communication operations. Therefore, a process consists of several tasks. Furthermore, a task is a process that executes a sequence of operations, consisting of several nodes.
[0051] Correspondingly, a node is an execution unit within a task, and the node includes at least an execution body, a decision body, and a loop body.
[0052] Based on the above definition, the flowchart drawing process is as follows: assign a unique graphic design and corresponding operation instructions to the execution body, decision body and loop body respectively, and complete the flowchart drawing by combining the hierarchical relationship.
[0053] The graphic design in this embodiment can be referenced. Figure 1 The executable is given a square shape, and the corresponding operation instructions are the calculations and operations to complete the process, including: assignment, four arithmetic operations, DSP operation, IO, AD / DA and fieldbus communication.
[0054] The judgment body is diamond-shaped, and the corresponding operation instruction is a condition judgment instruction; the flow direction is further determined based on whether the condition is met; if the judgment condition is true, the execution body on the left is executed, otherwise the execution body on the right is executed.
[0055] The loop body is composed of two squares, and its operation instruction is determined by the loop condition, which specifies the number of times the execution body within the loop body is executed. The execution body within the loop body is located on the left side of the loop body node. After the loop execution is completed, the process executes the execution body on its right side.
[0056] Taking a certain process as an example, according to the above definition, it includes two tasks: Task 1 and Task 2, which involve further wind stratification treatment. Figure 2 As shown, the nodes of Task 1 include: Executor 1, Decision 1 which is connected to Executor 1, Executor 2 and Loop 1 which are connected to Decision 1, Executor 3 and Executor 4 which are connected to Loop 1.
[0057] The nodes of Task 2 include: Executor 1, Decision 1 which is connected to Executor 1, Executor 3 and Decision 2 which are connected to Decision 1, and Executor 2 which is connected to Executor 3.
[0058] Therefore, even when nodes are the same, the connection relationships between nodes can be different, and there may be a variety of different situations.
[0059] To facilitate reading and management, this embodiment standardizes the data structure of nodes and the data structure of connections between nodes: the data structure of a node is S. nodes , represented as:
[0060] S nodes ={eType,shape,x,y,len,height,eName,eText};
[0061] In the formula, eType is the node type, shape is the shape assigned to the node, x and y are the coordinates of the node's position on the interface, len and height are the length and width of the node's shape, Name is the node name, and eText is the text content of the node.
[0062] The data structure for the join relationship is S relation , means as follows:
[0063] S relation ={iStNode,iEndNode,s x s y ,e x e y s eText eeText r Text};
[0064] In the formula, iStNode and iEndNode represent the starting node and ending node of the connection relationship, respectively, and s x s y e represents the coordinates of the starting node's position on the interface. x e y s represents the position coordinates of the end node in the interface. eText The text content of the starting node, e eText For the text content of the ending node, r Text A textual description of the connection relationship.
[0065] In other words, a clearer relationship description can be achieved by using data structures with the same structure to describe nodes and their connections.
[0066] Furthermore, the storage structure of the node table in Table 1 includes the following fields: primary key, node name, node type, left node, right node, number of operations, and task ID.
[0067] Table 1 Node Table
[0068] field name Field type Field comments id int primary key node_name varchar Node Name node_type varchar Node type left_nodeId int Left node right_nodeId int Right node function_num int Number of operations task_id int Task ID
[0069] As shown in Table 2, the storage structure of the task table includes the following fields: primary key, task name, task function, number of nodes, process ID, and trigger condition.
[0070] Table 2 Task List
[0071] field name Field type Field comments id int primary key task_name varchar Task Name task_use varchar Task Function node_num int Number of nodes byc_id int process ID task_trigger varchar Triggering conditions
[0072] The sequentially executed table stores various specific operations, such as switching relays, DSP algorithms, and bus operations. These operations are stored in the execution operation table. Referring to Table 3, the storage structure of the operation table includes the following fields: primary key, operation name, operation type, node ID, and order.
[0073] Table 3 Operation Table
[0074]
[0075]
[0076] The execution units in the above text consist of a series of operations, the specific forms of which can be obtained from data table 3 above, such as relay switches and AD / DA commands. Users can generate the required code format based on this scheme.
[0077] Based on the above description, the process of pushing a node onto the stack is as follows: Figure 3 As shown, this includes: reading in nodes and determining whether a node is an execution body.
[0078] If it is not an execution body, then further determine whether it is a judgment body or a loop body. If it is a judgment body or a loop body, then push it onto the stack along the left subtree until the left subtree is traversed. Push the nodes that have not been traversed in the up stack along the right subtree.
[0079] If it is an execution body, it is added to the execution node array and pushed onto the stack by traversing the right subtree.
[0080] Figure 4 The flowchart for generating node text by retrieving the corresponding node from the stack includes: repeating the following steps when the stack is not empty:
[0081] Take a node from the stack as the current node, embed the text of the left subtree that is connected to it, and then fill in the text of the right subtree that is connected to it to generate the node text.
[0082] In summary, users can use graphical editing tools for program development, focusing their main efforts on logic design and avoiding spending too much time on hardware circuits and MCU structures.
[0083] The integrated programming implementation of graphics and text code allows for online updates to the board's execution mode without requiring updates to the board's firmware.
[0084] Example 2
[0085] Based on the graphical programming method disclosed in Embodiment 1, this embodiment discloses a graphical programming system for embedded devices, including:
[0086] The first module is configured to subdivide fieldbus communication operations according to the hierarchical relationship between processes, tasks, and nodes, and draw corresponding flowcharts; a database is pre-created, which contains process tables, task tables, node tables, and operation tables; the following steps are executed on the flowcharts to generate corresponding code:
[0087] The second module is set up to obtain the data structure of each node and the data structure of the connection relationship between nodes, and input them into the database and store them according to the corresponding storage structure.
[0088] The third module is configured to retrieve the nodes from the database and push them onto a stack according to the storage connection status of the nodes; retrieve the corresponding nodes from the stack to generate node text; generate subtree text based on the node text and the location of the nodes, and finally connect the subtree texts into a whole process text.
Claims
1. A graphical programming method for embedded devices, characterized in that, Includes the following steps: The fieldbus communication operations are subdivided according to the hierarchical relationship between processes, tasks, and nodes, and corresponding flowcharts are drawn. A database is pre-created, which contains process tables, task tables, node tables, and operation tables. The following steps are performed on the flowcharts to generate corresponding code: Obtain the data structure of each node, as well as the data structure of the connection relationship between nodes, and input them into the database and store them according to the corresponding storage structure; The nodes are retrieved from the database and pushed onto the stack according to their storage connection status. Retrieve the corresponding node from the stack to generate node text; based on the node text, generate subtree text by combining the node's location, and finally connect the subtree texts to form the overall process text.
2. The graphical programming method for embedded devices according to claim 1, characterized in that, The hierarchical relationship is as follows: Fieldbus communication operations are defined as processes, and fieldbus communication operations are sets of procedures; the process consists of several tasks. The task is a process of executing a certain sequence of operations, consisting of several nodes; The node is an execution unit within a task, and the node includes at least an execution body, a decision body, and a loop body.
3. The graphical programming method for embedded devices according to claim 2, characterized in that, The flowchart drawing process is as follows: Each of the execution body, decision body, and loop body is assigned a unique graphical design and corresponding operation instructions; the flowchart is drawn by combining the hierarchical relationship. The operation instructions of the executor include at least: assignment instructions, arithmetic operation instructions, DSP operations, IO operations, and AD / DA operations; The operation instruction for the judgment body is a condition judgment instruction; The number of times the execution body within the loop is executed is determined by the loop condition.
4. The graphical programming method for embedded devices according to claim 1, characterized in that, The data structure of the node is S. nodes , is represented as: S nodes ={eType,shape,x,y,len,height,eName,eText}; In the formula, eType is the node type, shape is the shape assigned to the node, x, y are the coordinates of the node's position on the interface, len, height are the length and width of the node's shape, Name is the node name, and eText is the text content of the node.
5. The graphical programming method for embedded devices according to claim 1, characterized in that, The data structure of the connection relationship is S. relation , means as follows: S relation ={iStNode,iEndNode,s x ,s y ,e x ,e y ,s eText, e eText ,r Text }; In the formula, iStNode and iEndNode represent the starting node and ending node of the connection relationship, respectively, and s x ,s y e represents the coordinates of the starting node's position on the interface. x ,e y s represents the position coordinates of the end node in the interface. eText The text content of the starting node, e eText For the text content of the ending node, r Text A textual description of the connection relationship.
6. The graphical programming method for embedded devices according to claim 1, characterized in that, The storage structure of the node table includes the following fields: Primary key, node name, node type, left node, right node, number of operations, and task ID; The storage structure of the task table includes the following fields: primary key, task name, task function, number of nodes, process ID, and trigger condition. The storage structure of the operation table includes the following fields: primary key, operation name, operation type, node ID, and order.
7. The graphical programming method for embedded devices according to claim 1, characterized in that, The process of pushing the node onto the stack is as follows: Read in the node and determine if it is an execution body: If it is not an execution body, then further determine whether it is a judgment body or a loop body. If it is a judgment body or a loop body, then push it onto the stack along the left subtree until the left subtree is traversed. Push the nodes that have not been traversed in the up stack along the right subtree. If it is an execution body, it is added to the execution node array and pushed onto the stack by traversing the right subtree.
8. The graphical programming method for embedded devices according to claim 1, characterized in that, The process of retrieving the corresponding node from the stack and generating the node text is as follows: When the stack is not empty, repeat the following steps: Take a node from the stack as the current node, embed the text of the left subtree that is connected to it, and then fill in the text of the right subtree that is connected to it to generate the node text.
9. A graphical programming system for embedded devices, used to implement the graphical programming method as described in any one of claims 1 to 8, characterized in that, include: The first module is configured to break down fieldbus communication operations according to the hierarchical relationship between processes, tasks, and nodes, and draw corresponding flowcharts. A database is pre-created, containing process tables, task tables, node tables, and operation tables; the following steps are performed on the flowchart to generate corresponding code: The second module is set up to obtain the data structure of each node and the data structure of the connection relationship between nodes, and input them into the database and store them according to the corresponding storage structure. The third module is configured to retrieve the node from the database and push it onto the stack according to the node's storage connection status. Retrieve the corresponding node from the stack to generate node text; based on the node text, generate subtree text by combining the node's location, and finally connect the subtree texts to form the overall process text.