Implementation method and device of converter software architecture and electronic equipment

Abstract

The invention relates to the technical field of software architecture application, in particular to a converter software architecture implementation method, device and equipment and a computer readable storage medium. The method comprises the steps that software modules are divided according to hardware resource types, and each hardware resource corresponds to an independent code folder; all code operations related to the resource are limited in the folder; defining all user global variables in a single. C file, and declaring the global variables in a single. H file; a layered structure is adopted to realize a communication interface, and comprises a hardware layer, a protocol analysis layer and an application layer. User variables are configured through a structure table, and each variable supports attribute judgment and read-write operation by taking a group number and a sub-index number as a unique identifier. And a three-layer architecture of a hardware layer, a protocol analysis layer and an application layer is adopted, so that the flexibility and expandability of the system are improved. All global variables are declarated through a single. C file and a single. H file, and the problem of repeated definition of the variables is avoided.

Description

Technical Field

[0001] This application relates to the field of software architecture application technology, and in particular to a method, apparatus, electronic device and computer-readable storage medium for implementing a converter software architecture. Background Technology

[0002] As a core device for power conversion, the performance and reliability of a converter are highly dependent on the architecture design of its internal software system. Traditional converter control software is typically developed based on microcontroller units (MCUs), and generally suffers from the following problems and shortcomings: First, traditional software architectures lack strict modular specifications. Driver code for different hardware resources (such as PWM, ADC, and communication interfaces), application-layer algorithms, and global variables are often mixed together, resulting in high code coupling, poor readability, and difficult maintenance. When it is necessary to change the chip model or adjust hardware resources, extensive software refactoring is often required, leading to long development cycles and increasing the risk of errors. Second, in terms of communication protocol processing, traditional methods typically intertwine hardware drivers, protocol parsing, and application processing logic within the same code level. This tightly coupled design makes protocol replacement or upgrades extremely cumbersome, requiring in-depth modifications to multiple code sections, which is not only inefficient but also severely impacts code reliability and reusability. Third, for the management of system global variables, traditional methods often define them in multiple files, lacking a unified management mechanism. This easily leads to problems such as variable duplication, naming conflicts, and chaotic memory management, which is particularly prominent in medium to large-scale projects. Finally, there is a lack of an efficient, secure, and scalable mechanism for accessing and managing user parameters. The traditional approach is to use a large number of switch-case or if-else statements to query by variable ID. This method is inefficient, and the function code needs to be modified for each additional parameter, which is not conducive to software iteration and maintenance.

[0003] In summary, there is an urgent need in the field for a converter software architecture design method that is structurally clear, highly modular, easy to maintain and expand, in order to solve the aforementioned technical problems. Summary of the Invention

[0004] This application aims to at least partially address one of the technical problems in the related art.

[0005] Therefore, the first objective of this application is to propose a method for implementing a converter software architecture to address the shortcomings of existing converter software in terms of maintainability, portability, scalability, and parameter management.

[0006] The second objective of this application is to provide an apparatus.

[0007] The third objective of this application is to propose an electronic device.

[0008] The fourth objective of this application is to provide a computer-readable storage medium.

[0009] To achieve the above objectives, the first aspect of this application proposes a method for implementing a converter software architecture, comprising: Software modules are divided according to hardware resource type, with each hardware resource corresponding to an independent code folder, and all code operations related to that resource are restricted to that folder; Define all user-defined global variables in a single .c file, and declare the global variables in a single .h file for other modules to call; The communication interface is implemented using a layered structure, including a hardware layer, a protocol parsing layer, and an application layer; User variables are configured through a structured table. Each variable is uniquely identified by its group number and sub-index number, and attribute judgment and read / write operations are supported.

[0010] Preferably, the implementation of the hardware layer includes: The hardware port status is checked cyclically using a query method. When the transmit port is idle and the transmit buffer contains data, the data is written to the hardware transmit register and transmission is started. When there is data at the receive port, the data is read from the hardware receive register into the user receive buffer.

