MCU performance monitoring system and method

Abstract

The invention relates to an MCU performance monitoring system and method, and the system comprises an interrupt monitor which monitors an interrupt signal and determines whether to output an interrupt event; the bus monitor monitors a bus address and determines whether to output a bus event; the event filter is used for judging whether event filtering is carried out or not according to the obtained interrupt event and the bus event, and controlling to output busy signals after filtering; the timer generates a counting pulse signal and a counting overflow signal and is used for controlling the sampling operation frequency of busy signals; and the analysis engine performs timing analysis on the busy signal according to the counting pulse signal and the counting overflow signal to determine whether an interrupt request is generated or not. And the control engine configures the counting frequency and the counting length of the timer. The performance monitoring system judges whether the system is in a busy state or not by automatically monitoring the interruption state and the code running address of the system, analyzes busy signals and determines whether interruption processing is carried out or not, and a large number of idle functions do not need to be added to occupy processing core computing resources.

Description

Technical Field

[0001] The present disclosure relates to the technical field of system performance monitoring, and in particular to an MCU performance monitoring system and method. Background Art

[0002] Embedded products usually have performance, power consumption and real-time requirements for microcontroller units (MCUs), especially embedded products without operating systems, which hope to meet the smooth processing of real-time and non-real-time services with the lowest power consumption. Among them, real-time performance is mainly affected by the interrupt response time and interrupt processing time, while non-real-time service processing performance is positively correlated with the main frequency and is affected by the processing efficiency of the processing core.

[0003] When using the MCU, it is necessary to know the utilization rate of the processing core by different types of tasks and dynamically adjust the performance of the MCU according to the utilization rate. Specifically, when the utilization rate is low, the performance is reduced to reduce power consumption; when the utilization rate is high, the performance is improved, or non-essential tasks are stopped to ensure smooth processing of real-time and non-real-time tasks. During the product development stage, engineers can determine whether the current MCU is suitable based on the use of the processing core and decide whether to replace it with another type of MCU.

[0004] At present, the utilization rate of the processing core is usually counted by inserting an idle function in the software, and a regular interrupt is used to check the utilization rate of the processing core, so as to make corresponding processing. Specifically, it is necessary to add a control function at the start and end position of the interrupt or non-real-time task, and control the output of the IO port. Among them, different interrupts require the addition of a large number of idle functions, and the mutual exclusion processing of the idle function and the control of the IO port output are relatively time-consuming, which seriously affects the real-time performance of the system. Not only that, the logic of a large number of idle functions and mutual exclusion processing is relatively complicated. In addition to taking up a lot of code space, it also increases the difficulty of development and is prone to errors. Summary of the invention

[0005] In view of this, an embodiment of the present application provides an MCU performance monitoring system and method to solve the above-mentioned problems.

[0006] In a first aspect, an embodiment of the present application provides an MCU performance monitoring system, including a control engine and an interrupt monitor, a bus monitor, an event filter, a timer, and an analysis engine controlled by the control engine;

[0007] The interrupt monitor is used to monitor the interrupt signal of the system kernel and determine whether it corresponds to an output interrupt event;

[0008] The bus monitor is used to monitor the bus address of the system bus and determine whether it corresponds to an output bus event;

[0009] The event filter is electrically connected to the interrupt monitor and the bus monitor, and is used to determine whether to perform event filtering according to the obtained interrupt event and the bus event, and control the output of a corresponding busy signal after filtering;

[0010] The timer is capable of generating a count pulse signal and a count overflow signal for controlling the frequency of the sampling operation of the busy signal;

[0011] The analysis engine is electrically connected to the event filter and the timer, and is used to perform a timing analysis on the busy signal according to the count pulse signal and the count overflow signal to determine whether to generate an interrupt request for triggering an interrupt controller;

[0012] The control engine is used to configure the counting frequency and counting length of the timer.

[0013] In some embodiments, the monitoring module comprises:

[0014] An interrupt monitor, used to monitor the interrupt signal of the system kernel, and determine whether to output an interrupt event according to the level of the interrupt signal;

[0015] The bus monitor is used to monitor the bus address of the system bus and determine whether a corresponding output bus event occurs based on the relationship between the pre-stored address parameter and the bus address.

[0016] In some embodiments, the level of the interrupt signal is used to indicate whether the system kernel is in an interrupt context state;

