Hardware layer design method based on embedded operating system

Abstract

The present application relates to the technical field of hardware layer design, and particularly relates to a hardware layer design method based on an embedded operating system, comprising the following steps: analyzing application program interfaces stored in a current hardware layer to obtain application program interfaces stored in the hardware layer configured by a current operating system; receiving a running task of the current operating system, and analyzing application program interfaces required by the running task to be configured; searching for the application program interfaces required by the running task to be configured in the application program interfaces stored in the hardware layer, and feeding back the searching process of the application program interfaces to a system user in real time; the present application can bring an intelligent hardware layer design method to the current embedded operating system, and in the step execution process of the method, the hardware layer intelligent design of the embedded operating system is realized by analyzing the application program interfaces existing in the hardware layer in real time.

Description

Technical Field

[0001] This invention relates to the field of hardware layer design technology, and more specifically to a hardware layer design method based on an embedded operating system. Background Technology

[0002] Embedded systems are divided into four layers: hardware layer, driver layer, operating system layer, and application layer.

[0003] The hardware layer is the foundation of the entire embedded system. If you are familiar with microcontrollers and interfaces, and can program in C and assembly languages, starting from the hardware layer of an embedded system is relatively easy. The hardware layer is also the foundation of the driver layer. An excellent driver engineer should be able to understand hardware circuit diagrams and complete the logic design of CPLDs independently, while also being quite familiar with the operating system kernel and its scheduling. However, while the hardware platform is the foundation, added value comes from software.

[0004] However, after the current embedded operating system is configured, the hardware layer debugging work is often done manually. This process is cumbersome, prone to errors, and consumes a lot of manual labor, making the hardware layer design and debugging of embedded operating systems time-consuming and costly. Summary of the Invention

[0005] Technical problems to be solved

[0006] In view of the above-mentioned shortcomings of the existing technology, the present invention provides a hardware layer design method based on an embedded operating system, which solves the technical problems mentioned in the background.

[0007] Technical solution

[0008] To achieve the above objectives, the present invention provides the following technical solution:

[0009] The hardware layer design method based on an embedded operating system includes the following steps:

[0010] Step 1: Analyze the application programming interfaces (APIs) stored in the current hardware layer to obtain the APIs stored in the hardware layer that are currently configured in the operating system.

[0011] Step 2: Receive the currently running operating system task and analyze the application programming interfaces (APIs) required for the task.

[0012] Step 3: Search for the application programming interfaces (APIs) required for the analyzed running tasks in the application programming interfaces (APIs) stored in the hardware layer, and provide real-time feedback to the system user on the API search process.

[0013] Step 4: Build a cloud database, monitor the application interface configuration frequency stored in the hardware layer, and send the application interface to the cloud database according to the application interface configuration frequency.

[0014] Step 5: Obtain the operating system running task corresponding to the currently configured application interface, and match the operating system running task with its configured application interface;

[0015] Step 6: Capture the features of the last running task in the operating system. Each time the operating system runs a task, extract the features of the current running task and identify the features that are the same as those of the current running task from the captured running task features.

[0016] Furthermore, in step 1, the number of application interfaces configured in the operating system is less than the number of application interfaces stored in the hardware layer when the application interface is manually loaded or unloaded by the user on the system side.

[0017] Furthermore, when step 2 is executed, if it is found that the application programming interface (API) required for the running task does not exist in the application programming interface stored in the hardware layer, the operating system is controlled to stop executing the current running task and feedback is sent to the system user that the application programming interface does not exist in the hardware layer.

[0018] Furthermore, step 2 includes sub-modules, including:

[0019] Step 21: Build a data interaction platform. The operating system accesses the data interaction platform through a wireless network and provides real-time feedback on the running tasks and the corresponding application interface configurations of the running tasks.

[0020] Step 22: The data interaction platform records the running tasks and the configuration data of the corresponding application interfaces of the running tasks, and sets the data storage period of the data interaction platform. The data interaction platform updates the data stored in the data interaction platform according to the data storage period.

[0021] In step 22, the data storage period of the data interaction platform is set by the system user, and the initial data storage period of the data interaction voucher is set to one week.