[0011] Preferably, the implementation of the protocol parsing layer includes: Add frame headers, frame trailers, and checksum information to user data according to the communication protocol to form a complete frame and store it in the transmission buffer; The system detects the frame header, parses the frame length, and performs verification in the receive buffer. If the verification is successful, the data is extracted and transmitted to the application layer.

[0012] Preferably, the steps of detecting the frame header, parsing the frame length, and performing verification from the receive buffer, and extracting data and transmitting it to the application layer after successful verification, include: Continuously monitor the frame header bytes in the receive buffer; If a frame header is detected, the length of the current frame data is obtained according to the protocol; if the received data length is insufficient, the system waits for the next call to continue detection; if the data is received completely, a verification is performed, and if the verification is successful, the data is transmitted to the application layer; otherwise, the current frame is skipped.

[0013] Preferably, the implementation of the application layer includes: Construct a user variable table, wherein each entry in the user variable table contains a sub-index number, a variable attribute, and a pointer to the actual variable; Access the table based on the received group number and sub-index number, determine the variable attributes, and perform read and write operations; If there is a write operation, determine the writable attribute and write it to the target variable; if there is a read operation, read the variable value and send it after being packaged by the protocol layer.

[0014] Preferably, the variable attributes include at least one of the following: writable flag, storage type, data type, and log saving flag.

[0015] Preferably, it further includes: In the early stages of software development, a fixed project template structure should be established, and modifications to register definitions, interrupt vector tables, and memory allocation files within the template should be prohibited. User development is limited to the specified source file directory and main program file.

[0016] To achieve the above objectives, a second aspect of this application provides an implementation apparatus for a converter software architecture, comprising: The resource type division module divides the software modules according to the hardware resource type. Each hardware resource corresponds to an independent code folder, and all code operations related to that resource are restricted to that folder. The global variable definition module defines all user-defined global variables in a single .c file and declares these global variables in a single .h file for other modules to call. The module adopts a layered structure to implement the communication interface, including a hardware layer, a protocol parsing layer, and an application layer; The user variable configuration module configures user variables through a structure table. Each variable is uniquely identified by its group number and sub-index number, and supports attribute judgment and read / write operations.

[0017] To achieve the above objectives, a third aspect of this application provides an electronic device, including: a processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method described in any of the preceding descriptions.

[0018] To achieve the above objectives, a fourth aspect of this application provides a computer-readable storage medium, comprising computer-executable instructions stored therein, which, when executed by a processor, are used to implement the method described in any of the above embodiments.

[0019] This application provides a converter software architecture implementation method that strictly limits the code boundaries of each functional module by dividing the code into independent code folders according to hardware resources, achieving a highly cohesive and loosely coupled software design. This makes the code structure clear, allowing developers to quickly locate and understand the code for specific functions, greatly improving the maintainability and readability of the software. The three-layer communication architecture of hardware layer, protocol parsing layer, and application layer makes the responsibilities of each layer clear. When the protocol changes or is upgraded, only the protocol parsing layer needs to be modified, without changing the hardware driver or application logic; similarly, when changing the hardware interface, only the hardware layer needs to be adapted, fully embodying the "open / closed principle" of design patterns and improving the system's flexibility and scalability. A centralized variable management mechanism is established by defining all global variables in a single .c file and declaring them in a .h file, effectively avoiding variable duplication and naming conflicts, and enhancing code standardization and security. User variables are configured in a structured table format and accessed by mapping using group number and sub-index number. This mechanism allows adding, deleting, and modifying parameters without modifying the underlying access functions; only adding or modifying entries in the configuration table is required, greatly improving the efficiency and flexibility of parameter management and supporting rapid system iteration. Meanwhile, built-in writable attributes, storage type flags, and other features enhance the security and reliability of parameter access.