[0017] Wherein, when the interrupt signal is at a high level, the system kernel is in an interrupt context state, and the interrupt monitor outputs the interrupt event.

[0018] In some of the embodiments, the relationship between the address parameter pre-stored in the bus monitor and the bus address is used to characterize whether it corresponds to an output bus event;

[0019] When the bus address is equal to the start address in the address parameter, the bus monitor starts to output the bus event accordingly.

[0020] In some of these embodiments, the interrupt request comprises a threshold interrupt request;

[0021] The triggering process of the threshold interrupt request includes: generating the counting pulse signal and the counting overflow signal according to the counting frequency and the counting length, triggering the comparison between the counting of the busy signal and the preset utilization threshold, and determining whether to generate the threshold interrupt request for entering the interrupt processing process.

[0022] In some of the embodiments, the event filter is further used to output the busy signal to an IO port.

[0023] In a second aspect, an embodiment of the present application provides an MCU performance monitoring method, which is implemented based on the MCU performance monitoring system described in any one of the above items, and includes the following steps:

[0024] Monitor the interrupt signal of the system kernel and determine whether it corresponds to the output interrupt event;

[0025] monitoring a bus address of a system bus and determining whether it corresponds to an output bus event;

[0026] Determining whether to perform event filtering according to the interrupt event and the bus event obtained, and controlling the output of a corresponding busy signal after filtering;

[0027] Generate counting pulse signal and counting overflow signal regularly;

[0028] The busy signal is analyzed in a timing manner according to the count pulse signal and the count overflow signal to determine whether an interrupt request for triggering an interrupt controller is generated.

[0029] In some embodiments, monitoring the interrupt signal of the system kernel and determining whether a corresponding output interrupt event occurs includes:

[0030] Monitoring the interrupt signal of the system kernel and determining the level of the interrupt signal;

[0031] When the interrupt signal is at a high level, the interrupt event is output accordingly.

[0032] In some embodiments, monitoring the bus address of the system bus and determining whether it corresponds to an output bus event includes:

[0033] monitoring a bus address of the system bus and comparing the bus address with a pre-stored address parameter;

[0034] When the bus address is equal to the start address in the address parameter, the bus event starts to be output.

[0035] In some embodiments, the address parameters include a start address and an end address;

[0036] When the bus address is equal to the start address, the bus monitor outputs a bus event.

[0037] In some embodiments, the determining whether to perform filtering when outputting the interrupt event and the bus event, and controlling the output of a corresponding busy signal after filtering, includes:

[0038] Determining whether to enable the interrupt event and / or the bus event;

[0039] Output the corresponding busy signal according to the enable result.

[0040] In some embodiments, the performing timing analysis on the busy signal according to the count pulse signal and the count overflow signal to determine whether to generate an interrupt request for triggering an interrupt controller includes:

[0041] Add counting according to the counting frequency to generate a counting pulse signal matching the counting value;

[0042] Accumulating the count of the busy signal in each count pulse signal with the count length as a period, and generating the count overflow signal when the count value reaches the count length;

[0043] Determining, at each of the count overflow signals, whether a threshold of the busy signal exceeds a pre-configured usage threshold;

[0044] If exceeded, a corresponding threshold interrupt request is generated.

[0045] Technical effect of the present invention: The present invention determines whether the system is in a busy state by automatically monitoring the interrupt status and code running address of the system, and analyzes the busy signal output by the event filter to determine whether to make an interrupt processing. There is no need to add a large number of idle functions to occupy the computing resources of the processing core, thereby ensuring the real-time performance of the system and being less prone to errors.

[0046] Further features and aspects of the present disclosure will become apparent from the following detailed description of exemplary embodiments with reference to the attached drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate exemplary embodiments, features, and aspects of the disclosure and, together with the description, serve to explain the principles of the disclosure.

[0048] Figure 1 Shown is a structural block diagram of an MCU performance monitoring system according to an embodiment of the present application;

[0049] Figure 2 Shown is a busy signal waveform timing diagram of an embodiment of the present application;

[0050] Figure 3 The following is a flowchart of the MCU performance monitoring system according to an embodiment of the present application;

[0051] Figure 4 A flow chart of a method for monitoring MCU performance according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0052] Various exemplary embodiments, features and aspects of the present disclosure will be described in detail below with reference to the accompanying drawings. The same reference numerals in the accompanying drawings represent elements with the same or similar functions. Although various aspects of the embodiments are shown in the accompanying drawings, the drawings are not necessarily drawn to scale unless otherwise specified.