[0022] Furthermore, during the execution of step 3, the application programming interfaces (APIs) stored in the hardware layer are simultaneously recorded. When the number of APIs stored in the hardware layer that are searched is less than half of the total number of APIs that need to be searched in the hardware layer, step 3 stops executing, and the system user resets and manually uploads the APIs stored in the hardware layer.

[0023] Furthermore, the cloud database constructed in step 4 monitors the application interface configuration application frequency stored in the hardware layer in real time, and stores the application interfaces with the lowest frequency of the application interface configuration application frequency in the cloud database by the system user manually setting them.

[0024] In this process, the cloud database is connected to the hardware layer via a wireless network. Step 4 is set with a refresh cycle. After each refresh cycle, the application frequency of each application interface is re-measured. The cloud database stores only the 10% of application interfaces with the lowest application frequency among all application interfaces.

[0025] Furthermore, step 4 has sub-steps, including the following steps:

[0026] Step 41: After the refresh cycle set in step 4 ends, delete and upload the application interfaces stored in the cloud database according to the metering results matching the application configuration of each application interface.

[0027] Step 42: Obtain the operation data of deleting and uploading the application interface stored in the cloud database in Step 41, and synchronously feed back the obtained operation data to the system user after each refresh cycle.

[0028] Furthermore, the data content that is synchronously fed back to the system user in step 42 is backed up and stored in the cloud database built in step 4 during the feedback process.

[0029] Furthermore, steps 5 and 6 are triggered each time the operating system finishes configuring the application interface.

[0030] Furthermore, when step 6 identifies a feature identical to that of the currently running task, it applies the application programming interface (API) of the operating system running task configuration that matches the feature; when step 6 identifies no feature identical to that of the currently running task, it jumps to step 3 for execution.

[0031] The characteristics of an operating system running task include: application interface attributes, the number of application interfaces required for the running task, and the application interface parameters required for the running task.

[0032] Beneficial effects

[0033] Compared with known public technologies, the technical solution provided by this invention has the following beneficial effects:

[0034] 1. This invention provides a hardware layer design method based on an embedded operating system. The steps of this method bring an intelligent hardware layer design approach to current embedded operating systems. During the execution of these steps, the method primarily achieves intelligent hardware layer design by real-time analysis of the application programming interfaces (APIs) within the hardware layer. Furthermore, the method records and matches intelligent design data during the design process, ensuring that when the operating system performs hardware layer design in the same application scenario, the method can complete the hardware layer design configuration more quickly and efficiently. This provides the method with a certain degree of learning capability during the execution of its steps, thereby maximizing the user experience.

[0035] 2. In the process of executing its steps, the method of the present invention can also capture the characteristics of the operating system running task. By capturing the characteristics of the running task, the method can help to match the application programming interface required by the operating system running task more quickly and accurately, saving time for the operating system running task when configuring the hardware layer application programming interface, and making the configuration process more efficient. Attached Figure Description

[0036] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.

[0037] Figure 1 This is a flowchart illustrating the hardware layer design method based on an embedded operating system. Detailed Implementation

[0038] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0039] The present invention will be further described below with reference to embodiments.

[0040] Example 1

[0041] The hardware layer design method based on the embedded operating system in this embodiment, such as... Figure 1 As shown, it includes the following steps:

[0042] Step 1: Analyze the application programming interfaces (APIs) stored in the current hardware layer to obtain the APIs stored in the hardware layer that are currently configured in the operating system.

[0043] Step 2: Receive the currently running operating system task and analyze the application programming interfaces (APIs) required for the task.

[0044] Step 3: Search for the application programming interfaces (APIs) required for the analyzed running tasks in the application programming interfaces (APIs) stored in the hardware layer, and provide real-time feedback to the system user on the API search process.

[0045] Step 4: Build a cloud database, monitor the application interface configuration frequency stored in the hardware layer, and send the application interface to the cloud database according to the application interface configuration frequency.

[0046] Step 5: Obtain the operating system running task corresponding to the currently configured application interface, and match the operating system running task with its configured application interface;

[0047] Step 6: Capture the features of the last running task in the operating system. Each time the operating system runs a task, extract the features of the current running task and identify the features that are the same as those of the current running task from the captured running task features.

[0048] Example 2