[0020] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0021] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 A flowchart of a first specific embodiment of a converter software architecture implementation method provided by the present invention; Figure 2 This is a folder structure diagram for the 28335 program project; Figure 3 Develop the contents of the Source folder for users; Figure 4 A diagram illustrating the definition and declaration of global variables; Figure 5 A schematic diagram of the hardware layer sending function structure; Figure 6 This is a schematic diagram of the hardware layer receiver function structure; Figure 7 A schematic diagram of the sending parsing function structure; Figure 8 A schematic diagram of the receiving parsing function structure; Figure 9 A diagram illustrating the definition of user variable groups; Figure 10 This is a summary diagram of the parameter group data; Figure 11 This is a structural block diagram of a converter software architecture implementation device provided in an embodiment of the present invention. Detailed Implementation

[0022] The core of this invention is to provide a method, apparatus, electronic device, and computer-readable storage medium for implementing a converter software architecture. Through systematic architecture design, it effectively solves the defects of traditional converter software in terms of maintainability, portability, scalability, and parameter management.

[0023] To enable those skilled in the art to better understand the present invention, the invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are merely some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0024] Please refer to Figure 1 , Figure 1 The flowchart shows a first specific embodiment of the implementation method of the converter software architecture provided by the present invention; the specific operation steps are as follows: Step S101: Divide the software modules according to the type of hardware resources. Each hardware resource corresponds to an independent code folder. All code operations related to the resource are restricted to this folder. Step S102: Define all user-defined global variables in a single .c file and declare the global variables in a single .h file for other modules to call; Step S103: Implement the communication interface using a layered structure, including a hardware layer, a protocol parsing layer, and an application layer; Step S104: Configure user variables through a structure table. Each variable is uniquely identified by its group number and sub-index number, and supports attribute judgment and read / write operations.

[0025] Based on the above embodiments, this embodiment will provide a detailed description of step S101: Specifically, when a new MCU is put into use, in the early stages of software development, a software template in the example code is generally used as a reference. This template defines all register addresses, interrupt vector tables, clock phase-locked loop configurations, and other information. Once the template is determined, its definition content (including macro definitions, adding variables, deleting variables, etc.) is not allowed to be changed without authorization, and all user operations are confined to the user-defined folder. To increase software readability, each CPU / type of CPU software has the same software structure, which is determined in the early stages of CPU software development and remains unchanged unless there is a special need.

[0026] For a software project, hardware resources are defined in folders. Each hardware resource (such as SCIA, CANB, etc.) occupies one folder, and all code operations related to that resource are confined to the corresponding folder. Hardware resource calls are interfaced through application functions and global variables. For example... Figure 2 As shown, the 28335 program currently in use is used for illustration. The project contains three folders: DSP2833x_common, DSP2833x_headers, and DSP28335_Project. This is the template structure and will not be changed.

[0027] The DSP2833x_common folder contains: The cmd folder contains the starting address and length of all relevant Momory spaces as defined in the chip data. Unless there are special needs, the contents of this folder do not need to be modified and can be used directly. The gel folder defines all .gel files, which are rarely used by users and therefore do not need to be modified. The include folder defines all system macro definitions and library file calling interfaces, so no modifications are needed; The lib folder defines all system library files; no modifications are needed. The source folder defines all hardware resource programming. All user operations on hardware resources are limited to this folder. The contents of this folder will be described in detail later.

[0028] The DSP2833x_headers folder contains: The cmd folder is defined as system files and should not be modified. The gel folder is defined as system files and should not be modified. The include folder defines all register bit definitions; no modifications are needed.

[0029] The DSP28335_Project folder contains a Project folder, and its next-level subfolders contain: The `debug` folder contains all the compilation process files, the corresponding `.obj` file, `.map` file, and `.out` file for each `.c` file. The `.map` file displays the absolute addresses of all variables and functions mapped to memory, and the `.out` file is the target file to be written to flash memory. The contents of the `debug` folder are all automatically generated by the project and do not require modification. The main.c file contains the program entry point main() function, all interrupt service routines, and all other function calls, which require user programming.