[0053] The word “exemplary” is used exclusively herein to mean “serving as an example, example, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.

[0054] In addition, in order to better illustrate the present disclosure, numerous specific details are given in the following specific embodiments. It should be understood by those skilled in the art that the present disclosure can also be implemented without certain specific details. In some examples, methods, means, components and circuits well known to those skilled in the art are not described in detail in order to highlight the subject matter of the present disclosure.

[0055] In the prior art, in order to enable the MCU performance to meet higher usage requirements, the performance of the MCU is dynamically adjusted according to the utilization rate of the processing core. When the utilization rate is low, the performance is reduced to reduce losses. When the utilization rate is high, the performance is improved or non-essential tasks are stopped to meet the smooth processing of real-time and non-real-time tasks. Since the prior art implements the above process by adding idle functions at the start and end positions of interrupts or non-real-time tasks and controlling the output of the IO port, a large number of idle functions will be added to different interrupts. The judgment and mutual exclusion processing logic of the idle function is complex and time-consuming, and it will take up a lot of code space, increase the difficulty of development, and be more prone to errors. In addition, if the frequency of the timer interrupt is too high, it will occupy a large amount of processing core computing resources. If the frequency of the timer interrupt is too low, it will not be possible to monitor the changes in the utilization rate of the processing core in time.

[0056] Embodiment 1

[0057] The present application embodiment provides a MCU performance monitoring system, Figure 1 is a structural block diagram of an MCU performance monitoring system according to an embodiment of the present application, such as Figure 1As shown, the monitoring system includes a control engine 100 and an interrupt monitor 200, a bus monitor 300, an event filter 400, a timer 500 and an analysis engine 600 controlled by the control engine 100; the interrupt monitor 200 is used to monitor the interrupt signal of the system kernel and determine whether it corresponds to an output interrupt event; the bus monitor 300 is used to monitor the bus address of the system bus and determine whether it corresponds to an output bus event; the event filter 400 is electrically connected to the interrupt monitor 200 and the bus monitor 300, and is used to determine whether to perform event filtering according to the obtained interrupt event and bus event, and control the output of the corresponding busy signal after filtering; the timer 500 can generate a counting pulse signal and a counting overflow signal, and is used to control the sampling operation and frequency of the busy signal; the analysis engine 600 is electrically connected to the event filter 400 and the timer 500, and is used to perform a timing analysis on the busy signal according to the counting pulse signal and the counting overflow signal, and determine whether to generate an interrupt request for triggering the interrupt controller; the control engine is used to configure the counting frequency and counting length of the timer.

[0058] The performance monitoring system of the present embodiment includes a control engine 100, an interrupt monitor 200, a bus monitor 300, an event filter 400, a timer 500 and an analysis engine 600 electrically connected to the control engine 100. The control engine 100 contains configuration registers and control signals of various modules of the performance monitoring system, and is responsible for controlling the reset, configuration and operation of the monitoring system. Specifically, the opening and closing of the interrupt monitor 200, the bus monitor 300 and the event filter 400 are controlled based on the control engine 100. When the control engine 100 controls the interrupt monitor 200 and the bus monitor 300 to be turned on, the interrupt monitor 200 can monitor the interrupt signal of the system kernel, and the bus monitor 300 can monitor the bus address of the system bus, and determine whether to output a busy signal correspondingly according to the specific situation of the monitored interrupt signal and the bus address.

[0059] It should be noted here that when the MCU system is running, the system kernel obtains the code stored in the code memory through the system bus. To obtain the code in the memory, the address of the memory on the bus is required. In view of this, this embodiment designs a bus monitor 300 in the performance monitoring system, which is responsible for monitoring the bus address of the system bus, that is, the code running address.

