Function execution proportion result generation method and device based on embedded system, equipment and medium
By generating and comparing basic databases and sampling databases in an embedded system, combined with preset neural network optimization, real-time monitoring and analysis of function execution proportion is achieved, performance optimization difficulties on different hardware platforms are solved, and system performance optimization efficiency is improved.
Patent Information
- Application Number
- CN202510535669.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-04-27
- Publication Date
- 2025-05-30
- Estimated Expiration
- 2045-04-27
AI Technical Summary
The existing technology is difficult to realize efficient and low-cost function execution proportion real-time monitoring and analysis on different hardware platforms, resulting in difficulty in optimizing system performance.
By obtaining the original files and sampling files of the embedded system, data cleaning and analysis are performed, the basic database and sampling database are generated, the identification information in the two is compared to calculate the proportion of function execution, and the preset neural network is used to optimize the sampling database to dynamically update the proportion of execution.
It realizes efficient and real-time acquisition of function execution proportion in embedded systems, identify performance bottlenecks and guides optimization directions, and improves system performance optimization efficiency.
Smart Images

Figure CN120066921A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of Internet of Things embedded systems, and in particular, to a method, device, equipment and medium for generating function execution ratio results based on an embedded system. Background Art
[0002] With the wide application of embedded systems in fields such as the Internet of Things, industrial automation, and intelligent devices, the optimization of system performance has become a key factor in enhancing product competitiveness. Embedded systems usually run on hardware platforms with limited resources and need to achieve efficient operation under limited processor performance, memory capacity, and power consumption conditions. In a real-time operating system environment, the system contains a large number of mutually called functions, and the execution of these functions directly affects the response speed and overall performance of the system.
[0003] To achieve efficient system optimization, a method capable of real-time monitoring and analyzing function execution ratios is required to identify performance bottlenecks from the system level and guide the optimization direction. However, the current acquisition methods are difficult to provide comprehensive performance analysis from the system level, and performance analysis tools require specific hardware support (such as performance counters), which makes them difficult to be universal on different hardware platforms, increasing the development cost and transplantation difficulty. Therefore, a more efficient and low-cost method is needed to obtain and track function execution ratio results in real time. Summary of the Invention
[0004] The main purpose of this application is to provide a method, device, equipment and medium for generating function execution ratio results based on an embedded system, aiming to solve the technical problem of how to obtain function execution ratios in real time and efficiently.
[0005] To achieve the above object, this application proposes a method for generating function execution ratio results based on an embedded system, and the method includes: Obtain the original file of the embedded system and receive the sampling file transmitted by the lower computer; Perform data cleaning and parsing on the original file to obtain a basic database; Generate a sampling database according to the sampling file; Compare the identification information in the sampling database with the basic information in the basic database to obtain an execution ratio, where the execution ratio is the ratio of the sampling times of the target function in the total sampling times; Combine the execution ratio with the basic information to generate an execution ratio result, where the execution ratio result includes the function name, sampling times, and running ratio; After the step of comparing the identification information in the sampling database with the basic information in the basic database to obtain an execution ratio, it includes: Receive a new sampling file output by the lower computer; Input the new sampling file into a preset neural network to obtain an updated sampling database; Based on the updated sampling database, perform a step of comparing the identification information in the sampling database with the basic information in the basic database to obtain an execution ratio.
[0006] In one embodiment, the step of performing data cleaning and parsing on the original file to obtain a basic database includes: Obtain a function address mapping table for the original file; Extract information from the function address mapping table to obtain function basic information, where the function basic information includes a function name, a start address, and an end address; Construct a structured data table based on the function basic information; Perform data cleaning processing on the structured data table to generate a first database; Store the first database as a basic function library.
[0007] In one embodiment, the step of generating a sampling database according to the sampling file includes: Determine an original pointer sampling sequence based on the sampling file; Perform address alignment processing on the original pointer sampling sequence to obtain an address range corresponding to the original pointer sampling sequence; Perform statistics based on the address range to obtain a corresponding occurrence frequency and a frequency distribution table; Establish a second database according to the occurrence frequency and the frequency distribution table, where the second database includes an address value, an occurrence count, and a timestamp; Perform a rejection process on the second database to obtain a sampling database.
[0008] In one embodiment, the step of performing a rejection process on the second database to obtain a sampling database includes: Obtain a running timestamp and a basic database range; Reject abnormal data in the second database whose address value exceeds the basic database range to obtain an updated second database; Obtain an updated address value and the occurrence count of each address value in a preset sampling period according to the updated second database; Generate a sampling database based on the updated address value, the occurrence count of each address value in a preset sampling period, and the corresponding running timestamp.
[0009] In one embodiment, the step of comparing the identification information in the sampling database with the basic information in the basic database to obtain the execution ratio includes: Extract pointer information at multiple sampling moments from the sampling database and obtain the total number of samplings; Obtain multiple corresponding function identification information according to the multiple pointer information; Search for corresponding basic information in the basic database according to the multiple function identification information to obtain the target function sampling times; Determine the execution ratio of the target function based on the target function sampling times and the total number of samplings.
[0010] In one embodiment, the method is applied to a lower computer, and the method includes: Collect program counter data during the operation of the embedded system through a timer interrupt mechanism; Convert the program counter data to obtain pointer information; Store the pointer information in a collection information table; When the collection information table meets the preset capacity, output the collection information table as a sampling file and send it to the upper computer to execute the method described above.
[0011] In one embodiment, after the step of comparing the identification information in the sampling database with the basic information in the basic database to obtain the execution ratio, it further includes: The step of collecting program counter data during the operation of the embedded system through a timer interrupt mechanism includes: Set a timer through a timer interrupt mechanism; Configure the trigger period of the timer as a preset sampling interval; Sample the program counter at the preset sampling interval and record the program counter data; Write the program counter data into a circular buffer to obtain the data volume of the circular buffer; Detect the comparison between the data volume of the circular buffer and a preset capacity threshold to obtain a detection result; When the detection result is that the data volume of the circular buffer exceeds the preset capacity threshold, output the program counter data.
[0012] In addition, to achieve the above object, the present application also proposes a function execution ratio result generation device based on an embedded system. The function execution ratio result generation device based on an embedded system includes: An acquisition module for acquiring the original file of the embedded system and receiving the sampling file transmitted from the lower computer; A processing module, configured to perform data cleaning and parsing on the original file to obtain a basic database; The processing module is further configured to generate a sampling database according to the sampling file; A comparison module, configured to compare the identification information in the sampling database with the basic information in the basic database to obtain an execution ratio, where the execution ratio is the ratio of the sampling times of the target function in the total sampling times; A result module, configured to combine the execution ratio with the basic information to generate an execution ratio result, where the execution ratio result includes a function name, a sampling times, and a running ratio; A data update module, configured to receive a new sampling file output by a lower computer; input the new sampling file into a preset neural network to obtain an updated sampling database; and perform the step of comparing the identification information in the sampling database with the basic information in the basic database based on the updated sampling database to obtain an execution ratio.
[0013] In addition, to achieve the above object, the present application further provides a medium, where the medium is a computer-readable medium, and a computer program is stored on the medium. When the computer program is executed by a processor, the steps of the method for generating a function execution ratio result based on an embedded system as described above are implemented.
[0014] In addition, to achieve the above object, the present application further provides a computer program product, where the computer program product includes a computer program. When the computer program is executed by a processor, the steps of the method for generating a function execution ratio result based on an embedded system as described above are implemented.
[0015] The present application obtains an original file and a sampling file from an embedded system, and generates a basic database and a sampling database through data cleaning and parsing. By comparing the identification information of the two, the function execution ratio is obtained, and a result report including the function name, the sampling times, and the running ratio is generated. Further, a new sampling file is received and the sampling database is optimized and updated through a preset neural network, and the execution ratio is dynamically updated by comparing again. By parsing the MAP file and the sampling PC pointer, a basic database and a sampling database are formed, the function execution ratio is obtained by comparing the two, the data processing efficiency and accuracy are improved by using a neural network, and the running efficiency of the embedded system is evaluated based on the positioning of high-load functions, thereby improving the performance optimization efficiency of the embedded system. Description of the Drawings
[0016] To more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, for those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.
[0017] Figure 1 This is a schematic flowchart of the first embodiment of the method for generating the function execution ratio result based on an embedded system in this application; Figure 2 This is a schematic flowchart of the second embodiment of the method for generating the function execution ratio result based on an embedded system in this application; Figure 3 This is a schematic flowchart of the third embodiment of the method for generating the function execution ratio result based on an embedded system in this application; Figure 4 This is a schematic flowchart of the fourth embodiment of the method for generating the function execution ratio result based on an embedded system in this application; Figure 5 This is a schematic module structure diagram of the device for generating the function execution ratio result based on an embedded system in the embodiment of this application; Figure 6 This is a schematic device structure diagram of the hardware operating environment involved in the method for generating the function execution ratio result based on an embedded system in the embodiment of this application.
[0018] The implementation, functional features, and advantages of the purpose of this application will be further described with reference to the embodiments and the accompanying drawings. Detailed implementation manners
[0019] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of this application and are not used to limit this application.
[0020] For a better understanding of the technical solutions of this application, the following will be described in detail in combination with the accompanying drawings of the specification and the specific implementation manners.
[0021] The main solution of the embodiment of this application is: obtaining the original file of the embedded system and receiving the sampling file transmitted by the lower computer; performing data cleaning and parsing on the original file to obtain a basic database; generating a sampling database according to the sampling file; comparing the identification information in the sampling database with the basic information in the basic database to obtain the execution ratio, where the execution ratio is the ratio of the sampling times of the target function to the total sampling times; combining the execution ratio with the basic information to generate an execution ratio result, and the execution ratio result includes the function name, sampling times, and running ratio. After the step of comparing the identification information in the sampling database with the basic information in the basic database to obtain the execution ratio, it includes: receiving a new sampling file output by the lower computer; inputting the new sampling file into a preset neural network to obtain an updated sampling database; and performing the step of comparing the identification information in the sampling database with the basic information in the basic database to obtain the execution ratio based on the updated sampling database.
[0022] Based on this, an embodiment of the present application provides a method for generating function execution ratio results based on an embedded system, which is applied to a host computer. The host computer is usually a personal computer or a server. Refer to Figure 1 , Figure 1 which is a schematic flowchart of the first embodiment of the method for generating function execution ratio results based on an embedded system in the present application.
[0023] In this embodiment, the method for generating function execution ratio results based on an embedded system includes steps S10 to S40: Step S10, obtain the original file of the embedded system and receive the sampling file transmitted by the lower computer.
[0024] It should be noted that in order to track the function execution ratio of the embedded system, two key files need to be obtained first: the original file and the sampling file. In this embodiment, the original file refers to the MAP file generated by the GCC compiler, which contains information such as all functions in the system and their corresponding address ranges. The process of obtaining the MAP file is relatively straightforward, and only appropriate parameters need to be added in the compilation options to make GCC output this file. On the other hand, the sampling file is obtained by collecting the current state of the system during runtime, especially the position information of the program counter (PC) pointer. This step depends on a timer that generates an interrupt at a set time interval to record the position of the currently executing instruction. This process is completed by the lower computer, and the specific implementation strategy includes adding an interface to save the PC pointer, starting the timer for timed sampling, aggregating the collected information into a list, and outputting this information as a log through a low-priority thread in a timely manner.
[0025] Step S20, perform data cleaning and parsing on the original file to obtain a basic database.
[0026] It should be noted that obtaining the MAP file is relatively straightforward, and only appropriate parameters need to be added during compilation to make GCC output this file. However, the MAP file contains a large amount of information, such as symbol tables, memory mappings, and address ranges of each function, which are mixed together. Therefore, data cleaning and parsing steps are required.
[0027] Furthermore, step S20 also includes: obtaining a function address mapping table from the original file. Specifically, it is necessary to obtain the function address mapping table from the original file generated during the compilation process of the embedded system. Usually, this process can be achieved through compiler options to ensure that the output is a MAP file containing all necessary information. This file details the names of each function in the system and their corresponding memory address ranges. Then, information extraction is performed on the function address mapping table to obtain function basic information, where the function basic information includes the function name, start address, and end address. Specifically, information extraction is performed on the function address mapping table to obtain function basic information. The work in this stage mainly includes parsing the MAP file to identify and extract core information such as the name, start address, and end address of each function. For example, a script can be written or a dedicated tool can be used to automatically complete this task to ensure the consistency and accuracy of data extraction. Based on the function basic information, a structured data table is constructed, and data cleaning processing is performed on the structured data table to generate a first database, and the first database is stored as a basic function library. Specifically, constructing a structured data table not only helps improve the efficiency of data management but also facilitates subsequent data query and analysis. The design of the structured data table should consider the principle of being easy to expand and maintain, usually including fields such as function ID, function name, start address, end address, and any other potentially useful metadata. After constructing the structured data table, data cleaning processing is performed on it. Data cleaning aims to remove redundant information, correct incorrect data, and ensure the consistency of data formats. Common cleaning operations include removing duplicate records, correcting address range errors, and standardizing data formats. The data after cleaning will be converted into a first database, and the generated first database is stored as a basic function library. This basic function library will become the cornerstone of subsequent analysis work and be used to compare and match with other data collected during runtime. To ensure data security and access efficiency, a suitable database management system (such as SQLite or MySQL) can be selected to store this data, and a reasonable index strategy can be designed to accelerate the query speed.
[0028] In addition, during the data parsing process, it is also necessary to consider the handling of special cases. For example, when there are multiple functions with the same name but in different address spaces, how to correctly distinguish them; or when encountering functions with discontinuous addresses, how to reasonably handle these abnormal situations. The effective solution of these problems is crucial for improving the accuracy of the final analysis result. The goal of the entire process is to create a reliable basic database as the basis for comparing the data of the sampled file, so as to accurately count the actual execution frequency of each function and its proportion during the entire system operation.
[0029] Step S30, generating a sampled database based on the sampled file.
[0030] It should be noted that the sampling file usually contains a list of PC (Program Counter) pointer values collected at regular intervals during the system operation. These initial data need to go through a series of processes before being used for subsequent analysis.
[0031] Furthermore, step S30 also includes: determining the pointer information during runtime based on the sampling file, performing redundancy deletion on the pointer information to obtain the processed pointer information. Specifically, determining the pointer information during runtime mainly involves extracting all the PC pointer values from the sampling file. Since these data directly come from the real-time operation state of the system, they accurately reflect the execution situation of the system at each moment. However, the original sampling data may contain duplicate or incorrect information, which requires further processing. At the same time, to improve the accuracy of data analysis, it is necessary to perform redundancy deletion operations on the extracted pointer information. This includes identifying and removing duplicate PC pointer records, as well as filtering out obviously abnormal data points (such as values outside the valid address range). By applying appropriate algorithms, the data set can be effectively purified to ensure that each remaining pointer information is meaningful. Then, by matching the processed pointer information with the preset function address range, it is converted into the corresponding function identification information, and the function identification information is formatted according to the preset database structure to obtain the formatted function identification information. The formatted function identification information is stored to obtain the sampling database. Specifically, the processed pointer information is analyzed and converted into the corresponding function identification information by matching it with the preset function address range. The key here is to have an accurate basic database SQL1, which stores all functions and their corresponding address ranges. For each cleaned PC pointer value, check whether it falls within the address range of a known function and associate the pointer with the corresponding function identification. Once the function identifications corresponding to each PC pointer are determined, they need to be formatted according to the preset database structure. This means not only recording the identifier of each function but also including relevant metadata, such as the sampling timestamp, the thread ID it belongs to, etc., for subsequent analysis. The purpose of this is to build a database model with a clear structure and easy to query. The last step is to store the formatted function identification information into the sampling database SQL2. This usually involves batch insertion operations to efficiently import a large amount of data into the database.
[0032] The finally formed sampling database SQL2 should be a clear, ordered and easy-to-query structured data set, which can directly match and compare with the function address range information in the basic database SQL1, so as to calculate the actual execution times of each function and the proportion it occupies during the entire system operation.
[0033] Step S40: Compare the identification information in the sampling database with the basic information in the basic database to obtain the execution ratio.
[0034] It should be noted that the basic database SQL1 contains all functions parsed from the MAP file generated by GCC compilation and their corresponding address ranges and other detailed information. This information serves as a reference benchmark for identifying and matching data collected during runtime. After obtaining the cleaned and transformed sampling database SQL2, the next task is to compare each PC pointer value (i.e., the processed pointer information) recorded therein with the function address ranges in the basic database. Specifically, for each record in SQL2, query whether the PC pointer value it contains falls within the address range of any function in SQL1. If a match is found, it indicates that the PC pointer corresponds to an execution instance of a specific function.
[0035] After performing this comparison operation, the number of times each function is sampled can be counted. The above execution ratio is the ratio of the sampling times of the target function to the total sampling times. To calculate the execution ratio, the total sampling times also need to be known. Based on this, the execution ratio of each function can be calculated using the following formula: For example, in a hypothetical scenario, if a total of 10,000 samplings are performed and function A is sampled 500 times, then the execution ratio of function A is 5%. This analysis method can clearly show the proportion of importance of each function during the entire system operation. In addition, the function execution situation in different time periods can be further analyzed by segmenting the sampling data according to the timestamp to achieve this goal. For example, divide the one-day operation data into one-hour intervals, and then repeat the above matching and ratio calculation process within each interval. The advantage of doing this is that it can be observed whether the activity frequency of certain functions increases significantly during specific time periods, which may indicate high load or execution peaks of specific tasks during these periods. And classify and count according to different operation modes. Embedded systems usually run at different privilege levels, such as thread mode and privilege mode. Therefore, it is also necessary to classify and count the function execution situation according to the operation mode. In actual operation, this means that the current operation mode needs to be recorded when collecting PC pointers, and the sampling data is classified accordingly during the subsequent data processing stage. For example, functions frequently called in user mode may point to problems in the application layer logic, while functions called more frequently in kernel mode may be bottlenecks in underlying drivers or operating system services. In this way, the system can be optimized more targeted, such as adjusting task priorities or improving the efficiency of kernel-mode code.
[0036] Step S50: Combine the execution ratio with the basic information to generate an execution ratio result.
[0037] Specifically, based on the execution ratio data obtained by comparing the identification information in the sampling database with the basic information in the basic database as described above, summarize to form an execution ratio result. This execution ratio result usually includes the name of each function, its total number of samples during the entire system operation cycle, and the corresponding operation ratio.
[0038] Furthermore, according to the execution ratio result, generate an optimization result to conduct an in-depth analysis of the operation of the target function. For example, if it is found that some key functions are frequently called during system operation (high number of samples and / or high operation ratio), it means that these functions have become performance bottlenecks. For such functions, optimization suggestions can be put forward from multiple perspectives: For algorithm optimization, check whether the algorithm logic inside these functions can be optimized. For example, whether there are unnecessary loops, repeated calculations, or parts that can be replaced with more efficient algorithms. Memory access optimization analyzes the memory usage patterns of these functions and considers whether there is a high cache miss rate. Reduce memory access latency by adjusting the data structure or using an algorithm with better locality. For parallel processing, multi-threading can be introduced or hardware features (such as SIMD instruction sets) can be utilized to accelerate the execution process. Finally, for code refactoring, consider whether there is redundant code or overly complex control flow. Simplifying the code structure can not only improve readability but also potentially bring performance improvements. In addition, the optimization strategy can be further refined by combining the change trends of the execution ratio at different time periods or under different operation modes. For example, functions showing a high load during a specific time period need special attention, especially in real-time systems, and functions crucial for ensuring response time should be optimized first.
[0039] Furthermore, after obtaining the execution ratio results, continuous monitoring of the embedded system performance optimization will be carried out. By receiving the new sampling file output by the lower computer, the new sampling file is input into a preset neural network to obtain an updated sampling database, and the steps of S40 are executed based on the updated sampling database. Specifically, when the lower computer completes a new round of data collection, it will output a new sampling file containing the latest PC pointer value. This file contains the running state information of the system in the recent period of time and is crucial for capturing the dynamic behavior of the system. Once the new sampling file is received, the next step is to input it into a preset neural network for update operations. The preset neural network can be a model based on Long Short-Term Memory (LSTM) or Convolutional Neural Network (CNN). For example, an LSTM network is used to process time series data because the sampling files in the embedded system usually have time correlations. LSTM can capture pattern changes over a long time span, which is particularly useful for identifying function call frequencies and performance bottlenecks. CNN is good at feature extraction and can be used to detect specific patterns or anomalies in the PC pointer value. The advantage of using a neural network lies in its powerful pattern recognition ability and adaptive learning characteristics. Traditional data analysis methods are difficult to handle complex and dynamically changing data sets, while neural networks can automatically learn and identify potential patterns in the data through training. In addition, the operating environment of the embedded system is complex and changeable, and neural networks can better adapt to these changes and provide more accurate data analysis results. Using neural networks significantly improves the accuracy and efficiency of data processing.
[0040] After the update is completed, the next step is to compare the information in the updated sampling database with that in the base database. The core here is to match each PC pointer value with its corresponding function address range to determine the execution times and ratios of each function in the new time period. Since there is already the previous base database SQL1 and the old version of the sampling database SQL2 as references, this step mainly focuses on identifying the newly added execution instances and their impacts. In this way, not only can the trends of the system over time be traced, such as the increase or decrease in the execution frequency of certain functions, but also newly emerging performance bottlenecks can be discovered in a timely manner. For example, if a function that was previously less active suddenly shows a high execution ratio, it is due to recent code changes or a shift in the task load caused by changes in the external environment. For these findings, the optimization strategy can be quickly adjusted, such as reexamining the implementation details of the relevant functions and considering adjustments to the resource allocation plan.
[0041] This embodiment provides a method for generating function execution ratio results based on an embedded system, by obtaining original files and sampling files from the embedded system, and generating a basic database and a sampling database through data cleaning and analysis. The identification information of the two is compared to obtain the function execution ratio, and a result report containing the function name, sampling times and running ratio is generated. Further, a new sampling file is received and the sampling database is updated through a preset neural network optimization, and the execution ratio is dynamically updated again. By parsing the MAP file and the sampling PC pointer, a basic and sampling database are formed, and the function execution ratio is obtained by comparing the two. The neural network is used to improve the data processing efficiency and accuracy, and the embedded system operation efficiency is evaluated based on the positioning of high-load functions, thereby improving the performance optimization efficiency of the embedded system.
[0042] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can refer to the above introduction, and will not be repeated later. Figure 2 The method for generating the function execution ratio result based on the embedded system in step S40 further includes steps S201 to S205: Step S201: determining an original pointer sampling sequence based on a sampling file.
[0043] It should be noted that all PC pointer values are first extracted from the sampling file. These values are usually accompanied by timestamps or other metadata (such as thread ID) to provide contextual information. Automated tools can be written using scripting languages (such as Python or Perl) to parse the sampling file and extract the required pointer information from it. The next step is to clean the extracted raw pointer values to remove any noise or invalid data that may affect the accuracy of the analysis. For example, filter out pointer values that exceed the valid address range, remove duplicate records, and correct incorrect timestamps. This step ensures the data quality for subsequent analysis. The cleaned pointer values will be organized into an ordered sequence, namely the raw pointer sampling sequence. This sequence is arranged in chronological order, and each element represents the code location that the system is executing at a certain moment. In order to facilitate subsequent analysis, additional metadata can also be attached to each pointer value, such as the acquisition time, the thread to which it belongs, etc.
[0044] Step S202: performing address alignment processing on the original pointer sampling sequence to obtain an address interval corresponding to the original pointer sampling sequence.
[0045] It should be noted that address alignment processing is performed on each PC pointer value in the original pointer sampling sequence. Specifically, it is to check whether each pointer value falls within the address range of a certain function. This can be achieved through scripting or using SQL queries for automated processing. For example, for each pointer value, the basic database can be queried to find all function address ranges containing this pointer value and record the matching results.
[0046] Once the address range to which each pointer value belongs is determined, a mapping table can be generated to convert the original pointer sampling sequence into a corresponding address range sequence. This mapping table not only contains each pointer value and its corresponding function address range, but also can attach additional information such as function name, thread ID, etc., for subsequent analysis. To ensure the accuracy of address alignment, the results also need to be verified. For example, check whether there are unrecognized pointer values (which may point to operating system code or other non-user-defined functions) and handle these special cases appropriately. In addition, by optimizing the query algorithm and index structure, the speed and efficiency of address alignment processing can be significantly improved.
[0047] Step S203: Based on the address ranges, perform statistics to obtain the corresponding occurrence frequencies and frequency distribution table.
[0048] It should be noted that performing statistics based on the address ranges to obtain the corresponding occurrence frequencies and frequency distribution table can identify which functions in the system are frequently called, thereby locating potential performance bottlenecks.
[0049] Specifically, according to the mapping table generated after address alignment processing, we can count the occurrence frequencies of each function address range in the sampling file, that is, how many times the function has been executed during the entire monitoring period. By traversing all pointer values and recording the function address ranges they belong to, a frequency statistics table can be constructed, where each item represents a function and its corresponding execution times. For further analysis, the proportion of the execution frequency of each function to the total sampling times can also be calculated to form a frequency distribution table, which helps to understand the resource occupancy of each function in the system and its relative importance. In addition, the frequency distribution table not only shows the functions with high-frequency calls, but also reveals the function call patterns with low frequencies but possibly critical ones, providing a basis for optimization work. For example, if the execution frequency of a certain function is extremely high, code optimization or algorithm improvement may need to be considered; while functions with low frequencies but long execution times may be the key objects for optimization.
[0050] Step S204: Establish a second database according to the occurrence frequencies and frequency distribution table.
[0051] It should be noted that the second database includes address values, occurrence counts, and timestamps. When constructing the second database, this process can be automated by writing scripts or using database management tools. For each record, in addition to storing the address value and occurrence count, adding a timestamp field can provide additional temporal dimension information to help developers understand the changing trends of specific function call patterns over time. For example, certain functions may be frequently called only within a specific time period, which may be due to changes in system load or other external factors. In this way, not only can the execution frequency of each function be accurately recorded, but also its dynamic behavior characteristics can be captured.
[0052] In addition, to improve query efficiency and data management capabilities, the second database should be designed with a reasonable index structure. For example, indexes can be created based on address values, occurrence counts, or timestamps to make query operations more efficient.
[0053] Step S205: Perform a culling process on the second database to obtain a sampled database.
[0054] It should be noted that culling the second database to generate a streamlined sampled database is a crucial step in ensuring data quality and improving analysis efficiency. This process aims to remove unnecessary redundant information and abnormal data, thereby making the final dataset used for performance analysis more accurate and useful.
[0055] Further, step 205 also includes: obtaining a running timestamp and a basic database range. Specifically, the running timestamp refers to the specific time records of the system during monitoring. These timestamps provide the time dimension information of the data, enabling developers to track the system behavior within a specific time period. By recording the time points of each sampling, the changing trend of the system load can be analyzed, and the time periods of peak hours or abnormal events can be identified. At the same time, the basic database range refers to the set of address intervals of all functions extracted from the compiled MAP file or other original files. This range includes the starting address and the ending address of each function, which defines the locations of all monitorable functions in the system. The basic database not only provides a reference standard for subsequent data processing but also helps to identify which PC pointer values belong to legitimate function calls, thus excluding invalid or abnormal data points. Then, abnormal data with address values exceeding the basic database range in the second database is removed to obtain an updated second database. Specifically, each address value in the second database needs to be compared with the function address intervals in the basic database. The basic database contains the starting and ending addresses of all known functions, and these address intervals define the legitimate function call range. By writing a script or using a database query language (such as SQL), it is possible to automatically check whether each PC pointer value falls within the address range of any function. If an address value exceeds the range of the basic database, it is considered abnormal data and should be removed from the second database. For example, all records in the second database can be traversed through a loop structure, and a lookup operation can be performed on each address value to determine whether it belongs to a legitimate function address interval. Records that do not meet the conditions can be directly deleted or marked as invalid. To ensure the accuracy of the processing, a logging function can also be added to record in detail the data being removed and the reasons, facilitating subsequent review and verification. After this step, the obtained updated second database only contains valid address values within the known function address range. This not only improves the purity of the data set but also provides a reliable basis for subsequent statistical analysis. Then, updated address values and the occurrence times of each address value in a preset sampling period are obtained based on the updated second database, and a sampling database is generated based on the updated address values, the occurrence times of each address value in the preset sampling period, and the corresponding running timestamps. Specifically, for each valid address value in the updated second database, the number of times it is sampled throughout the monitoring period is counted. This can be achieved by traversing all records and grouping and summarizing them by address value. For example, using an SQL query, it is easy to count the occurrence frequency of each address value: "SELECT address_value, COUNT(*) AS occurrence FROM updated_db GROUP BY address_value".Here, "updated_db" represents the updated second database, "address_value" is the specific address pointed to by the PC pointer, and "occurrence" represents the number of occurrences of that address value. Next, based on these updated address values and their corresponding occurrence counts, combined with the timestamp information of each record, the final sampled database is generated. Each entry should include not only the address value and the occurrence count, but also the timestamps of the first and last occurrences, as well as other metadata (such as thread ID) that may be helpful for analysis. The purpose of this is to provide a structured and easily queryable dataset to support more in-depth performance analysis. For example, through the timestamp information, high-load functions within a specific time period can be identified, or trends in the call patterns of certain functions over time can be discovered.
[0056] In this embodiment, the original pointer sampling sequence is extracted from the sampling file, mapped to the corresponding function address range through address alignment processing, and the occurrence frequency and distribution of each address range are counted. Based on these data, a second database is established, which includes address values, occurrence counts, and timestamps. Subsequently, data elimination processing is performed to remove outliers, and finally the final sampled database is generated, improving data accuracy and analysis efficiency, effectively identifying high-load functions and potential bottlenecks in the system, supporting dynamic optimization and adjustment, enhancing the performance and stability of the system, and providing a reliable data basis for continuous monitoring and improvement.
[0057] Based on the first embodiment of the present application, in the third embodiment of the present application, the same or similar content as in the above-mentioned first embodiment can be referred to the above introduction and will not be repeated hereinafter. On this basis, please refer to Figure 3 , the method step S40 for generating the function execution proportion result based on the embedded system further includes steps S301 to S304: Step S301, extract pointer information at multiple sampling moments from the sampled database and obtain the total number of samplings.
[0058] It should be noted that by querying the sampling database, all PC pointer value records within a specific time interval can be filtered out to ensure coverage of the critical periods of system operation. Once the required time period is determined, the next step is to summarize and statistically analyze this data. This not only includes collecting all pointer information at each sampling moment but also calculating the total number of samplings during the entire selected period. The specific operation can be automated through writing scripts or using SQL queries. For example, a simple SQL query: "SELECT COUNT(*) FROM sampled_data WHERE timestamp BETWEEN'start_time' AND 'end_time';". Here, "sampled_data" represents the table storing the sampling data, and "timestamp" is the field recording the collection time.
[0059] Step S302, obtain multiple corresponding function identification information according to multiple pointer information.
[0060] It should be noted that in order to convert these pointer values into meaningful function identification information, they need to be matched with the function address ranges in the basic database (SQL1). The specific operation usually involves writing scripts or using database query languages (such as SQL) to automate this process. For example, a loop structure can be constructed to traverse all sampled PC pointer values and perform a lookup operation for each pointer value to determine the function it belongs to. This lookup operation can be achieved by comparing whether the PC pointer value falls between the start and end addresses of a certain function. If a match is found, the identifier of that function is recorded; if not, it means the pointer points to an unrecognized part, such as operating system kernel code or other non-user-defined functions.
[0061] Step S303, look up the corresponding basic information in the basic database according to multiple function identification information to obtain the sampling times of the target function.
[0062] It should be noted that based on the function identification information obtained in the previous steps, relevant data can be automatically retrieved from the basic database (SQL1) by writing query scripts or using SQL statements. Each function identification information represents a specific function name and its corresponding address range.
[0063] Specifically, a database query can be executed once for each function identification information. For example: "SELECT function_name, start_address, end_address FROM function_base WHERE function_id = 'target_function_id'". Here, "function_base" is the table storing all basic function information, and "function_id" is the field used to uniquely identify each function. In this way, detailed basic information of the target function can be obtained, including but not limited to the function name, start address, and end address. Next, these basic information are used to match the pointer information in the sampling database to count the sampling times of the target function. This process involves traversing each record in the sampling database (SQL2) and checking whether its PC pointer value falls within the address range of a certain function. If the match is successful, the sampling count of this function is incremented by one. Finally, by summarizing all the matching results, the exact sampling times of the target function can be obtained.
[0064] Step S304, determine the execution ratio of the target function based on the sampling times of the target function and the total sampling times.
[0065] It should be noted that after obtaining the execution ratio of the target function, more in-depth analysis can be carried out. Functions with a high execution ratio may be potential performance bottlenecks, especially when these functions contain complex logic or are frequently called. In this way, not only can it be intuitively seen which functions are most frequently executed, but also those places that may need optimization can be discovered.
[0066] In addition, comparing the execution ratio with the expected performance metrics can help verify whether the actual performance of the system meets the expectations and guide subsequent optimization work. For example, if the execution ratio of functions on certain critical paths is much higher than expected, then measures such as algorithm optimization, parallel processing, or code refactoring can be considered to improve efficiency.
[0067] In this embodiment, by extracting pointer information from the sampling database and counting the total sampling times, identifying the function according to the pointer match, querying the basic database to obtain the sampling times of the target function, and calculating the execution ratio, performance monitoring and analysis are achieved, accurately locating high-load functions, providing data support for optimizing the performance of the embedded system.
[0068] Based on this, the embodiment of the present application provides a method for generating function execution ratio results based on an embedded system, which is applied to the lower computer. The lower computer usually refers to an embedded hardware device that directly runs, such as a microcontroller (MCU) or a single-chip microcomputer. Refer to Figure 4 , Figure 4This is a schematic flowchart of the fourth embodiment of the method for generating the function execution proportion result based on an embedded system in this application.
[0069] In this embodiment, the method for generating the function execution proportion result based on an embedded system includes steps S401 to S404: Step S401, collect the program counter data during the operation of the embedded system through a timer interrupt mechanism.
[0070] It should be noted that first, set a timer through the timer interrupt mechanism and configure the trigger period of the timer as a preset sampling interval. A hardware timer needs to be configured during the system initialization phase. This timer is set to trigger an interrupt every certain time interval, for example, every 1 millisecond. Then, sample the program counter according to the preset sampling interval and record the program counter data. Specifically, each time the timer triggers an interrupt, the interrupt service routine (ISR) will read the current program counter value and record it. These PC pointer values directly reflect the code position that the system is executing at that moment. To minimize the impact on system performance, the ISR should be as concise as possible and only responsible for obtaining and recording the PC pointer value. Finally, write the program counter data into a circular buffer, obtain the data volume of the circular buffer, detect the comparison between the data volume of the circular buffer and a preset capacity threshold, and obtain a detection result. When the detection result is that the data volume of the circular buffer exceeds the preset capacity threshold, output the program counter data. Specifically, each time a timer interrupt is triggered, the obtained PC pointer value will be quickly written into the circular buffer, which can ensure the continuity and real-time nature of the data. As new data is continuously added, the system will dynamically calculate the current data volume of the circular buffer. By comparing this data volume with the preset capacity threshold, the status of the buffer can be monitored. If the detection result shows that the data volume of the circular buffer exceeds the preset capacity threshold, it means that the buffer is about to be full or already full. At this time, immediate measures need to be taken to avoid data loss. When the detection result indicates that the data volume exceeds the limit, the system will start the data output process, pack all the unprocessed data in the circular buffer into a sampling file, and send it to the host computer for subsequent analysis. To ensure data consistency and integrity, mutex locks or other synchronization mechanisms may be needed to avoid race conditions when accessing this buffer in a multi-threaded environment.
[0071] In addition, considering the data overflow problem that may occur during long-term operation, a mechanism also needs to be implemented to handle the full-load situation. For example, when the buffer reaches its capacity limit, the earliest record can be overwritten or the collection can be stopped and a warning notice can be issued. At the same time, to avoid excessive impact on system performance, the collection operation should be as concise and efficient as possible, reducing the workload executed in the interrupt context.
[0072] Step S402, convert the program counter data to obtain pointer information.
[0073] It should be noted that each time a timer interrupt is triggered, the obtained original PC value needs to go through a series of processes to be converted into meaningful pointer information.
[0074] First of all, the obtained PC value is usually a memory address, directly representing the position of the currently executing instruction. However, for ease of understanding and analysis, these addresses need to be mapped to specific functions or code segments. The first step in the conversion process is to correct the PC value to ensure that it points to the correct instruction position. For example, some architectures may require an offset adjustment to the PC value to match the actual instruction address. Next, by looking up the basic database (such as the function address range parsed from the MAP file), each PC value can be mapped to the corresponding function name and address range. This step not only involves simple address comparison but also needs to handle edge cases, such as instructions across function boundaries. In addition, additional metadata, such as acquisition timestamps, thread IDs, etc., can be attached to each pointer information during the conversion process to provide richer context information. The generated pointer information not only includes the original PC value but also the function name it belongs to, the address range, and the relevant time and thread information.
[0075] Step S403: Store the pointer information into the acquisition information table.
[0076] It should be noted that the PC pointer value read in the timer interrupt service routine (ISR) will be immediately added to a specially designed acquisition information table. This acquisition information table is usually a circular buffer or linked list structure, which can effectively manage memory usage while ensuring data continuity. Each time a new PC pointer value is acquired, it will be inserted into the table according to the first-in-first-out principle to ensure that the latest data will not be lost. To prevent data overwriting and overflow problems, the acquisition information table needs to have a certain self-protection mechanism. For example, when the table approaches its maximum capacity, a semaphore can be released to notify the log output thread to process the existing data, or simply stop entering new data and record an overflow event for subsequent analysis. In addition, considering the limited system resources, the operation complexity performed in the ISR should be minimized, and only necessary data insertion operations should be carried out, while handing over more time-consuming data processing tasks to the background low-priority thread. At the same time, each record may include auxiliary information such as timestamps and thread IDs to provide a richer context environment.
[0077] Step S404: When the acquisition information table meets the preset capacity, output the acquisition information table as a sampling file and send it to the host computer.
[0078] It should be noted that, in order to manage the capacity of the acquisition information table, a threshold is usually set to define when to output data. For example, if the acquisition information table is designed to store 1000 records, when the number of records reaches this threshold due to newly added data, the system will trigger the data output mechanism. At this time, all the data in the acquisition information table will be packed into a sampling file. The packing process may include formatting the data and adding necessary metadata (such as timestamps, device identifiers, etc.) to ensure that the host computer can accurately parse this information. Then the sampling file is transmitted to the host computer. According to the specific communication protocol and hardware configuration, various methods can be used to achieve this goal. For example, the file can be sent out through a serial port, a USB interface, or a network connection (such as TCP / IP). In some application scenarios, wireless communication technologies (such as Wi-Fi, Bluetooth) may also be used to transmit data, which is especially suitable for mobile or remote monitoring scenarios. In order not to affect the real-time performance of the system, in actual operation, a low-priority thread or a specific background task is usually selected to perform the file transmission work.
[0079] Furthermore, in order to achieve real-time monitoring and analysis of the function execution ratio, the lower computer needs to continuously update the sampling file and transmit these latest sampling files to the host computer in real time.
[0080] When the acquisition information table reaches the preset time, the data in the acquisition information table is updated and packed again as a new sampling file and sent to the host computer. Specifically, when a certain time interval (such as 10s) has passed for the acquisition information table in the lower computer, a data packing operation will be triggered to convert the currently acquired information into a new sampling file. In this process, in addition to including the PC pointer value, metadata such as timestamps and thread IDs will also be attached to provide richer context information. In this way, each newly generated sampling file reflects the running state of the system in the recent period. Next, the lower computer will use the pre-configured communication mechanism, such as a serial port, USB, or network interface (such as the TCP / IP protocol), to send the newly generated sampling file to the host computer. In order to ensure the stability and efficiency of data transmission, a streaming transmission method can be adopted, that is, transmitting while generating the sampling file instead of waiting for the entire file to be generated before transmitting. In addition, a retransmission mechanism can also be set up to deal with possible data loss problems to ensure that all important performance data can reach the host computer safely. This process ensures the currency and accuracy of the performance data and provides a solid foundation for the continuous optimization of the system.
[0081] In this embodiment, a timer is set to collect pointer information and store the pointer information in the acquisition information table. When the acquisition information table meets the preset capacity, the acquisition information table is output as a sampling file and sent to the host computer, realizing data acquisition and transmission, supporting real-time performance monitoring, and improving the efficiency and accuracy of system optimization.
[0082] The present application also provides a function execution ratio result generation device based on an embedded system. Please refer to Figure 5 , the device includes: An acquisition module 10, configured to acquire the original file of the embedded system and receive the sampling file transmitted by the lower computer.
[0083] A processing module 20, configured to perform data cleaning and parsing on the original file to obtain a basic database; The processing module 20 is further configured to generate a sampling database according to the sampling file.
[0084] A comparison module 30, configured to compare the identification information in the sampling database with the basic information in the basic database to obtain an execution ratio, where the execution ratio is the ratio of the sampling times of the target function in the total sampling times.
[0085] A result module 40, configured to combine the execution ratio with the basic information to generate an execution ratio result, where the execution ratio result includes the function name, the sampling times, and the running ratio.
[0086] A data update module 50, configured to receive a new sampling file output by the lower computer; input the new sampling file into a preset neural network to obtain an updated sampling database; and perform the step of comparing the identification information in the sampling database with the basic information in the basic database based on the updated sampling database to obtain an execution ratio.
[0087] The function execution ratio result generation device based on an embedded system provided by the present application adopts the function execution ratio result generation method in the above embodiment, and can solve the technical problem of how to obtain the function execution ratio in real time and efficiently. Compared with the prior art, the beneficial effects of the function execution ratio result generation device based on an embedded system provided by the present application are the same as those of the function execution ratio result generation method based on an embedded system provided by the above embodiment, and other technical features in the function execution ratio result generation device based on an embedded system are the same as the features disclosed in the method of the above embodiment, and will not be described in detail here.
[0088] In one embodiment, the processing module 20 is further configured to obtain a function address mapping table for the original file; extract information from the function address mapping table to obtain function basic information, where the function basic information includes the function name, the start address, and the end address; construct a structured data table based on the function basic information; perform data cleaning processing on the structured data table to generate a first database; and store the first database as a basic function library.
[0089] In one embodiment, the processing module 20 is further configured to determine an original pointer sampling sequence based on a sampling file; perform address alignment processing on the original pointer sampling sequence to obtain an address range corresponding to the original pointer sampling sequence; perform statistics based on the address range to obtain corresponding occurrence frequencies and a frequency distribution table; establish a second database according to the occurrence frequencies and the frequency distribution table, where the second database includes address values, occurrence times, and timestamps; perform elimination processing on the second database to obtain a sampling database.
[0090] In one embodiment, the processing module 20 is further configured to obtain a running timestamp and a basic database range; eliminate abnormal data in the second database whose address values exceed the basic database range to obtain an updated second database; obtain updated address values and the occurrence times of each address value in a preset sampling period according to the updated second database; generate a sampling database based on the updated address values, the occurrence times of each address value in the preset sampling period, and the corresponding running timestamps.
[0091] In one embodiment, the comparison module 30 is further configured to extract pointer information at multiple sampling moments from the sampling database and obtain the total number of samplings; obtain multiple corresponding function identification information according to the multiple pointer information; find corresponding basic information in the basic database according to the multiple function identification information to obtain the sampling times of the target function; determine the execution ratio of the target function based on the sampling times of the target function and the total number of samplings.
[0092] In one embodiment, the result module 30 is further configured to collect program counter data during the operation of the embedded system through a timer interrupt mechanism; convert the program counter data to obtain pointer information; store the pointer information in a collection information table; when the collection information table meets a preset capacity, output the collection information table as a sampling file and send it to the host computer.
[0093] In one embodiment, the result module 30 is further configured to set a timer through a timer interrupt mechanism; configure the trigger period of the timer as a preset sampling interval; sample the program counter at the preset sampling interval and record the program counter data; write the program counter data into a circular buffer to obtain the data volume of the circular buffer; detect the comparison between the data volume of the circular buffer and a preset capacity threshold to obtain a detection result; when the detection result is that the data volume of the circular buffer exceeds the preset capacity threshold, output the program counter data.
[0094] The present application provides a device for generating function execution proportion results based on an embedded system. The device for generating function execution proportion results based on an embedded system includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the method for generating function execution proportion results based on an embedded system in the first embodiment above.
[0095] Reference is made below to Figure 6 , which shows a schematic structural diagram of a device for generating function execution proportion results based on an embedded system suitable for implementing the embodiments of the present application. The device for generating function execution proportion results based on an embedded system in the embodiments of the present application may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistant), PADs (Portable Application Description: tablet computers), PMPs (Portable Media Player: portable multimedia players), in-vehicle terminals (such as in-vehicle navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 6 The device for generating function execution proportion results based on an embedded system shown is merely an example and should not impose any limitations on the functions and usage scope of the embodiments of the present application.
[0096] As Figure 6As described above, the device for generating the function execution proportion result based on the embedded system may include a processing device 1001 (such as a central processing unit, a graphics processing unit, etc.), which may perform various appropriate actions and processes according to the program stored in the ROM (Read Only Memory) 1002 or the program loaded from the storage device 1003 into the RAM (Random Access Memory) 1004. In the RAM 1004, various programs and data required for the operation of the device for generating the function execution proportion result based on the embedded system are also stored. The processing device 1001, the ROM 1002, and the RAM 1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems may be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 may allow the device for generating the function execution proportion result based on the embedded system to communicate with other devices wirelessly or wiredly to exchange data. Although the figure shows a device for generating the function execution proportion result based on the embedded system having various systems, it should be understood that it is not required to implement or have all the shown systems. Instead, more or fewer systems may be implemented or had.
[0097] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes program codes for executing the methods described in the flowcharts. In such an embodiment, the computer program may be downloaded and installed from the network through the communication device, or installed from the storage device 1003, or installed from the ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the methods of the embodiments disclosed in the present application are executed.
[0098] The function execution ratio result generation device based on an embedded system provided by this application adopts the function execution ratio result generation method in the above-mentioned embodiment, and can solve the technical problem of how to obtain the function execution ratio in real time and efficiently. Compared with the prior art, the beneficial effects of the function execution ratio result generation device based on an embedded system provided by this application are the same as those of the function execution ratio result generation method based on an embedded system provided by the above-mentioned embodiment, and other technical features in the function execution ratio result generation device based on an embedded system are the same as the features disclosed in the method of the previous embodiment, which will not be elaborated here.
[0099] It should be understood that each part disclosed in this application can be implemented by hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in a suitable manner in any one or more embodiments or examples.
[0100] As mentioned above, only the specific implementation manners of this application are described, but the protection scope of this application is not limited thereto. Any person skilled in the art within the technical scope disclosed in this application can easily think of changes or substitutions, which should all be covered within the protection scope of this application. Therefore, the protection scope of this application should be subject to the protection scope of the claims.
[0101] This application provides a computer-readable medium with computer-readable program instructions (i.e., computer programs) stored thereon for performing calculations to obtain computer-readable program instructions for executing the function execution ratio result generation method based on an embedded system in the above-mentioned embodiment.
[0102] The computer-readable medium provided by the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or components, or any combination of the above. More specific examples of computer-readable media may include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM) or flash memory, optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above. In this embodiment, the computer-readable medium can be any tangible medium that contains or stores a program, and the program can be used by or in conjunction with an instruction execution system, device, or component. The program code contained on the computer-readable medium can be transmitted by any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the above.
[0103] The above computer-readable medium may be included in a device for generating a function execution ratio result based on an embedded system; or it may exist independently and not be assembled into a device for generating a function execution ratio result based on an embedded system.
[0104] The above computer-readable medium carries one or more programs. When the one or more programs are executed by a device for generating a function execution ratio result based on an embedded system, the device for generating a function execution ratio result based on an embedded system can write computer program code for performing the operations of the present application in one or more programming languages or combinations thereof. The above programming languages include object-oriented programming languages - such as Java, Smalltalk, C++; and also include conventional procedural programming languages - such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any type of network - including a local area network (LAN) or a wide area network (WAN) - or can be connected to an external computer (for example, by using an Internet service provider to connect through the Internet).
[0105] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagram may represent a module, a segment of a program, or a portion of code that contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than that marked in the accompanying drawings. For example, two consecutive blocks shown may actually be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, as well as combinations of blocks in the block diagram and / or flowchart, can be implemented by a dedicated hardware-based system that performs the specified functions or operations, or can be implemented by a combination of dedicated hardware and computer instructions.
[0106] The modules described in the embodiments of the present application can be implemented in software or in hardware. In some cases, the name of the module does not constitute a limitation on the unit itself.
[0107] The readable medium provided by the present application is a computer-readable medium, and the computer-readable medium stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned method for generating the function execution ratio result based on an embedded system, which can solve the technical problem of how to obtain the function execution ratio in real time and efficiently. Compared with the prior art, the beneficial effects of the computer-readable medium provided by the present application are the same as those of the method for generating the function execution ratio result based on an embedded system provided in the above embodiments, and will not be elaborated here.
[0108] The present application also provides a computer program product, including a computer program, and when the computer program is executed by a processor, it implements the steps of the method for generating the function execution ratio result based on an embedded system as described above.
[0109] The computer program product provided by the present application can solve the technical problem of how to obtain the function execution ratio in real time and efficiently. Compared with the prior art, the beneficial effects of the computer program product provided by the present application are the same as those of the method for generating the function execution ratio result based on an embedded system provided in the above embodiments, and will not be elaborated here.
[0110] The above are only some embodiments of the present application, and do not limit the patent scope of the present application. All equivalent structural transformations made under the technical concept of the present application by using the content of the specification and drawings of the present application, or directly / indirectly applied to other related technical fields, are included in the patent protection scope of the present application.
Claims
1. A method for generating function execution ratio results based on an embedded system, characterized in that: The method is applied to a host computer, and the method comprises: Obtain the original files of the embedded system and receive the sample files transmitted by the lower computer; Performing data cleaning and analysis on the original file to obtain a basic database; Generate a sampling database according to the sampling file; Comparing the identification information in the sampling database with the basic information in the basic database, obtaining an execution ratio, where the execution ratio is the ratio of the number of samplings of the target function to the total number of samplings; The execution ratio is combined with the basic information to generate an execution ratio result, wherein the execution ratio result includes the function name, sampling times and running ratio; After the step of comparing the identification information in the sampling database with the basic information in the basic database to obtain the execution ratio, the method further comprises: Receive new sampling files output by the lower computer; Inputting a preset neural network into the new sampling file to obtain an updated sampling database; A step of comparing the identification information in the sampling database with the basic information in the basic database to obtain an execution ratio is performed based on the updated sampling database.
2. The method according to claim 1, characterized in that The step of performing data cleaning and parsing on the original file to obtain a basic database includes: Obtaining a function address mapping table for the original file; Extracting information from the function address mapping table to obtain basic function information, wherein the basic function information includes a function name, a start address, and an end address; Constructing a structured data table based on the basic function information; Performing data cleaning processing on the structured data table to generate a first database; The first database is stored as a basic function library.
3. The method according to claim 1, characterized in that The step of generating a sampling database according to the sampling file comprises: Determine an original pointer sampling sequence based on the sampling file; Performing address alignment processing on the original pointer sampling sequence to obtain an address interval corresponding to the original pointer sampling sequence; Perform statistics based on the address interval to obtain corresponding occurrence frequency and frequency distribution table; Establishing a second database according to the occurrence frequency and frequency distribution table, wherein the second database includes address values, occurrence times and timestamps; The second database is eliminated to obtain a sampling database.
4. The method according to claim 3, characterized in that The step of performing elimination processing on the second database to obtain a sample database includes: Get the run timestamp and underlying database scope; Eliminate abnormal data in the second database whose address value exceeds the range of the basic database to obtain an updated second database; Obtaining updated address values and the number of occurrences of each address value in a preset sampling period according to the updated second database; A sampling database is generated based on the updated address value, the number of occurrences of each address value in a preset sampling period and the corresponding running timestamp.
5. The method according to claim 1, characterized in that The step of obtaining the execution ratio by comparing the identification information in the sampling database with the basic information in the basic database includes: Extracting pointer information of multiple sampling moments from the sampling database and obtaining the total number of sampling times; Acquire multiple corresponding function identification information according to the multiple pointer information; According to the plurality of function identification information, the corresponding basic information is searched in the basic database to obtain the sampling times of the target function; The execution ratio of the objective function is determined based on the objective function sampling times and the total sampling times.
6. A method for generating function execution ratio results based on an embedded system, characterized in that: The method is applied to a lower computer, and the method comprises: Collect program counter data when the embedded system is running through the timer interrupt mechanism; Convert the program counter data to obtain pointer information; Storing the pointer information in a collection information table; When the collection information table meets the preset capacity, the collection information table is output as a sampling file and sent to a host computer to execute the method according to claim 1.
7. The method according to claim 6, characterized in that The step of collecting program counter data when the embedded system is running through the timing interrupt mechanism includes: Set the timer through the timer interrupt mechanism; Configuring the trigger period of the timer to be a preset sampling interval; Recording program counter data by sampling the program counter according to the preset sampling interval; Writing the program counter data into a circular buffer to obtain the data volume of the circular buffer; Detecting the data volume of the circular buffer and comparing it with a preset capacity threshold to obtain a detection result; When the detection result is that the amount of data in the circular buffer exceeds a preset capacity threshold, the program counter data is output.
8. A function execution ratio result generating device based on an embedded system, characterized in that: The device comprises: The acquisition module is used to obtain the original files of the embedded system and receive the sample files transmitted by the lower computer; A processing module, used for performing data cleaning and analysis on the original file to obtain a basic database; The processing module is further used to generate a sampling database according to the sampling file; A comparison module, configured to compare the identification information in the sampling database with the basic information in the basic database to obtain an execution ratio, where the execution ratio is the ratio of the number of samplings of the target function to the total number of samplings; A result module is used to combine the execution ratio with the basic information to generate an execution ratio result, wherein the execution ratio result includes the function name, sampling times and running ratio; The data update module is used to receive a new sampling file output by a lower computer; input a preset neural network into the new sampling file to obtain an updated sampling database; and perform a step of comparing the identification information in the sampling database with the basic information in the basic database based on the updated sampling database to obtain an execution ratio.
9. A function execution ratio result generating device based on an embedded system, characterized in that: The device includes: a memory, a processor, and a function execution ratio result generation program based on an embedded system stored in the memory and running on the processor, wherein the function execution ratio result generation program based on an embedded system is configured to implement the steps of the function execution ratio result generation method based on an embedded system as described in any one of claims 1-5 and or 6-7.
10. A storage medium, characterized in that: The storage medium stores a function execution ratio result generation program based on an embedded system, and when the function execution ratio result generation program based on an embedded system is executed by a processor, the steps of the function execution ratio result generation method based on an embedded system as described in any one of claims 1-5 and or 6-7 are implemented.
Citation Information
Patent Citations
Subdivision information collection system and collection method thereof
CN101673214A
Software-defined key function positioning and extracting method of C + + system
CN111857681A
Firmware instruction set architecture identification method based on function call instruction feature analysis
CN116991475A
Controller behavior and parameter monitoring method and device, electronic equipment and medium
CN118468289A
Performance analysis method based on RISC-V architecture
CN119669015A