[0030] Other files generated during project creation do not need to be modified. The above describes the framework of the entire project. The user's work is limited to the \DSP2833x_common\source folder and the \DSP28335_Project\Project\main.c file. All other files do not need to be modified.

[0031] Based on the above embodiments, this embodiment will provide a detailed description of step S102: Specifically, the contents of a typical Source folder are shown in the figure, containing all functions related to hardware resources, such as... Figure 3 As shown, the ADCInner folder corresponds to internal AD sampling; the ECANA folder corresponds to the ECANA communication interface; the EPWM folder corresponds to EPWM hardware resources; the GPIO folder defines all multiplexed IO functions and input / output directions; the System folder defines system-related phase-locked loops, clocks, interrupt vector tables, etc., which generally do not need to be modified by the user; the Main folder defines all global variables and external declarations; ...; Arithmetic contains all power electronic control algorithms.

[0032] The entire project uses one .c file to define all user-global variables and one .h file to declare all user-global variables for all functions to access and call. These files are stored in the Main folder. Templates for the .c and .h file contents are as follows: Figure 4 As shown.

[0033] In one embodiment, the main control word MPR_MainCtrlWord defines a structure data type in the .h file and declares external variables, and defines variables in the .c file to allocate storage space at compile time.

[0034] Based on the above embodiments, this embodiment will provide a detailed description of step S103: In one embodiment, the hardware port status is checked cyclically using a query method; When the transmit port is idle and the transmit buffer contains data, the data is written to the hardware transmit register and transmission is started. When there is data at the receive port, the data is read from the hardware receive register into the user receive buffer.

[0035] The implementation of the protocol parsing layer includes: Add frame headers, frame trailers, and checksum information to user data according to the communication protocol to form a complete frame and store it in the transmission buffer; The process involves detecting the frame header, parsing the frame length, and performing verification in the receive buffer. Upon successful verification, the data is extracted and transmitted to the application layer, including: Continuously monitor the frame header bytes in the receive buffer; If a frame header is detected, the length of the current frame data is obtained according to the protocol; if the received data length is insufficient, the system waits for the next call to continue detection; if the data is received completely, a verification is performed, and if the verification is successful, the data is transmitted to the application layer; otherwise, the current frame is skipped.

[0036] The implementation of the application layer includes: Construct a user variable table, wherein each entry in the user variable table contains a sub-index number, variable attributes, and a pointer to the actual variable, wherein the variable attributes include at least one of the following: writable flag, storage type, data type, and log saving flag; Access the table based on the received group number and sub-index number, determine the variable attributes, and perform read and write operations; If there is a write operation, determine the writable attribute and write it to the target variable; if there is a read operation, read the variable value and send it after being packaged by the protocol layer.

[0037] Specifically, for hardware resource usage, if user timing can be controlled, polling is generally used. Interrupts should be used as little as possible unless there are special needs. Programming communication interface hardware resources (SCI, SPI, I2C, CAN, etc.) is generally implemented in three layers: hardware, protocol, and application. Data is transferred between layers through user-defined send and receive buffers, which use a circular queue data structure. When communication is relatively simple, two or three layers can be combined.

[0038] Hardware layer: The lowest layer is the hardware layer, which contains register definitions, send functions, and receive functions. Unless there are specific timing requirements, the send and receive functions are called cyclically within the main program. The send function's functionality is as follows: Figure 5 As shown, the system continuously queries the status of the transmitting hardware port. When the hardware is idle and the user-defined transmit buffer has data to send, it writes the contents of the user-defined transmit buffer into the hardware transmit buffer in batches, moving the pointer forward according to the number of data items. After writing to the transmit register, it initiates hardware transmission. If there is a multi-machine transmit conflict arbitration mechanism, it checks whether it already has bus control before transmitting. If the hardware has a transmit buffer (FIFO) or uses DMA, each transmission sends multiple bytes (words); otherwise, it sends only one byte (word).