[0060] It should also be noted that, in the case where a busy signal can be output, the event filter 400 selects which events as the judgment conditions for whether the system is busy, that is, whether interrupt events and / or bus events are enabled, and the event filter 400 can control the busy signal to be sent to the analysis engine. Not only that, the control engine 100 can control the opening and closing of the event filter 400, and control whether the event filter 400 enables interrupt events and / or bus events when it is turned on, thereby determining the output busy signal. Specifically, if the event filter 400 is configured to not enable interrupt events and bus events, a fixed low level is output, indicating that the system is in an idle state, that is, the interrupt events and bus events are filtered out; if the event filter 400 is configured to enable interrupt events and bus events, the busy signal is the superposition output of the valid areas of the two events; if the event filter 400 only enables one of the interrupt events and bus events, the level of the busy signal is the same as the enabled signal. Figure 2 As shown, if the event filter 400 is configured to enable interrupt events and bus events at the same time, the busy signal is the superposition output of the valid areas of the two events, and the busy signal is sampled under the triggering of the count pulse of the timer 500. If the busy signal is valid when the count pulse occurs, the count value is increased by 1. And when the event filter 400 is turned off, the output is fixed at a low level, indicating that the system is in an idle state. Among them, when the event filter 400 can output a busy signal, the analysis engine 600 regularly analyzes the busy signal to determine whether to trigger a corresponding interrupt request.

[0061] It can be seen that this embodiment determines whether the system is in a busy state by automatically monitoring the system's interrupt status and code execution address, and analyzes the busy signal output by the event filter 400 to determine whether to perform interrupt processing, without adding a large number of idle functions to occupy the computing resources of the processing core.

[0062] In some of the embodiments, the level of the interrupt signal is used to indicate whether the system kernel is in the interrupt context state; when the interrupt signal is at a high level, the system kernel is in the interrupt context state, and the interrupt monitor 200 outputs an interrupt event.

[0063] It should be noted that the input end of the interrupt monitor 200 is electrically connected to the output end of the system kernel, and is used to receive the interrupt signal output by the system kernel, and to determine whether the corresponding output interrupt event is based on the level of the interrupt signal. Among them, based on the interrupt monitor 200, it is determined whether the system is in a state of processing the interrupt context. Specifically, the interrupt signal from the system kernel is a level signal, and the high level of the interrupt signal indicates that the system is in the interrupt context state, and the low level of the interrupt signal indicates that the system kernel is in the non-interrupt context state. The control engine 100 is used to control the opening and closing of the interrupt monitor 200. In the open state, the interrupt controller outputs an interrupt event when the system kernel enters the interrupt context, that is, outputs a high level, and clears the interrupt event when the system kernel exits the interrupt context, that is, outputs a low level. At the same time, in the closed state, the interrupt monitor 200 outputs a fixed low level, indicating that there is no interrupt event.

[0064] In some embodiments, the relationship between the address parameter pre-stored in the bus monitor 300 and the bus address is used to indicate whether a corresponding bus event is output; wherein, when the bus address is equal to the starting address in the address parameter, the bus monitor 300 starts to output the bus event accordingly.

[0065] In this embodiment, the input end of the bus monitor 300 is electrically connected to the system bus for receiving the bus address of the system bus. The bus monitor 300 stores two address parameters, namely the start address and the end address, and these two parameters are configured by the control engine 100. In addition, the control engine 100 is also used to control the opening and closing of the bus monitor 300. When the bus monitor 300 is turned on, when the bus address of the system is equal to the start address of the bus monitor 300, the bus monitor 300 starts to output bus events, that is, outputs a high level; when the bus address of the system is equal to the end address of the bus monitor 300, the bus monitor 300 clears the bus event, that is, outputs a low level. When the bus monitor 300 is turned off, the bus monitor 300 outputs a fixed low level, indicating that there is no bus event. That is, the bus monitor 300 needs to be configured as the bus start address and the bus end address of the bus access behavior that needs to be monitored, outputs the bus event when the bus address is equal to the start address of the bus monitor 300, and clears the bus event when the bus address is equal to the end address of the bus monitor 300.

[0066] In some of the embodiments, the interrupt request includes a threshold interrupt request; the triggering process of the threshold interrupt request includes: generating a counting pulse signal and a counting overflow signal according to the counting frequency and the counting length, triggering a comparison between the count of the busy signal and a preset utilization threshold, and determining whether to generate a threshold interrupt request for entering the interrupt processing flow.

