Power supply development software architecture, method, equipment and computer medium
By adopting a three-layer architecture (application layer, intermediate layer and driver layer) in power development, the serious problem of code coupling in the existing technology and the lack of multi-person collaboration is solved, the separation of operations and devices and the decoupling of code is achieved, and the development efficiency and code management are improved.
Patent Information
- Application Number
- CN202411986356.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-31
- Publication Date
- 2025-05-06
AI Technical Summary
The existing PG power development process is not very modular, resulting in a mix of hardware resources and business processes, serious code coupling, difficult to maintain after updates and iterations, and lack of support for multi-person collaboration and module debugging.
It adopts a three-layer architecture, namely the application layer, the intermediate layer and the driver layer. The application layer analyzes business function instructions. The intermediate layer provides a business operation interface, the driver layer registers the device and bus driver, and packages the implementation method to achieve the separation of operations and devices.
Through a hierarchical architecture, the code is decoupled and reused, and the simultaneous development of multiple people is supported, which simplifies device porting and debugging, and improves the unity of development efficiency and code management.
Smart Images

Figure CN119938027A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the technical field of power supply development, and more specifically, to a power supply development software architecture, a power supply development method, an electronic device, and a non-transitory computer-readable storage medium. Background Art
[0002] The current PG power supply development process is not highly modularized, and hardware resources are easily mixed with business processes. After several versions are updated, code coupling is very likely to occur. For example, different businesses and drivers will be intertwined, and changing one code may involve many non-corresponding parts, resulting in increased workload and difficulty in troubleshooting hidden problems. In addition, the code is not portable and does not support simultaneous step-by-step development / debugging by multiple people. Due to code coupling, it can only be developed by the same person, and there is a lack of means for debugging by module. Summary of the invention
[0003] In response to at least one defect or improvement need in the prior art, the present invention provides a power supply development software architecture, aiming to develop a general framework for code decoupling, separating devices from operations, improving code reusability, and supporting multiple people to develop different functions at the same time.
[0004] To achieve the above-mentioned purpose, according to the first aspect of the present invention, a power supply development software architecture is provided, including: an application layer, which is used to obtain and parse business function instructions in the power supply development process; an intermediate layer, which is provided with business operation interfaces corresponding to each of the business function instructions, and the business operation interface is used to provide the application layer with directly callable function functions according to the business function instructions, and the application layer implements corresponding business functions according to the combination of the function functions; a driver layer, which registers device drivers and bus drivers corresponding to the business operation interfaces, and encapsulates corresponding implementation methods according to the device drivers and the bus drivers, so as to provide the intermediate layer with the implementation methods when the application layer calls the business operation interface.
[0005] In one embodiment of the present invention, the application layer, the middle layer and the driver layer are respectively divided into a top and a bottom. The top provides a registration function and a query linked list function to the bottom of the same layer. The bottom hangs the implementation method into a linked list according to the registration function and waits for the top to query and call.
[0006] In one embodiment of the present invention, the top of the driver layer includes a packaging module and a packaging management module. The packaging module is used to query the linked list according to the board information to find the corresponding device driver and the bus driver and encapsulate the corresponding implementation method for the application layer to call. The packaging management module provides the registration function, the query linked list function and the data structure of the implementation method.
[0007] In one embodiment of the present invention, the intermediate layer implements the service operation interface through a hardware port configuration file, and the hardware port configuration file includes board information, devices used by the service function, required processor resources and the implementation method.
[0008] In one embodiment of the present invention, the intermediate layer is provided with a platform device driver, and the platform device driver integrates the bus driver and the device driver by constructing a virtual bus for the intermediate layer to call.
[0009] In one embodiment of the present invention, the initialization programs of the application layer, the intermediate layer and the driver layer are respectively registered in corresponding memories and are called by the main function when executing the initialization process, thereby initializing the driver layer, the intermediate layer and the application layer in sequence.
[0010] According to a second aspect of the present invention, a power supply development method is also provided, which is applicable to the power supply development software architecture described in any one of the above embodiments, including: dividing the power supply development software architecture into an application layer, an intermediate layer and a driver layer; the application layer is used to obtain and parse the business function instructions in the power supply development process; the intermediate layer is provided with a business operation interface corresponding to each of the business function instructions, and the business operation interface is used to provide the application layer with a function function that can be directly called according to the business function instruction, and the application layer implements the corresponding business function according to the combination of the function functions; the driver layer registers a device driver and a bus driver corresponding to the business operation interface, and encapsulates the corresponding implementation method according to the device driver and the bus driver, so that the intermediate layer can call the implementation method when the application layer calls the business operation interface.
[0011] In one embodiment of the present invention, the power supply development method further includes: dividing the application layer, the middle layer and the driver layer into top and bottom layers respectively, the top layer provides a registration function and a query linked list function to the bottom layer of the same layer, and the bottom layer hangs the implementation method into a linked list according to the registration function, waiting for the top layer to query and call.
[0012] According to the third aspect of the present invention, there is also provided an electronic device, comprising a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the method described in any one of the above embodiments when executing the program.
[0013] According to a fourth aspect of the present invention, there is also provided a non-transitory computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the method described in any one of the above embodiments.
[0014] In general, the above technical solutions conceived by the present invention can achieve at least the following beneficial effects compared with the prior art:
[0015] By dividing the power supply development software architecture into an application layer, an intermediate layer and a driver layer, the application layer obtains and parses the business function instructions in the power supply development process, and the intermediate layer is provided with a business operation interface corresponding to each business function instruction, which is used to provide the application layer with a function function that can be directly called according to the business function instruction, and realize the corresponding business function through a combination of function functions. The driver layer registers device drivers and bus drivers corresponding to the business operation interface, and encapsulates them into corresponding implementation methods for the intermediate layer to call, thereby realizing the separation of operation and device. It is more convenient to transplant / add / delete / match different devices under the same module without introducing hidden problems, and there is a unified input and output format, which can quickly locate exceptions during debugging. In addition, after layering, the code can be uniformly managed with higher efficiency, and the expansion of new functions is simpler and controllable. BRIEF DESCRIPTION OF THE DRAWINGS
[0016] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.
[0017] Figure 1 A functional execution diagram of a power development software architecture provided in an embodiment of the present application;
[0018] Figure 2 A schematic diagram of functional modules of a power supply development software architecture provided in an embodiment of the present application;
[0019] Figure 3 A schematic diagram of a sampling module of a power development software architecture provided in an embodiment of the present application;
[0020] Figure 4 A schematic diagram of an initialization module of a power development software architecture provided in an embodiment of the present application;
[0021] Figure 5 A schematic diagram of a power control module of a power development software architecture provided in an embodiment of the present application;
[0022] Figure 6A schematic diagram of the structure of an electronic device provided in an embodiment of the present application;
[0023] Figure 7 A schematic diagram of the structure of a non-transitory computer-readable storage medium provided in an embodiment of the present application. DETAILED DESCRIPTION
[0024] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention. In addition, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.
[0025] The terms "first", "second", "third", etc. in the specification and claims of this application and the above-mentioned drawings are used to distinguish different objects, rather than to describe a specific order. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally includes steps or units that are not listed, or optionally includes other steps or units inherent to these processes, methods, products or devices.
[0026] like Figure 1 The figure shows a functional execution diagram of the power supply development software architecture, wherein the application layer is used to obtain and parse the business function instructions in the power supply development process; the middle layer is provided with a business operation interface corresponding to each of the business function instructions, and the business operation interface is used to provide the application layer with a function function that can be directly called according to the business function instruction, and the application layer implements the corresponding business function according to the combination of the function functions; the driver layer registers the device driver and bus driver corresponding to the business operation interface, and encapsulates the corresponding implementation method according to the device driver and the bus driver, so that the middle layer can call the implementation method when the application layer calls the business operation interface.
[0027] Specifically, for example, the upper computer JC_Power issues a business function instruction, and the application layer Com_manager controls the process cmd_process through the jcemif protocol and the Json protocol to parse the business function instruction, and power_sturct introduces the board data structure so that the process can call the operation interface defined in the middle layer according to the parsed business function instruction.
[0028] In one embodiment, the middle layer implements the service operation interface through a hardware port configuration file board_config, and the hardware port configuration file includes board information, devices used by the service function, required processor resources and the implementation method.
[0029] In one embodiment, the application layer, the middle layer and the driver layer are respectively divided into a top and a bottom. The top provides a registration function and a query linked list function to the bottom of the same layer. The bottom hangs the implementation method into a linked list according to the registration function and waits for the top to query and call.
[0030] In one embodiment, the top of the driver layer includes an encapsulation module ×××_Warp and an encapsulation management module ×××_Warp_manager. The encapsulation module is used to query the linked list according to the board information to find the corresponding device driver and the bus driver and encapsulate the corresponding implementation method for the application layer to call. The encapsulation management module provides the registration function, the query linked list function and the data structure of the implementation method.
[0031] In one embodiment, the middle layer is provided with a platform device driver dev_drv_platform, and the platform device driver dev_drv_platform integrates the bus driver and the device driver by constructing a virtual bus for the middle layer to call.
[0032] like Figure 2 The figure shows the overall block diagram of the power supply software architecture. Different bus drivers bus_drv and device drivers dev_drv are registered in the driver layer to meet the middle layer call. The bus driver is determined by the control scheme, and the device driver is determined by the configured hardware. Several implementation methods are fixed in the middle layer, and the device driver platform dev_drv_platform.c distinguishes different implementation methods according to different control methods bus_type (arm / fpga). Different implementation methods correspond to different driver layer implementations, and the expansion of implementation methods is also supported in the later stage. In the application layer, the required functional interface is called according to the business process.
[0033] The present application is described in detail below with reference to specific embodiments.
[0034] like Figure 3 As shown in the figure, for AD sampling, from top to bottom, the business function to be implemented by the application layer is power sampling. Power sampling requires the functions of voltage acquisition and current acquisition, and then the collected data is filtered, which is completed by the middle layer. In the driver layer, the bus driver and device driver are registered in the linked list, and the corresponding driver is found in the linked list according to the implementation type in adc_wrap.c, and it is encapsulated for the middle layer to call.
[0035] like Figure 4 As shown, the initialization adopts a registration method in memory, so that it can be called in the files of each layer instead of in the main function. The main function only needs to call do_initcalls, which will initialize the driver layer, the middle layer and the application in sequence. In addition, the initialization process with extremely high requirements on the execution order can be called explicitly.
[0036] like Figure 5 As shown in the figure, the application layer of power control includes: configuration parameters and power output control. These services require DAC output and IO control, so the middle layer includes DAC module and IO module. The driver layer includes DAC bus and device driver, IO bus and device driver. All drivers are registered into the linked list according to the implementation method type, and the corresponding driver is found in xxx_wrap.c to encapsulate the functions of DAC and IO modules.
[0037] In summary, the first embodiment of the present application divides the power supply development software architecture into an application layer, an intermediate layer and a driver layer. The application layer obtains and parses the business function instructions in the power supply development process. The intermediate layer is provided with a business operation interface corresponding to each business function instruction, which is used to provide the application layer with a function function that can be directly called according to the business function instruction, and realize the corresponding business function through a combination of function functions. The driver layer registers device drivers and bus drivers corresponding to the business operation interface, and encapsulates them into corresponding implementation methods for the intermediate layer to call, thereby realizing the separation of operation and device. It is more convenient to transplant / add / delete / match different devices under the same module without introducing hidden problems, and there is a unified input and output format, which can quickly locate exceptions during debugging. In addition, after layering, the code can be uniformly managed with higher efficiency, and the expansion of new functions is simpler and controllable.
[0038] In addition, a second embodiment of the present invention proposes a power supply development method, including: dividing the power supply development software architecture into an application layer, an intermediate layer and a driver layer; the application layer is used to obtain and parse business function instructions in the power supply development process; the intermediate layer is provided with a business operation interface corresponding to each of the business function instructions, and the business operation interface is used to provide the application layer with a function function that can be directly called according to the business function instruction, and the application layer implements the corresponding business function according to the combination of the function functions; the driver layer registers a device driver and a bus driver corresponding to the business operation interface, and encapsulates the corresponding implementation method according to the device driver and the bus driver, so that the intermediate layer can call the implementation method when the application layer calls the business operation interface.
[0039] In one embodiment, the power supply development method also includes: dividing the application layer, the middle layer and the driver layer into top and bottom layers respectively, the top layer provides a registration function and a query linked list function to the bottom layer of the same layer, and the bottom layer hangs the implementation method into a linked list according to the registration function, waiting for the top layer to query and call.
[0040] It is worth mentioning that the power development method disclosed in the second embodiment of the present invention is applicable to the power development software architecture described in the first embodiment. The specific structure of the power development software architecture and the functions implemented are as described in the first embodiment, so they are not described in detail here. Optionally, the various modules in the first embodiment and the above-mentioned other operations or functions are respectively for implementing the power development method described in the second embodiment, and the beneficial effects of this embodiment are the same as the beneficial effects of the power development software architecture described in the first embodiment, and for the sake of brevity, they are not repeated here.
[0041] The third embodiment of the present invention further proposes an electronic device 30, for example, comprising: at least one processing unit 31, and at least one storage unit 32, wherein the storage unit 32 stores a computer program, and when the computer program is executed by the processing unit 31, the processing unit 31 executes the method described in the first embodiment, and the beneficial effects of the electronic device 30 provided in this embodiment are the same as the beneficial effects of the power supply development method provided in the second embodiment.
[0042] The fourth embodiment of the present invention also provides a non-transitory computer-readable storage medium 40 on which a computer program is stored. When the program is executed by a processor, the steps of the above method are implemented. The beneficial effects of the non-transitory computer-readable storage medium 40 provided in this embodiment are the same as the beneficial effects of the power supply development method provided in the second embodiment.
[0043] In addition, it can be understood that the aforementioned embodiments are merely illustrative descriptions of the present application. Under the premise that the technical features do not conflict, the structures do not contradict, and the purpose of the invention of the present application is not violated, the technical solutions of the various embodiments can be arbitrarily combined and used in combination.
[0044] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and / or methods can be implemented in other ways. For example, the device embodiments described above are merely schematic, and the division of the units / modules is merely a logical function division. There may be other division methods in actual implementation, such as multiple units or modules can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.
[0045] The units / modules described as separate components may or may not be physically separated, and the components shown as units / modules may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units / modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
[0046] In addition, each functional unit / module in each embodiment of the present application may be integrated into one processing unit / module, or each unit / module may exist physically separately, or two or more units / modules may be integrated into one unit / module. The above-mentioned integrated unit / module may be implemented in the form of hardware or in the form of hardware plus software functional units / modules.
[0047] The above-mentioned integrated unit / module implemented in the form of a software functional unit / module can be stored in a computer-readable storage medium. The above-mentioned software functional unit is stored in a storage medium, including a number of instructions for enabling one or more processors of a computer device (which can be a personal computer, a server, or a network device, etc.) to perform some steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory, referred to as ROM), random access memory (Random Access Memory, referred to as RAM), disk or optical disk and other media that can store program codes.
[0048] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.
Claims
1. A power development software architecture, characterized in that: include: The application layer is used to obtain and parse business function instructions during the power supply development process; The middle layer is provided with a business operation interface corresponding to each of the business function instructions, and the business operation interface is used to provide the application layer with a function function that can be directly called according to the business function instruction, and the application layer implements the corresponding business function according to the combination of the function functions; The driver layer registers the device driver and bus driver corresponding to the business operation interface, and encapsulates the corresponding implementation method according to the device driver and the bus driver, so as to allow the middle layer to call the implementation method when the application layer calls the business operation interface.
2. The power development software architecture according to claim 1, characterized in that: The application layer, the middle layer and the driver layer are respectively divided into a top and a bottom. The top provides a registration function and a query linked list function to the bottom of the same layer. The bottom hangs the implementation method into a linked list according to the registration function and waits for the top to query and call.
3. The power development software architecture according to claim 2, characterized in that: The top of the driver layer includes a packaging module and a packaging management module. The packaging module is used to query the linked list according to the board information to find the corresponding device driver and the bus driver and encapsulate the corresponding implementation method for the application layer to call. The packaging management module provides the registration function, the query linked list function and the data structure of the implementation method.
4. The power development software architecture according to claim 1, characterized in that: The middle layer implements the service operation interface through a hardware port configuration file, and the hardware port configuration file includes board information, devices used by the service function, required processor resources and the implementation method.
5. The power development software architecture according to claim 1, characterized in that: The intermediate layer is provided with a platform device driver, and the platform device driver integrates the bus driver and the device driver by constructing a virtual bus for the intermediate layer to call.
6. The power development software architecture according to claim 1, characterized in that: The initialization programs of the application layer, the intermediate layer and the driver layer are respectively registered in corresponding memories and are called by the main function when executing the initialization process, so as to initialize the driver layer, the intermediate layer and the application layer in sequence.
7. A power supply development method, characterized in that: A power supply development software architecture applicable to any one of claims 1 to 6, comprising: Dividing the power development software architecture into an application layer, an intermediate layer and a driver layer; The application layer is used to obtain and parse business function instructions in the power supply development process; The intermediate layer is provided with a business operation interface corresponding to each of the business function instructions, and the business operation interface is used to provide the application layer with a function function that can be directly called according to the business function instruction, and the application layer implements the corresponding business function according to the combination of the function functions; The driver layer registers the device driver and bus driver corresponding to the business operation interface, and encapsulates the corresponding implementation method according to the device driver and the bus driver, so that the middle layer can call the implementation method when the application layer calls the business operation interface.
8. The power development method according to claim 7, characterized in that: Also includes: The application layer, the middle layer and the driver layer are divided into top and bottom layers respectively. The top layer provides a registration function and a query linked list function to the bottom layer of the same layer. The bottom layer hangs the implementation method into a linked list according to the registration function and waits for the top layer to query and call.
9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the steps of the method according to any one of claims 7 to 8 are implemented.
10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 7 to 8 are implemented.