[0039] The receiving function is as follows Figure 6 As shown, the system continuously queries the status of the receiving hardware port. When data is detected in the receive register, its contents are read into the user-defined receive buffer. The pointer is then moved forward according to the number of data items, and the transmit buffer is set to "empty". If the hardware has a receive buffer (FIFO) or uses DMA, multiple bytes (words) of data are received each time; otherwise, only one byte (word) is received.

[0040] Protocol parsing layer: Above the hardware layer is the protocol parsing layer, which contains send and receive parsing functions. The send parsing function is called at a higher layer (application layer); the receive parsing function is called in the main program.

[0041] Send parsing function functionality such as Figure 7 As shown, each time it is called, according to the communication protocol, the user data is packaged and processed with frame header, frame tail, encryption, verification and other information to form a frame message, which is then assigned to the user-defined sending buffer, and the pointer is moved forward according to the message length. The receiving parsing function has the following functionality: Figure 8 As shown, query whether the user-defined receive buffer has received data; When data is received, according to the communication protocol, the frame header byte (word) is continuously checked. If it is not the frame header, the pointer moves forward one byte (word) and continues to check until it is detected or the user-defined receive buffer is empty.

[0042] After detecting the frame header, the length of the current frame data is determined according to the communication protocol. If the length of the received bytes (words) is less than the length of the current frame, the current call is skipped, and the check continues in the next call. Upon receiving a full-length frame, data verification is performed according to the communication protocol. If the verification is successful, the upper-layer user application function is called, and the user data is passed to the user layer to trigger the execution of user operations. At the same time, the pointer moves forward out of the current frame. If the verification fails, no operation is performed, and the pointer moves forward one byte (word).

[0043] Then proceed with the next frame of data detection, repeating the above steps.

[0044] Application layer: The application layer software consists of two parts: user variable data tables and application layer functions. The `Const` keyword is used to define pointer tables, mapping user data address pointers related to this communication to Flash space. Each user data item defines its own parameters in the table, including whether it is writable, its actual storage space, whether it needs to be sent periodically, and the periodic sending time. Application layer functions call these tables to complete the communication between user data and other objects. When user data changes, simply add rows to the table. The table definition method is described using a local monitoring table as an example: Step 1: As Figure 9 As shown, a user variable group is defined, with data type being a custom structure RTMType, named sParaData_Groupxx[]. The RTMType structure contains a sub-index number SubNum, a union para, and a target variable *Obj. The sub-index SubNum is used to specify the sub-index number of the target variable *Obj in the corresponding group; The union maps one word variable and one bit-defined variable to the same storage space, allowing users to manipulate the target variable *Obj in either word or bit mode. The nested structure in the union defines the attributes of each user variable *Obj in bit mode, including the writable attribute WrFlag, the attribute LogSaveFlag indicating whether to log after writing, the storage space attribute MomoryFlag (including Ram, Rom, etc.), and the data type attribute DataType (int, long, string, etc.).

[0045] The target variable *Obj points to the address of the user variable. Although it is defined as int here, it can be used to match the long or string data type by force casting.

[0046] Step 2: As Figure 10 As shown, all parameter group data are summarized in a structure named sParaData_Summary[]. The RTMSummaryType structure contains the parameter group number (index number) GroupNum and a pointer to the first address of the parameter group *SubGroup.

[0047] Each target variable uses a group number:sub-index number mapping, such as the third variable in group 1 uniquely corresponding to the system time System_Hour.

[0048] Application layer functions use the table as follows: When a write command is received, the group number and sub-index number are used to determine whether the table has a writable attribute, and the value is written to the target address variable; when a read command is received, the target variable value is read based on the group number and sub-index number, and then processed by the protocol and transmitted to the user-defined send buffer.

[0049] In the early stages of software development, a fixed project template structure should be established, and modifications to register definitions, interrupt vector tables, and memory allocation files within the template should be prohibited; user development should be limited to the specified source file directory and main program file.