[0067] It should be noted that the timer 500 of the present embodiment is electrically connected to the control engine 100 and the analysis engine 600 at the same time, and the setting of the timer 500 is used to trigger the analysis engine 600 to analyze the busy signal regularly, and then the analysis engine controls whether to generate an interrupt request. Among them, the interrupt request includes a count overflow interrupt request and a threshold interrupt request. Specifically, the timer 500 controls the counting frequency and the counting length, and regularly generates a count pulse signal of the count overflow signal, which is used to trigger the analysis engine 600 to analyze the busy signal. Among them, the control engine 100 is used to configure the counting frequency and the counting length of the timer 500, and the timer 500 counts up at the counting frequency, and generates a count pulse signal for each increase of the count value by 1, which is a high-level pulse. It should be noted that the count overflow interrupt request generates a count overflow signal when the count value reaches the count length, which is also a high-level pulse, and clears the count value to count from the beginning.

[0068] It should also be noted that, in this embodiment, the start and stop of the timer 500 is controlled by the control engine 100, and specifically, the timer 500 needs to be started before the analysis engine 600 is started. And the control engine is also used to configure the usage threshold threshold of the analysis engine, including the upper limit of the usage threshold and the lower limit of the usage threshold. The analysis engine 600 accumulates the busy signal count at each counting pulse signal, and calculates the usage of the processing core with a count overflow as a cycle and clears the busy signal count. The analysis engine 600 determines whether the busy signal count exceeds the usage threshold at each count overflow signal. Among them, if the busy signal count exceeds any one of the upper limit of the usage threshold or the lower limit of the usage threshold, a corresponding interrupt request, i.e., a threshold interrupt request, is generated, and a high-level pulse is output.

[0069] It should also be noted that the control engine 100 of this embodiment can also configure the analysis engine 600 to be in a fast threshold judgment mode, wherein the analysis engine 600 compares the busy signal count with the usage threshold at each count pulse signal in the fast threshold judgment mode. If the busy signal count has been detected to exceed the usage threshold in less than one count overflow cycle, a corresponding interrupt request is triggered.

[0070] It can be seen that if the processing core has been running within the utilization rate threshold during the system operation, the MCU software does not need to do any processing, while meeting the purpose of monitoring the utilization rate of the processing core and not affecting the real-time requirements of the system. By analyzing the time distribution data of the system in the idle or busy state, the utilization rate of the processing core by interrupts and non-real-time tasks can be obtained. The analysis engine 600 can set the trigger interrupt request according to the utilization rate threshold to achieve the requirement of quickly adjusting the MCU performance, and make the system work safer and more stable by analyzing and optimizing the utilization rate of the processing core.

[0071] In some of the embodiments, the event filter is further configured to output a busy signal to the IO port.

[0072] In this embodiment, the event filter 400 can also control whether the busy signal is output to the IO port. That is, the busy state of the performance monitoring system supports outputting the busy signal to the IO port of the MCU, which is convenient for users to observe in real time. The busy signal can also be used as a signal for external dynamic perception of the working state of the MCU. The performance requirements for the MCU can be significantly reduced through peak-shifting processing, thereby reducing costs.

[0073] It should be noted that when the performance monitoring is performed based on the above system, initial configuration is required, that is, initial configuration of the timer 500 , the interrupt monitor 200 , the bus monitor 300 , the event filter 400 and the analysis engine 600 .

[0074] like Figure 3 As shown, the specific usage process will be described in detail below.

[0075] 1. Initialize timer 500;

[0076] Configure the counting frequency and overflow period of timer 500. In the scenario where accurate performance analysis is required, the counting frequency is increased. Since the higher the counting frequency, the faster the busy signal is sampled, the complete busy signal can be sampled when the counting frequency is greater than or equal to the frequency of the bus and the system. In the scenario where performance needs to be monitored quickly, the counting frequency can be increased and a shorter overflow period can be configured. A shorter overflow period can trigger an interrupt request more quickly. In the scenario where low power consumption is required, the counting frequency can be reduced and a longer overflow period can be configured. A longer overflow period can reduce the triggering frequency of interrupts, thereby reducing power consumption.

[0077] 2. Initialize the interrupt monitor 200;

[0078] The configuration enables the interrupt monitor 200, and if the system is in the processing interrupt context state, the interrupt event is output. If the configuration does not enable the interrupt monitor 200 or the system is in the non-processing interrupt context state, the interrupt event is cleared.

[0079] 3. Initialize the system bus monitor 300;

[0080] The bus start address and bus end address of the bus access behavior to be monitored by the bus monitor 300 are configured. When the bus address is equal to the start address of the bus monitor 300, the bus event is output, and when the bus address is equal to the end address of the bus monitor 300, the bus event is cleared.