[0049] At the implementation level, based on Example 1, this example refers to... Figure 1 The hardware layer design method based on an embedded operating system in Example 1 is further explained in detail below:

[0050] In step 1, the hardware layer stores the application interfaces, but when the application interfaces are manually loaded or unloaded by the user on the system side, the number of application interfaces configured in the operating system is less than the number of application interfaces stored in the hardware layer.

[0051] like Figure 1 As shown, when step 2 is executed, if it is found that the application programming interface (API) required for the running task does not exist in the application programming interface stored in the hardware layer, the operating system is controlled to stop executing the current running task and feedback is sent to the system user that the application programming interface does not exist in the hardware layer.

[0052] like Figure 1 As shown, step 2 has sub-modules, including:

[0053] Step 21: Build a data interaction platform. The operating system accesses the data interaction platform through a wireless network and provides real-time feedback on the running tasks and the corresponding application interface configurations of the running tasks.

[0054] Step 22: The data interaction platform records the running tasks and the configuration data of the corresponding application interfaces of the running tasks, and sets the data storage period of the data interaction platform. The data interaction platform updates the data stored in the data interaction platform according to the data storage period.

[0055] In step 22, the data storage period of the data interaction platform is set by the system user, and the initial data storage period of the data interaction voucher is set to one week.

[0056] like Figure 1 As shown, during the execution of step 3, the application programming interfaces (APIs) stored in the hardware layer are simultaneously recorded. When the number of APIs stored in the hardware layer that are searched is less than half of the total number of APIs that need to be searched in the hardware layer, step 3 stops executing, and the system user resets and manually uploads the APIs stored in the hardware layer.

[0057] like Figure 1 As shown, the cloud database built in step 4 monitors the application interface configuration application frequency stored in the hardware layer in real time, and stores the application interfaces with the lowest frequency in the application interface configuration application frequency that are manually set by the system user as the storage target in the cloud database.

[0058] The cloud database is connected to the hardware layer via a wireless network. Step 4 sets a refresh cycle. After each refresh cycle, the application frequency of each application interface is re-measured. The cloud database stores only the 10% of application interfaces with the lowest configured application frequency.

[0059] Example 3

[0060] At the implementation level, based on Example 1, this example refers to... Figure 1 The hardware layer design method based on an embedded operating system in Example 1 is further explained in detail below:

[0061] Step 4 has sub-steps, including the following steps:

[0062] Step 41: After the refresh cycle set in step 4 ends, delete and upload the application interfaces stored in the cloud database according to the metering results matching the application configuration of each application interface.

[0063] Step 42: Obtain the operation data of deleting and uploading the application interface stored in the cloud database in Step 41, and synchronously feed back the obtained operation data to the system user after each refresh cycle.

[0064] like Figure 1 As shown, the data content that is synchronously fed back to the system user in step 42 is backed up and stored in the cloud database built in step 4 during the feedback process.

[0065] like Figure 1 As shown, steps 5 and 6 are triggered each time the operating system finishes configuring the application interface.

[0066] like Figure 1 As shown, in step 6, when a feature identical to that of the currently running task is identified, the application programming interface of the operating system running task configuration with the same feature is applied; in step 6, when no feature identical to that of the currently running task is identified, the process jumps to step 3.

[0067] The characteristics of an operating system running task include: application interface attributes, the number of application interfaces required for the running task, and the application interface parameters required for the running task.

[0068] In summary, the method described in the above embodiments provides an intelligent hardware layer design approach for current embedded operating systems. During the execution of this method, it primarily achieves intelligent hardware layer design for the embedded operating system by real-time analysis of the application programming interfaces (APIs) existing in the hardware layer. During the design process, it also records and further matches the intelligent design data of the hardware layer, ensuring that when the operating system runs in subsequent hardware layer design scenarios with similar operational tasks, this method can complete the hardware layer design configuration more quickly and efficiently. This provides the method with a certain degree of learning capability during the execution process, thereby maximizing the user experience. Furthermore, during the execution of the method, it can capture the characteristics of the operating system's operational tasks. By capturing these characteristics, the method can more quickly and accurately match the APIs required for the operating system's operational tasks, saving time and making the configuration process more efficient.