[0050] This embodiment provides a method for implementing a converter software architecture. By dividing the code into independent folders according to hardware resources, the code boundaries of each functional module are strictly limited, achieving a highly cohesive and loosely coupled software design. This makes the code structure clear, allowing developers to quickly locate and understand the code for specific functions, greatly improving the maintainability and readability of the software. The three-layer communication architecture of hardware layer, protocol parsing layer, and application layer makes the responsibilities of each layer clear. When the protocol changes or is upgraded, only the protocol parsing layer needs to be modified, without changing the hardware driver or application logic; similarly, when changing the hardware interface, only the hardware layer needs to be adapted, fully reflecting the "open / closed principle" of design patterns and improving the system's flexibility and scalability. By defining all global variables in a single .c file and declaring them in a .h file, a centralized variable management mechanism is established, effectively avoiding variable duplication and naming conflicts, and enhancing code standardization and security. User variables are configured in a structured table format and accessed by mapping using group number and sub-index number. This mechanism allows adding, deleting, and modifying parameters without modifying the underlying access functions; only adding or modifying entries in the configuration table is required, greatly improving the efficiency and flexibility of parameter management and supporting rapid system iteration. Meanwhile, built-in writable attributes, storage type flags, and other features enhance the security and reliability of parameter access.

[0051] Based on the above embodiments, this embodiment uses a specific example to describe the implementation method of the converter software architecture, as follows: This embodiment uses a converter control system employing a TI TMS320F28335 DSP as an example to illustrate the implementation of the present invention in detail.

[0052] System development environment and engineering structure establishment: First, in the Code Composer Studio (CCS) development environment, create a new software project based on the standard project template provided by the chip manufacturer. The project contains the following three fixed folder structures: DSP2833x_common: Contains memory linking command files (.cmd), system library files (.lib), gel files (.gel), and source files (.c) and header files (.h) for all peripheral drivers.

[0053] DSP2833x_headers: A header file containing all register and bit definitions for the chip.

[0054] DSP28335_Project: Contains the user's main program file (main.c) and project configuration files.

[0055] All user development work is strictly limited to the various function folders under the DSP2833x_common / source directory and the DSP28335_Project / Project / main.c file.

[0056] Modular implementation of hardware resources: In the DSP283x_common / source directory, create a separate folder for each hardware peripheral: EPWM: Contains all initialization functions (EPWM_Init.c), duty cycle update functions (EPWM_UpdateDuty.c), etc. of the enhanced pulse width modulation module.

[0057] ADCInner: Contains functions for initializing the internal ADC module, triggering sampling, and reading results.

[0058] ECANA: Contains the initialization, sending, and receiving functions for the CAN communication module.

[0059] GPIO: Contains initialization and status read / write functions for all general-purpose input / output ports.

[0060] System: Contains system initialization, phase-locked loop (PLL) configuration, and watchdog management functions.

[0061] Arithmetic: Includes all power electronic control algorithm functions such as PID regulation and Park / Clarke transformation.

[0062] Main: Contains the global variable definition file (GlobalVars.c) and its declaration file (GlobalVars.h).

[0063] Centralized management of global variables: All global variables are defined in Main / GlobalVars.c, and their declarations and structure definitions are made in Main / GlobalVars.h.

[0064] Implementation of layered development for communication software: Taking CAN communication (ECANA) as an example, this paper illustrates the implementation of a three-layer architecture; Hardware layer implementation: Implement hardware layer functions in ECANA / ECANA_HW.c: ECANA_TxFunction(): Loop through the CAN mailbox transmission status. If the mailbox is idle and the application layer transmit buffer (sUserTxBuffer) has data, write the data to the hardware mailbox and start transmission.

[0065] ECANA_RxFunction(): Loops through the CAN mailbox to check the reception status. If a new message is received, the data is read into the application layer receive buffer (sUserRxBuffer).

[0066] Protocol parsing layer implementation: Implement the protocol parsing function in ECANA / ECANA_Protocol.c, assuming the CANopen protocol frame format is used.