[0081] 4. Initialize event filter 400;

[0082] Configure whether to enable interrupt events or bus events. The unfiltered events will be superimposed together and output as busy signals. Also, configure whether to output the busy signal to the IO port.

[0083] 5. Initialize the analysis engine 600;

[0084] Configure the upper and lower usage thresholds of the analysis engine 600. Configure whether to enable the fast threshold judgment mode. Configure whether to enable the threshold interrupt and the count overflow interrupt. The analysis engine 600 accumulates the busy signal count at each counting pulse, and calculates the utilization of the processing core with a count overflow as a cycle. The analysis engine 600 determines whether the busy signal count exceeds the usage threshold at each count overflow signal. The analysis engine 600 controls whether an interrupt request is generated when the busy signal count exceeds the usage threshold. In addition, it can also be configured as a fast threshold judgment mode to compare the busy signal count and the usage threshold at each counting pulse. If it has been detected that the busy signal count exceeds the usage threshold in less than one count overflow cycle, a threshold interrupt request is triggered.

[0085] 6. Interrupt handling;

[0086] If the interrupt request output of the analysis engine 600 is enabled, the corresponding threshold interrupt request and count overflow interrupt request are processed in the interrupt. The software can adjust the system performance and the processing priority of the task as needed.

[0087] In addition, the present application also provides the use process of the system's interrupt monitoring function and bus monitoring function, which will be explained below respectively.

[0088] The following is an example of using the interrupt monitoring function:

[0089] (1) Initialize timer 500 and configure the counting frequency and overflow period of timer 500.

[0090] (2) Initialize the interrupt monitor 200 and configure and enable the interrupt monitor 200.

[0091] (3) Initialize the event filter 400, configure the enable interrupt event, and start the busy signal output to the IO port.

[0092] (4) Initialize the analysis engine 600, configure the upper and lower usage thresholds of the analysis engine 600, configure to enable the fast threshold judgment mode, and configure to enable the interrupt request output of the analysis engine 600.

[0093] (5) Interrupt signal processing: After entering the interrupt context, the MCU core outputs an interrupt signal, i.e., a high level. Since the interrupt monitor 200 is in the on state, it outputs an interrupt event at a high level. The event filter 400 outputs a busy signal, i.e., a high level, when an interrupt event occurs. The analysis engine 600 counts the busy signal and triggers an interrupt request when the count exceeds the usage threshold.

[0094] (6) The software processes the interrupt signal. After the interrupt request is triggered, the software enters the interrupt processing flow. The software adjusts the system performance and task processing priority as needed.

[0095] Among them, in the above (3), you can also choose not to output the busy signal to the IO port, and (4) you can also choose not to enable the fast threshold judgment mode and interrupt request output. The specific selection and configuration can be made according to actual needs.

[0096] The following is an example of using the bus monitoring function:

[0097] (1) Initialize timer 500 and configure the counting frequency and overflow period of timer 500.

[0098] (2) Initialize the bus monitor 300, start the bus monitor 300, and configure the bus start address and bus end address of the bus access behavior that the bus monitor 300 needs to monitor.

[0099] (3) Initialize the event filter 400, configure the enable bus event, and start the busy signal output to the IO port.

[0100] (4) Initialize the analysis engine 600, configure the upper and lower usage thresholds of the analysis engine 600, configure to enable the fast threshold judgment mode, and configure to enable the interrupt request output of the analysis engine 600.

[0101] (5) Interrupt signal processing: the bus monitor 300 outputs a bus event, i.e., a high level, when the code runs between the bus start address and the bus end address. The event filter 400 outputs a busy signal, i.e., a high level, when a bus event occurs. The analysis engine 600 counts the busy signal and triggers an interrupt request when the count exceeds the usage threshold.

[0102] (6) The software processes the interrupt signal. After the interrupt request is triggered, the software enters the interrupt processing flow. The software adjusts the system performance and task processing priority as needed.

[0103] Among them, in the above (3), you can also choose not to output the busy signal to the IO port, and (4) you can also choose not to enable the fast threshold judgment mode and interrupt request output. The specific selection and configuration can be made according to actual needs.