[0069] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions will not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A hardware layer design method based on an embedded operating system, characterized in that, Includes the following steps: Step 1: Analyze the application programming interfaces (APIs) stored in the current hardware layer to obtain the APIs stored in the hardware layer that are currently configured in the operating system. Step 2: Receive the currently running operating system task and analyze the application programming interfaces (APIs) required for the task. Step 3: Search for the application programming interfaces (APIs) required for the analyzed running tasks in the application programming interfaces (APIs) stored in the hardware layer, and provide real-time feedback to the system user on the API search process. Step 4: Build a cloud database, monitor the application interface configuration frequency stored in the hardware layer, and send the application interface to the cloud database according to the application interface configuration frequency. Step 5: Obtain the operating system running task corresponding to the currently configured application interface, and match the operating system running task with its configured application interface; Step 6: Capture the features of the last running task in the operating system. Each time the operating system runs a task, extract the features of the current running task and identify the features that are the same as those of the current running task from the captured running task features. The cloud database constructed in step 4 monitors the application interface configuration application frequency stored in the hardware layer in real time, and stores the application interfaces with the lowest frequency of the application interface configuration application frequency in the cloud database by the system user manually setting them. In this process, the cloud database is connected to the hardware layer via a wireless network. Step 4 is set with a refresh cycle. After each refresh cycle, the application frequency of each application interface is remeasured. The cloud database stores only the 10% of application interfaces with the lowest application frequency among all application interfaces.

2. The hardware layer design method based on an embedded operating system according to claim 1, characterized in that, In step 1, the number of application interfaces stored in the hardware layer is less than the number of application interfaces stored in the hardware layer when the application interface is manually loaded or unloaded by the user on the system side.

3. The hardware layer design method based on an embedded operating system according to claim 1, characterized in that, When step 2 is executed, if it is found that the application programming interface (API) required for the running task does not exist in the application programming interface stored in the hardware layer, the operating system is controlled to stop executing the current running task and feedback is sent to the user on the system side that the application programming interface does not exist in the hardware layer.

4. The hardware layer design method based on an embedded operating system according to claim 1, characterized in that, Step 2 has sub-modules at the lower level, including: Step 21: Build a data interaction platform. The operating system accesses the data interaction platform through a wireless network and provides real-time feedback on the running tasks and the corresponding application interface configurations of the running tasks. Step 22: The data interaction platform records the running tasks and the configuration data of the corresponding application interfaces of the running tasks, and sets the data storage period of the data interaction platform. The data interaction platform updates the data stored in the data interaction platform according to the data storage period. In step 22, the data storage period of the data interaction platform is set by the system user, and the initial data storage period of the data interaction voucher is set to one week.

5. The hardware layer design method based on an embedded operating system according to claim 1, characterized in that, When step 3 is executed, the application programming interfaces (APIs) stored in the hardware layer are searched simultaneously. When the number of APIs searched in the hardware layer is less than half of the total number of APIs that need to be searched in the hardware layer, step 3 stops executing, and the system user resets and manually uploads the APIs stored in the hardware layer.

6. The hardware layer design method based on an embedded operating system according to claim 1, characterized in that, Step 4 has sub-steps, including the following steps: Step 41: After the refresh cycle set in step 4 ends, delete and upload the application interfaces stored in the cloud database according to the metering results matching the application configuration of each application interface. Step 42: Obtain the operation data of deleting and uploading the application interface stored in the cloud database in Step 41, and synchronously feed back the obtained operation data to the system user after each refresh cycle.

7. The hardware layer design method based on an embedded operating system according to claim 6, characterized in that, In step 42, the data content that is synchronously fed back to the system user is backed up and stored in the cloud database built in step 4.

8. The hardware layer design method based on an embedded operating system according to claim 1, characterized in that, Steps 5 and 6 are triggered each time the operating system finishes configuring the application interface.

9. The hardware layer design method based on an embedded operating system according to claim 1, characterized in that, When step 6 identifies a feature identical to that of the currently running task, it applies the application programming interface configured by the operating system running task with the same feature. When step 6 identifies no feature identical to that of the currently running task, it jumps to step 3 for execution. The characteristics of an operating system running task include: application interface attributes, the number of application interfaces required for the running task, and the application interface parameters required for the running task.

Images