[0067] ECANA_ProtocolParseTx(): Called by the application layer. It receives a data object (e.g., object dictionary index, sub-index, data), packages it into a complete CANopen protocol frame (including COB-ID, Data Length Code (DLC), and data fields), and puts it into sUserTxBuffer.

[0068] ECANA_ProtocolParseRx(): Called in the main loop. It continuously scans the sUserRxBuffer to find the start of a protocol frame (COB-ID). Upon detection, it parses the frame structure according to the protocol, verifying the data length and integrity. If verification passes, it extracts the data object (index, sub-index, data) and calls the application-layer callback function ECANA_AppCallback().

[0069] Application layer implementation: The application layer manages all variables accessible via CAN communication through a parameter table: The first step is to define the parameter structure in Main / ParameterTable.h; The second step is to create a parameter table, which is instantiated in Main / ParameterTable.c. The third step involves application layer function operations. When the protocol parsing layer ECANA_ProtocolParseRx() parses a write instruction (group number 0x2000, sub-index 0, data 400), it will call the application layer function.

[0070] The function iterates through the sParaData_Summary table, finds group number 0x2000, then finds sub-index 0 in its sub-table, checks that its WrFlag attribute is writable, and writes the data 400 into the variable System_Voltage pointed to by the Obj pointer, thus realizing the function of modifying the system voltage reference value through communication messages.

[0071] Main program flow: In main.c, the main function executes in the following order: Call System_Init() to initialize the system clock, PLL, and watchdog timer.

[0072] Call the initialization functions of each hardware module (EPWM_Init(), ADC_Init(), ECANA_Init()).

[0073] Enter the main loop while(1): Call the control algorithm function (Arithmetic_PID()).

[0074] Call the hardware layer functions (ECANA_TxFunction(), ECANA_RxFunction()).

[0075] Call the protocol parsing function (ECANA_ProtocolParseRx()).

[0076] Handle other tasks (fault protection, state machines, etc.).

[0077] Please refer to Figure 11 , Figure 11 This invention provides a structural block diagram of an implementation device for a converter software architecture; the specific device may include: Resource type division module 100 divides software modules according to hardware resource type. Each hardware resource corresponds to an independent code folder, and all code operations related to that resource are restricted to that folder. The global variable definition module 200 defines all user-defined global variables in a single .c file and declares the global variables in a single .h file for other modules to call. The hierarchical module 300 adopts a hierarchical structure to implement the communication interface, including a hardware layer, a protocol parsing layer, and an application layer; The user variable configuration module 400 configures user variables through a structure table. Each variable is uniquely identified by its group number and sub-index number, and supports attribute judgment and read / write operations.

[0078] The converter software architecture implementation device of this embodiment is used to implement the aforementioned converter software architecture implementation method. Therefore, the specific implementation method of the converter software architecture implementation device can be found in the embodiment section of the converter software architecture implementation method above. For example, the resource type division module 100, the global variable definition module 200, the structure layering module 300, and the user variable configuration module 400 are respectively used to implement steps S101, S102, S103, and S104 in the converter software architecture implementation method. Therefore, its specific implementation method can be referred to the description of the corresponding embodiment, and will not be repeated here.

[0079] To implement the above embodiments, this application also proposes an electronic device, including: a processor and a memory communicatively connected to the processor; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory to implement the method provided in the foregoing embodiments.

[0080] To implement the above embodiments, this application also proposes a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods provided in the foregoing embodiments.

[0081] To implement the above embodiments, this application also proposes a computer program product, including a computer program that, when executed by a processor, implements the methods provided in the foregoing embodiments.

[0082] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in this application all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0083] It should be noted that personal information collected from users should be used for legitimate and reasonable purposes and should not be shared or sold outside of these legitimate uses. Furthermore, such collection / sharing should only be conducted after receiving the user's informed consent, including but not limited to notifying the user to read the user agreement / user notice and sign an agreement / authorization that includes authorization of relevant user information before the user uses the function. In addition, any necessary steps must be taken to protect and safeguard access to such personal information data and ensure that others with access to personal information data comply with their privacy policies and procedures.