[0104] In summary, after completing the initialization configuration of the performance monitoring system, if the processing core has been running within the utilization rate threshold range, the MCU software does not need to do any processing. Compared with the timed interrupt technology of the prior art, it satisfies the requirement of simultaneously monitoring the utilization rate of the processing core, does not affect the real-time performance of the system, and reduces the occupation of the processing core computing resources. At the same time, the system of the present application can also be adapted to low-power application scenarios, supports interrupts and fast threshold judgment modes, so that the system can quickly perceive changes in the utilization rate of the processing core and make corresponding adjustments. Not only that, it can also obtain accurate processing core utilization information, monitor the workload of the processing core in real time, and ensure the safe and stable execution of tasks.

[0105] Embodiment 2

[0106] like Figure 4 As shown, in the second aspect, the embodiment of the present application provides an MCU performance monitoring method, which is implemented based on any of the above MCU performance monitoring systems. Since the principle of the MCU performance monitoring method of the embodiment of the present disclosure is the same or similar to the working principle of the MCU performance monitoring system of the embodiment of the present disclosure, the repeated parts will not be repeated. The method comprises the following steps:

[0107] S100, monitoring the interrupt signal of the system kernel, and determining whether it corresponds to an output interrupt event;

[0108] S200, monitoring the bus address of the system bus, and determining whether it corresponds to an output bus event;

[0109] S300, judging whether to perform event filtering according to the obtained interrupt event and bus event, and controlling the output of a corresponding busy signal after filtering;

[0110] S400, generating a counting pulse signal and a counting overflow signal at a regular time;

[0111] S500 , performing timing analysis on the busy signal according to the counting pulse signal and the counting overflow signal to determine whether an interrupt request for triggering an interrupt controller is generated.

[0112] In some embodiments, monitoring the interrupt signal of the system kernel and determining whether to output a corresponding interrupt event include: monitoring the interrupt signal of the system kernel and determining the level of the interrupt signal; when the interrupt signal is at a high level, outputting a corresponding interrupt event.

[0113] In some embodiments, the bus address of the system bus is monitored and it is determined whether it corresponds to an output bus event, including: monitoring the bus address of the system bus and comparing the bus address with a pre-stored address parameter; when the bus address is equal to the starting address in the address parameter, starting to output the bus event.

[0114] In some of the embodiments, when outputting interrupt events and bus events, determining whether to perform filtering, and controlling the output of corresponding busy signals after filtering, includes: determining whether to enable filtering of interrupt events and / or bus events; and outputting corresponding busy signals according to the enabling result.

[0115] In some of the embodiments, a busy signal is analyzed based on a counting frequency and a counting length to determine whether to generate an interrupt request for triggering an interrupt controller, including: adding counts based on the counting frequency to generate a counting pulse signal that matches the counting value; accumulating the busy signal count at each counting pulse signal with the counting length as a period, and generating a counting overflow signal when the counting value reaches the counting length; determining at each counting overflow signal whether a threshold of the busy signal exceeds a pre-configured utilization threshold; if so, generating a corresponding threshold interrupt request.

[0116] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementation modes, and this embodiment will not be described in detail here.

[0117] Those skilled in the art should understand that the technical features of the above-described embodiments may be arbitrarily combined. To make the description concise, not all possible combinations of the technical features in the above-described embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0118] The above-mentioned embodiments only express several implementation methods of the present invention, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for ordinary technicians in this field, several variations and improvements can be made without departing from the concept of the present invention, and these all belong to the protection scope of the present invention. Therefore, the protection scope of the patent of the present invention shall be subject to the attached claims.

[0119] Unless otherwise defined, the technical terms or scientific terms involved in this application should be understood by people with ordinary skills in the technical field to which this application belongs. The words "one", "one", "the" and the like involved in this application do not indicate a quantitative limitation and may represent the singular or plural. The terms "include", "comprise", "have" and any of their variations involved in this application are intended to cover non-exclusive inclusions. The words "connect", "connected", "coupled" and the like involved in this application are not limited to physical or mechanical connections, but include electrical connections, whether direct or indirect. The "multiple" involved in this application refers to two or more, and "and / or" describes the association relationship of associated objects, indicating that three relationships may exist. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. The terms "first", "second", "third" and the like involved in this application are merely to distinguish similar objects and do not represent a specific ordering of objects.

[0120] The above embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but the limitation of the scope of the invention patent cannot be understood as a result. It should be pointed out that, for a person of ordinary skill in the art, several modifications or improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the patent of the present application shall be subject to the attached claims.

Claims

1. A MCU performance monitoring system, characterized in that: comprising a control engine and an interrupt monitor, a bus monitor, an event filter, a timer and an analysis engine controlled by the control engine; The interrupt monitor is used to monitor the interrupt signal of the system kernel and determine whether it corresponds to an output interrupt event; The bus monitor is used to monitor the bus address of the system bus and determine whether it corresponds to an output bus event; The event filter is electrically connected to the interrupt monitor and the bus monitor, and is used to determine whether to perform event filtering according to the obtained interrupt event and the bus event, and control the output of a corresponding busy signal after filtering; The timer is capable of generating a count pulse signal and a count overflow signal for controlling the frequency of the sampling operation on the busy signal; The analysis engine is electrically connected to the event filter and the timer, and is used to perform a timing analysis on the busy signal according to the count pulse signal and the count overflow signal to determine whether to generate an interrupt request for triggering an interrupt controller; The control engine is used to configure the counting frequency and counting length of the timer.

2. The MCU performance monitoring system according to claim 1, characterized in that: The level of the interrupt signal is used to indicate whether the system kernel is in an interrupt context state; Wherein, when the interrupt signal is at a high level, the system kernel is in an interrupt context state, and the interrupt monitor outputs the interrupt event.

3. The MCU performance monitoring system according to claim 1, characterized in that: The relationship between the address parameter pre-stored in the bus monitor and the bus address is used to indicate whether it corresponds to an output bus event; When the bus address is equal to the start address in the address parameter, the bus monitor starts to output the bus event accordingly.

4. The MCU performance monitoring system according to claim 1, characterized in that: The interrupt request comprises a threshold interrupt request; The triggering process of the threshold interrupt request includes: generating the counting pulse signal and the counting overflow signal according to the counting frequency and the counting length, triggering the comparison between the counting of the busy signal and the preset utilization threshold, and determining whether to generate the threshold interrupt request for entering the interrupt processing process.

5. The MCU performance monitoring system according to any one of claims 1 to 4, characterized in that: The event filter is further used to output the busy signal to the IO port.

6. A MCU performance monitoring method, implemented based on the MCU performance monitoring system according to any one of claims 1 to 5, characterized in that: The steps include: Monitor the interrupt signal of the system kernel and determine whether it corresponds to the output interrupt event; monitoring a bus address of a system bus and determining whether it corresponds to an output bus event; Determining whether to perform event filtering according to the interrupt event and the bus event obtained, and controlling the output of a corresponding busy signal after filtering; Generate counting pulse signal and counting overflow signal regularly; The busy signal is analyzed in a timing manner according to the count pulse signal and the count overflow signal to determine whether an interrupt request for triggering an interrupt controller is generated.

7. The MCU performance monitoring method according to claim 6, characterized in that: The monitoring system kernel interrupt signal and determining whether it corresponds to an output interrupt event include: Monitoring the interrupt signal of the system kernel and determining the level of the interrupt signal; When the interrupt signal is at a high level, the interrupt event is output accordingly.

8. The MCU performance monitoring method according to claim 6, characterized in that: The monitoring of the bus address of the system bus and determining whether it corresponds to an output bus event includes: monitoring a bus address of the system bus and comparing the bus address with a pre-stored address parameter; When the bus address is equal to the start address in the address parameter, the bus event starts to be output.

9. The MCU performance monitoring method according to claim 6, characterized in that: The determining whether to perform filtering when outputting the interrupt event and the bus event, and controlling the output of a corresponding busy signal after filtering, comprises: Determining whether to enable the interrupt event and / or the bus event; Output the corresponding busy signal according to the enable result.

10. The MCU performance monitoring method according to claim 6, characterized in that: The performing timing analysis on the busy signal according to the count pulse signal and the count overflow signal to determine whether an interrupt request for triggering an interrupt controller is generated comprises: Add counting according to the counting frequency to generate a counting pulse signal matching the counting value; Accumulating the count of the busy signal in each count pulse signal with the count length as a period, and generating the count overflow signal when the count value reaches the count length; Determining, at each of the count overflow signals, whether a threshold of the busy signal exceeds a pre-configured usage threshold; If exceeded, a corresponding threshold interrupt request is generated.

Images