[0084] This application is intended to provide an implementation scheme for users to selectively prevent the use or access to their personal information data. Specifically, this disclosure is intended to provide hardware and / or software to prevent or block access to such personal information data. Once personal information data is no longer needed, risks can be minimized by restricting data collection and deleting data. Furthermore, where applicable, such personal information is de-identified to protect user privacy.

[0085] In the foregoing descriptions of the embodiments, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0086] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0087] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0088] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0089] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0090] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0091] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0092] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

Claims

1. A method for implementing a converter software architecture, characterized in that, include: Software modules are divided according to hardware resource type, with each hardware resource corresponding to an independent code folder, and all code operations related to that resource are restricted to that folder; Define all user-defined global variables in a single .c file, and declare the global variables in a single .h file for other modules to call; The communication interface is implemented using a layered structure, including a hardware layer, a protocol parsing layer, and an application layer; User variables are configured through a structured table. Each variable is uniquely identified by its group number and sub-index number, and attribute judgment and read / write operations are supported.

2. The method for implementing the converter software architecture according to claim 1, characterized in that, The implementation of the hardware layer includes: The hardware port status is checked cyclically using a query method. When the transmit port is idle and the transmit buffer contains data, the data is written to the hardware transmit register and transmission is started. When there is data at the receive port, the data is read from the hardware receive register into the user receive buffer.

3. The method for implementing the converter software architecture according to claim 1, characterized in that, The implementation of the protocol parsing layer includes: Add frame headers, frame trailers, and checksum information to user data according to the communication protocol to form a complete frame and store it in the transmission buffer; The system detects the frame header, parses the frame length, and performs verification in the receive buffer. If the verification is successful, the data is extracted and transmitted to the application layer.

4. The method for implementing the converter software architecture according to claim 3, characterized in that, The steps of detecting the frame header, parsing the frame length, and performing verification from the receive buffer, and extracting data and transmitting it to the application layer after successful verification, include: Continuously monitor the frame header bytes in the receive buffer; If a frame header is detected, the length of the current frame data is obtained according to the protocol; if the received data length is insufficient, the system waits for the next call to continue detection; if the data is received completely, a verification is performed, and if the verification is successful, the data is transmitted to the application layer; otherwise, the current frame is skipped.

5. The method for implementing the converter software architecture according to claim 1, characterized in that, The implementation of the application layer includes: Construct a user variable table, wherein each entry in the user variable table contains a sub-index number, a variable attribute, and a pointer to the actual variable; Access the table based on the received group number and sub-index number, determine the variable attributes, and perform read and write operations; If there is a write operation, determine the writable attribute and write it to the target variable; if there is a read operation, read the variable value and send it after being packaged by the protocol layer.

6. The method for implementing the converter software architecture according to claim 5, characterized in that, The variable attributes include at least one of the following: writable flag, storage type, data type, and log saving flag.

7. The method for implementing the converter software architecture according to claim 1, characterized in that, Also includes: In the early stages of software development, a fixed project template structure should be established, and modifications to register definitions, interrupt vector tables, and memory allocation files within the template should be prohibited. User development is limited to the specified source file directory and main program file.

8. A device for implementing a converter software architecture, characterized in that, include: The resource type division module divides the software modules according to the hardware resource type. Each hardware resource corresponds to an independent code folder, and all code operations related to that resource are restricted to that folder. The global variable definition module defines all user-defined global variables in a single .c file and declares these global variables in a single .h file for other modules to call. The module adopts a layered structure to implement the communication interface, including a hardware layer, a protocol parsing layer, and an application layer; The user variable configuration module configures user variables through a structure table. Each variable is uniquely identified by its group number and sub-index number, and supports attribute judgment and read / write operations.

9. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-7.

Images