ARM9 platform management method and system based on Linux system

Abstract

The invention discloses an ARM9 platform management method and system based on a Linux system, and relates to the technical field of platform management. Priority sorting is performed on all interrupt requests, and an interrupt request sorting table is generated. After the priority sorting of all interrupt requests is completed, when multiple interrupt requests are triggered at the same time, the management order of the interrupt requests is selected according to the interrupt request sorting table. When the interrupt request is selected for management, the interrupt service program is started first, and the callback function quickly executes the corresponding processing logic, and all interrupt requests are divided into real-time tasks and non-real-time tasks. The management system ensures that high-priority interrupts are processed in time through priority sorting and the interrupt request sorting table, and quickly starts the interrupt service program and the rapid execution of the callback function to improve the efficiency of interrupt processing, reduce the context switching time loss, not only improve the management efficiency, but also reasonably use the management resources, and improve the certainty and efficiency of task execution.

Description

Technical Field

[0001] The present invention relates to the technical field of platform management, and in particular to an ARM9 platform management method and system based on a Linux system. Background Art

[0002] The ARM9 platform management system belongs to the field of power applications and is designed for real-time system applications of distributed power equipment terminal platforms. The management system is based on the Linux platform and integrates the NUC980 terminal chip. It is mainly used to realize real-time monitoring and management of power equipment. The platform supports real-time analog quantity acquisition and calculation, as well as digital quantity acquisition and resolution identification, to ensure accurate and reliable operation and data processing in complex power environments.

[0003] The prior art has the following deficiencies:

[0004] 1. The existing management system does not have effective interrupt priority management, which causes low-priority interrupt requests to affect the processing of high-priority interrupt requests, and the management efficiency of the ARM9 platform is reduced due to the long response time of the interrupt handler or the context switching between interrupt handlers.

[0005] 2. The mixed processing of real-time tasks and non-real-time tasks in the ARM9 platform results in insufficient response time for real-time tasks, which not only wastes management resources of the management system, but also reduces the certainty and efficiency of task execution of the management system.

[0006] Based on this, the present application proposes an ARM9 platform management method and system based on the Linux system, which ensures that high-priority interrupts are processed in a timely manner through priority sorting and interrupt request sorting tables, and quickly starts interrupt service programs and quickly executes callback functions to improve the efficiency of interrupt processing, reduce context switching time loss, divide interrupt requests into real-time tasks and non-real-time tasks, ensure that real-time tasks are processed first, and non-real-time tasks run in the background at the same time, which not only improves the management efficiency of the ARM9 platform, but also reasonably utilizes management resources and improves the certainty and efficiency of task execution. Summary of the invention

[0007] The purpose of the present invention is to provide an ARM9 platform management method and system based on a Linux system to solve the deficiencies in the background technology.

[0008] In order to achieve the above object, the present invention provides the following technical solution: an ARM9 platform management method based on a Linux system, the management method comprising the following steps:

[0009] The management system obtains all interrupt requests of the ARM9 platform, prioritizes all interrupt requests, generates an interrupt request ranking table, and registers the corresponding interrupt callback function after completing the priority ranking of all interrupt requests;

[0010] When multiple interrupt requests are triggered at the same time, the management order of the interrupt requests is selected according to the interrupt request sorting table. When the interrupt request is selected for management, the interrupt service program is started first, and the callback function executes the corresponding processing logic;

[0011] All interrupt requests are divided into real-time tasks and non-real-time tasks. After the interrupt service program of the real-time task is executed, the real-time task is shared with the non-real-time task through the inter-process communication mechanism. The management system runs the non-real-time task in the background based on the Linux system and decides whether to execute the corresponding subsequent tasks according to the conditions of the real-time task.

[0012] In a preferred embodiment, the management system obtains all interrupt requests of the ARM9 platform, prioritizes all interrupt requests, and generates an interrupt request ranking table, including the following steps:

[0013] The management system obtains all interrupt requests of the ARM9 platform, and obtains the trigger frequency index, importance index and mitigation index of each interrupt request;

[0014] The trigger frequency index, importance index and mitigation index are calculated comprehensively to obtain the priority coefficient, which is expressed as follows: , where is the priority coefficient, is the trigger frequency index, is the importance index, is the mitigation index, , , are the adjustment coefficients of the trigger frequency index, importance index and mitigation index, respectively, and , , All are greater than 0;

[0015] After obtaining the priority coefficients of all interrupt requests, all interrupt requests are sorted from large to small according to the priority coefficients to generate an interrupt request sorting table.

[0016] In a preferred embodiment, selecting the management order of the interrupt requests according to the interrupt request sorting table includes the following steps:

[0017] When multiple interrupt requests are triggered simultaneously, the management order of the interrupt requests is selected according to the positive order of the terminal request sorting table.

[0018] In a preferred embodiment, when an interrupt request is selected for management, the interrupt service routine is started first, and the callback function quickly executes the corresponding processing logic, including the following steps:

[0019] The management system monitors the status of various interrupt requests in real time. When an interrupt request is detected, the interrupt service routine is triggered immediately, and the current CPU context is saved when the interrupt service routine is started;

[0020] The management system closes other interrupt requests and calls the corresponding interrupt callback function to start processing interrupt requests according to the registered interrupt vector table. The callback function contains processing logic, which includes reading data, performing calculations, controlling devices, and recording events.

[0021] After the interrupt processing logic is completed, the interrupt flag is cleared, and the saved CPU context is restored after the callback function is executed. After the current interrupt request is processed, the disabled interrupt request is re-enabled. After the interrupt request is processed, the interrupt service routine returns to the main program to continue executing the interrupted task.

[0022] In a preferred embodiment, the real-time task is shared with the non-real-time task through an inter-process communication mechanism, comprising the following steps:

[0023] Initialize the inter-process communication mechanism, which is used to exchange data between real-time tasks and non-real-time tasks. The inter-process communication mechanism allows different tasks to run in different processes and transfer data through defined channels;

[0024] When the interrupt service routine of the real-time task completes the preliminary data processing, it sends the data to the non-real-time task through the inter-process communication mechanism. The process of sharing data includes the following sub-steps:

[0025] Pack the data processed by the interrupt service program into a data packet in a standard format, and prepare to send it to the non-real-time task. Use the inter-process communication mechanism to send the packed data to the queue or shared memory of the non-real-time task, and notify the non-real-time task through a signal or flag that there is new data to be processed. The non-real-time task receives the data from the real-time task through the inter-process communication mechanism and performs corresponding processing operations, including recording data to a log file, storing data in a database, analyzing and collating data for subsequent tasks or report generation;

[0026] The non-real-time task returns the processed results or feedback information to the real-time task through the inter-process communication mechanism, continuously monitors the data exchange status between the real-time task and the non-real-time task, and optimizes the inter-process communication mechanism according to the actual operation conditions.

[0027] In a preferred embodiment, the data exchange status between the real-time task and the non-real-time task is continuously monitored, and the inter-process communication mechanism is optimized according to the actual operation situation, including the following steps:

[0028] Continuously monitor the data exchange status between real-time tasks and non-real-time tasks. The data exchange status includes the data transmission rate and the data loss rate. Optimize the inter-process communication mechanism according to the actual operation status. The actual operation status includes the processing capacity coefficient of the management system. The processing capacity coefficient, data transmission rate and data loss rate are comprehensively calculated to generate an adjustment index. The expression is: , where To adjust the index, is the processing capacity coefficient, is the data transmission rate, is the data loss rate, , , are the proportional coefficients of processing capacity coefficient, data transmission rate and data loss rate respectively, and , , All are greater than 0;

[0029] After obtaining the adjustment index, the buffer size of the inter-process communication mechanism is adjusted through the adjustment algorithm, which is expressed as: , where is the adjusted buffer size, is the buffer size before adjustment, To adjust the exponent, the adjusted buffer size is applied in the subsequent processing steps of the inter-process communication mechanism.

[0030] In a preferred embodiment, the management system runs non-real-time tasks in the background based on the Linux system, and determines whether to execute corresponding subsequent tasks according to the conditions of the real-time tasks, including the following steps:

[0031] Real-time monitoring data collection;

[0032] Data is collected to the corresponding threshold;

[0033] Check data collection status every minute;

[0034] If the data reaches the threshold, the data processing task is automatically started;

[0035] Logs recording data collection and processing;

[0036] When data collection fails, an alarm email is sent to the administrator.

[0037] In a preferred embodiment, the calculation expression of the importance index is: , where is the importance index, The number of exception events generated by the interrupt request, The total number of exception events generated for all interrupt requests, is the number of devices or subsystems affected by the interrupt request, The maximum number of devices or subsystems affected by the interrupt request. , is the weight coefficient, and .

[0038] In a preferred embodiment, the acquisition logic of the trigger frequency index is: obtaining the trigger frequency and the trigger frequency growth rate of the interrupt request, normalizing the trigger frequency and the trigger frequency growth rate so that the value range of the trigger frequency and the trigger frequency growth rate is mapped to between [0,1], obtaining the normalized value of the trigger frequency and the normalized value of the trigger frequency growth rate, and summing the normalized value of the trigger frequency and the normalized value of the trigger frequency growth rate to obtain the trigger frequency index;

[0039] The logic for obtaining the mitigation index is as follows: obtaining the average processing time of interrupt requests, and obtaining the number of post-dependencies of the interrupt requests, that is, the number of interrupt requests that can be executed only after the execution of the interrupt request, normalizing the average processing time and the number of post-dependencies, mapping the value range of the average processing time and the number of post-dependencies to [0,1], obtaining the normalized value of the average processing time and the normalized value of the number of post-dependencies, and subtracting the normalized value of the number of post-dependencies from the normalized value of the average processing time to obtain the mitigation index.

[0040] ARM9 platform management system based on Linux system, including priority sorting module, interrupt service module, task division and processing module;

[0041] Priority sorting module: obtain all interrupt requests of the ARM9 platform, prioritize all interrupt requests, and generate an interrupt request sorting table;

[0042] Interrupt service module: After completing the priority sorting of all interrupt requests, register the corresponding interrupt callback function. When multiple interrupt requests are triggered at the same time, select the management order of the interrupt requests according to the interrupt request sorting table. When the interrupt request is selected for management, start the interrupt service program first, and the callback function executes the corresponding processing logic;

[0043] Task division and processing module: All interrupt requests are divided into real-time tasks and non-real-time tasks. After the interrupt service program of the real-time task is executed, the real-time task is shared with the non-real-time task through the inter-process communication mechanism, and the non-real-time task is run in the background based on the Linux system. It also decides whether to execute the corresponding subsequent tasks based on the conditions of the real-time task.

[0044] In the above technical solution, the technical effects and advantages provided by the present invention are:

[0045] 1. The present invention prioritizes all interrupt requests and generates an interrupt request ranking table. After completing the priority ranking of all interrupt requests, the corresponding interrupt callback function is registered. When multiple interrupt requests are triggered at the same time, the management order of the interrupt requests is selected according to the interrupt request ranking table. When the interrupt request is selected for management, the interrupt service program is started first, and the callback function quickly executes the corresponding processing logic, and all interrupt requests are divided into real-time tasks and non-real-time tasks. After the interrupt service program of the real-time task is executed, the real-time task is shared with the non-real-time task through the inter-process communication mechanism, and the management system runs the non-real-time task in the background based on the Linux system, and decides whether to execute the corresponding subsequent task according to the conditions of the real-time task. The management system ensures that high-priority interrupts are processed in time through priority sorting and interrupt request ranking table, and quickly starts the interrupt service program and the rapid execution of the callback function to improve the efficiency of interrupt processing, reduce the context switching time loss, divide the interrupt request into real-time tasks and non-real-time tasks, ensure that the real-time task is processed first, and the non-real-time task runs in the background at the same time, which not only improves the management efficiency of the ARM9 platform, but also reasonably utilizes management resources and improves the certainty and efficiency of task execution;

[0046] 2. The present invention continuously monitors the data exchange status between real-time tasks and non-real-time tasks, including the data transmission rate and the data loss rate, optimizes the inter-process communication mechanism according to the actual operation conditions, including the processing capacity coefficient of the management system, and comprehensively calculates the processing capacity coefficient, the data transmission rate and the data loss rate to generate an adjustment index. After obtaining the adjustment index, the buffer size of the inter-process communication mechanism is adjusted through an adjustment algorithm, and the adjusted buffer size is applied to the subsequent processing steps of the inter-process communication mechanism. This is conducive to improving the data processing performance of the management system. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0048] Figure 1 The present invention is a flow chart of the method. DETAILED DESCRIPTION

[0049] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0050] Example 1: Please refer to Figure 1 As shown, the ARM9 platform management method based on the Linux system described in this embodiment includes the following steps:

[0051] The management system obtains all interrupt requests of the ARM9 platform, prioritizes all interrupt requests, and generates an interrupt request sorting table. Priority sorting prevents other low-priority interrupt requests from affecting high-priority interrupt requests. After completing the priority sorting of all interrupt requests, the corresponding interrupt callback function is registered. When multiple interrupt requests are triggered at the same time, the management order of the interrupt requests is selected according to the interrupt request sorting table. When an interrupt request is selected for management, the interrupt service program is started first, and the callback function quickly executes the corresponding processing logic, dividing all interrupt requests into real-time tasks and non-real-time tasks. After the interrupt service program of the real-time task is executed, the real-time task is shared with the non-real-time task through the inter-process communication mechanism, and the management system runs non-real-time tasks in the background based on the Linux system, and decides whether to execute the corresponding subsequent tasks according to the conditions of the real-time task.

[0052] This application prioritizes all interrupt requests and generates an interrupt request ranking table. After completing the priority ranking of all interrupt requests, the corresponding interrupt callback function is registered. When multiple interrupt requests are triggered at the same time, the management order of the interrupt requests is selected according to the interrupt request ranking table. When the interrupt request is selected for management, the interrupt service program is started first, and the callback function quickly executes the corresponding processing logic, and all interrupt requests are divided into real-time tasks and non-real-time tasks. After the interrupt service program of the real-time task is executed, the real-time task is shared with the non-real-time task through the inter-process communication mechanism, and the management system runs the non-real-time task in the background based on the Linux system, and decides whether to execute the corresponding subsequent task according to the conditions of the real-time task. The management system ensures that high-priority interrupts are processed in time through priority sorting and interrupt request ranking table, and quickly starts the interrupt service program and the rapid execution of the callback function to improve the efficiency of interrupt processing, reduce the context switching time loss, divide the interrupt request into real-time tasks and non-real-time tasks, ensure that the real-time task is processed first, and the non-real-time task runs in the background, which not only improves the management efficiency of the ARM9 platform, but also reasonably utilizes management resources and improves the certainty and efficiency of task execution.

[0053] Embodiment 2: The management system obtains all interrupt requests of the ARM9 platform, prioritizes all interrupt requests, and generates an interrupt request ranking table. The priority ranking prevents other low-priority interrupt requests from affecting high-priority interrupt requests, including the following steps:

[0054] The management system obtains all interrupt requests of the ARM9 platform, and obtains the trigger frequency index, importance index and mitigation index of each interrupt request;

[0055] The trigger frequency index, importance index and mitigation index are calculated comprehensively to obtain the priority coefficient, which is expressed as follows: , where is the priority coefficient, is the trigger frequency index, is the importance index, is the mitigation index, , , are the adjustment coefficients of the trigger frequency index, importance index and mitigation index, respectively, and , , All are greater than 0;

[0056] After obtaining the priority coefficients of all interrupt requests, all interrupt requests are sorted from large to small according to the priority coefficients to generate an interrupt request sorting table. The higher the interrupt request is ranked in the interrupt request sorting table, the higher the priority of the interrupt request is, and the more priority and attention it needs.

[0057] The logic for obtaining the trigger frequency index is as follows: obtain the trigger frequency and the trigger frequency growth rate of the interrupt request, normalize the trigger frequency and the trigger frequency growth rate, map the value range of the trigger frequency and the trigger frequency growth rate to [0,1], obtain the normalized value of the trigger frequency and the normalized value of the trigger frequency growth rate, sum the normalized value of the trigger frequency and the normalized value of the trigger frequency growth rate to obtain the trigger frequency index. The larger the trigger frequency index, the larger the trigger frequency and the trigger frequency growth rate of the interrupt request, that is, the higher the priority of the interrupt request. The specific reasons are as follows:

[0058] 1) Frequent triggering indicates high urgency

[0059] When the trigger frequency of an interrupt request is high, it usually means that the interrupt processing task occupies a more important position in the system. For example, the high frequency update of sensor data may mean that timely processing and response are required to ensure the real-time and accuracy of the data. Therefore, frequently triggered interrupt requests often have a higher urgency, and the priority should be increased accordingly to avoid data loss or delayed response;

[0060] 2) Optimal configuration of system resources

[0061] Interrupt requests with high triggering frequency may cause backlog and delay of system resources if not processed in time. For example, if an interrupt request is frequently triggered but not processed in time, data may accumulate in the system buffer, causing buffer overflow or resource shortage. Therefore, in order to ensure the effective use of system resources, it is necessary to give priority to processing these frequently triggered interrupt requests to ensure system stability and reasonable allocation of resources.

[0062] 3) Reduce waiting time

[0063] Frequently triggered interrupt requests, if they have a low priority, may cause their waiting time to be too long, affecting the overall performance of the system. By increasing the priority of such interrupt requests, their waiting time can be reduced, ensuring that key tasks can be executed in time, thereby improving the response speed and overall efficiency of the system;

[0064] 4) Avoid response delays

[0065] When the trigger frequency of a certain type of interrupt request increases rapidly, it means that its importance may increase over time. For example, some real-time data processing tasks may need to respond quickly when the amount of data increases. Otherwise, data processing will be delayed, affecting the overall operation of the system. In this case, increasing the priority of such interrupt requests can effectively avoid the response delay problem.

[0066] 5) Adapt to dynamic environment

[0067] Interrupt requests with high trigger frequency and trigger frequency growth rate may be important feedback for the system in a dynamic operating environment. The system in a dynamic environment needs to quickly adapt to various changes, such as sudden increases in network traffic and frequent changes in external sensor events. Therefore, increasing the priority of such interrupt requests helps the system respond to changes in a timely manner and maintain operational stability and reliability.

[0068] 6) Prevent loss of critical tasks

[0069] A high trigger frequency means that a certain type of interrupt request is more important in the system and may involve the processing of critical tasks. If not processed in a timely manner, the critical tasks may be discarded or delayed, seriously affecting the normal operation of the system. Therefore, in order to ensure the effective execution of critical tasks, interrupt requests with high trigger frequencies need to be processed first.

[0070] The calculation expression of importance index is: , where is the importance index, The number of exception events generated by the interrupt request, The total number of exception events generated for all interrupt requests, is the number of devices or subsystems affected by the interrupt request, The maximum number of devices or subsystems affected by the interrupt request. , is the weight coefficient, and The greater the importance index, the greater the number of abnormal events generated by the interrupt request and the number of devices or subsystems affected, that is, the greater the priority of the interrupt request. The specific reasons are as follows:

[0071] 1) Direct impact of the number of abnormal events

[0072] The more abnormal events triggered by interrupt requests, the more likely it is that the interrupt is closely related to the core functions or key processes of the system. For example, in a distributed power equipment terminal platform, if an interrupt request is frequently accompanied by multiple abnormal events, it may indicate that the interrupt is related to the key links of power transmission, data acquisition or control systems. In order to avoid further escalation or spread of these abnormal events, the system needs to give priority to processing such interrupt requests, thereby reducing risks.

[0073] 2) Wide range of impact

[0074] The more devices or subsystems an interrupt request affects, the greater the potential risk and impact range. For example, an interrupt request may affect multiple power devices or multiple data collection points at the same time, which may lead to large-scale instability of the system or widespread data errors. In order to ensure the overall stable operation of the system and the normal operation of each subsystem, such interrupt requests with wide impacts need to be processed first;

[0075] 3) Mission-critical protection

[0076] Interrupt requests with a high importance index usually involve critical tasks or core functions. For example, if a critical control interruption in power equipment is not handled in a timely manner, it may cause equipment failure, system paralysis, or a large-scale power outage. Therefore, in order to protect these critical tasks and ensure that the core functions of the system can operate normally, such interrupt requests must be handled with priority;

[0077] 4) Prevent chain reactions

[0078] When an interrupt request affects a large number of devices or subsystems, if it is not responded to in time, it may trigger a series of chain reactions, leading to more abnormal events and failures in the system. For example, if the interrupt of a key device is not handled in time, it may cause failures of peripheral devices and then cause the collapse of the entire system. Therefore, giving priority to handling such interrupt requests can effectively prevent chain reactions and reduce the spread of failures.

[0079] 5) Improve the robustness of the system

[0080] Processing interrupt requests with a high importance index can improve the robustness of the system, that is, the system's ability to cope with uncertainty and abnormal situations. By giving priority to these interrupt requests, the system can better cope with possible abnormal situations, maintain normal working conditions, and reduce the impact on other devices or subsystems.

[0081] 6) Optimized resource allocation

[0082] When an interrupt request affects a wide range of issues, the system may need to allocate more resources to handle related issues. By giving priority to interrupt requests with a high importance index, it is possible to avoid wasting resources and ensure that system resources can be concentrated on handling the most important issues, thereby improving the overall efficiency and performance of the system.

[0083] 7) Reduce troubleshooting costs

[0084] Interrupt requests with a high importance index often involve critical equipment or subsystems. If not handled in a timely manner, they may lead to greater failures and increase repair costs. For example, if a critical interruption of power equipment is not responded to in a timely manner, it may cause equipment damage or data loss, which in turn requires more time and cost to repair. Giving priority to such interrupt requests can effectively reduce the difficulty and cost of subsequent repairs.

[0085] The logic for obtaining the ease index is as follows: obtain the average processing time of the interrupt request, and obtain the number of post-dependencies of the interrupt request, that is, the number of interrupt requests that can be continued to be executed after the execution of the interrupt request, normalize the average processing time and the number of post-dependencies, map the value range of the average processing time and the number of post-dependencies to [0,1], obtain the normalized value of the average processing time and the normalized value of the number of post-dependencies, and subtract the normalized value of the number of post-dependencies from the normalized value of the average processing time to obtain the ease index. The larger the ease index, the longer the average processing time of the interrupt request or the smaller the number of post-dependencies, that is, the lower the priority of the interrupt request. The specific reasons are as follows:

[0086] 1) The processing time is long, which affects the urgency

[0087] If the average processing time of an interrupt request is long, it means that more time resources are required to process the interrupt. In the case of limited system resources, giving priority to such interrupt requests may result in other more urgent interrupts not being responded to in time. Therefore, interrupt requests with longer processing time are usually less urgent, and their priority should be appropriately reduced to ensure that more urgent tasks can be processed first.

[0088] 2) System resource optimization

[0089] The system usually needs to schedule resources when processing multiple interrupt requests. If the processing time of an interrupt request is long, it may occupy more system resources. In order to ensure the effective use of resources and the processing of other urgent tasks, the system usually gives priority to those interrupt requests with shorter processing time and higher urgency. Therefore, the priority of interrupt requests with longer processing time should be appropriately lowered to avoid long-term occupation and waste of resources.

[0090] 3) Few post-dependencies and limited impact

[0091] The number of post-dependencies of an interrupt request is small, which means that the processing result of the interrupt will not have a significant impact on subsequent tasks. In this case, even if the interrupt request is processed a little later, it will not have a significant impact on the overall operation of the system. Therefore, the priority of interrupt requests with fewer post-dependencies can be appropriately lowered to ensure that the system can give priority to those interrupt requests that have an important impact on subsequent tasks and system stability.

[0092] 4) Reduce system waiting time

[0093] If the processing time of an interrupt request is long, giving priority to it may extend the waiting time of other interrupts, resulting in a decrease in the overall response speed of the system. In order to improve the response speed of the system, interrupt requests with shorter processing times are usually given priority to reduce the average waiting time of the system. Therefore, interrupt requests with longer processing times are usually given lower priority to avoid occupying system resources for a long time.

[0094] 5) Prevent resource contention

[0095] In a multi-tasking system, interrupt requests that take a long time to process may cause resource contention problems, especially when the system load is high. By lowering the priority of such interrupt requests, resources can be prevented from being occupied by a single task for a long time, thereby reducing resource contention problems and ensuring that other tasks in the system can proceed smoothly.

[0096] 6) Adapt task scheduling strategy

[0097] In the system, the scheduling strategy usually gives priority to those interrupt requests that have a greater impact on the system operation. Interrupt requests that take a long time to process and have fewer post-dependencies usually have less impact on the overall operation of the system. Therefore, their priority can be appropriately reduced to adapt to the overall scheduling strategy of the system, so that the system can run more efficiently.

[0098] 7) Balance task priorities

[0099] In order to maintain the balance of tasks in a multi-tasking system, the system usually considers the urgency of the task, resource usage, and subsequent impact. Interrupt requests with longer processing time and fewer post-dependencies usually have smaller impact scope and urgency. Therefore, the system can lower their priority to ensure that more important and urgent tasks can be processed in time, thereby balancing the overall task priority of the system.

[0100] 8) Reduce unnecessary system overhead

[0101] When the processing time of an interrupt request is long or there are few post-dependencies, prioritizing it may bring unnecessary system overhead, such as delaying the execution of other more critical tasks. Therefore, lowering the priority of such interrupt requests can reduce system overhead and make system resources more efficiently utilized.

[0102] After completing the priority sorting of all interrupt requests, register the corresponding interrupt callback function, including the following steps:

[0103] Define a corresponding callback function for each interrupt request. The callback function is a function that the system automatically calls when an interrupt occurs. It is used to execute specific interrupt processing logic. The callback function should contain specific code for processing interrupt events.

[0104] The defined callback function is registered in the system's interrupt vector table. Each interrupt vector corresponds to a specific interrupt request and its priority. When the interrupt request is triggered, the management system calls the corresponding callback function according to the vector table.

[0105] In order to better illustrate the application of the callback function, this application gives the following example:

[0106] Assuming that we have a specific interrupt request callback function to process the collection of certain sensor data, we can define the following function expression:

[0107] / / Define sensor data collection interrupt callback function

[0108] void-Sensor-Data-Interrupt-Handler(void)

[0109] { / / 1. Disable other interrupts to prevent the current processing interrupt from being interrupted

[0110] Disable-Interrupts();

[0111] / / 2. Read sensor data

[0112] int_sensor_data=Read-Sensor-Data();

[0113] / / 3. Process the sensor data

[0114] Process-Sensor-Data(sensor_data);

[0115] / / 4. Store the processed data into the system buffer

[0116] Store-Data-To-Buffer(sensor_data);

[0117] / / 5. Check whether the processing result requires further operation

[0118] if(Need-Further-Action(sensor_data)){

[0119] Trigger-Further-Action(sensor_data);}

[0120] / / 6. Record interrupt processing log

[0121] Log-Interrupt-Event("Sensor-Data-Interrupt",sensor_data);

[0122] / / 7. Resume interrupt

[0123] Enable-Interrupts();}

[0124] / / Register callback function to interrupt vector table

[0125] void-Register-Interrupt-Handlers(void)

[0126] {Register-Interrupt(SENSOR_DATA_INTERRUPT,Sensor-Data-Interrupt-Handler,HIGH_PRIORITY);}

[0127] The description of the above code is:

[0128] Sensor-Data-Interrupt-Handler is the callback function that handles sensor data collection, which is automatically executed when an interrupt is triggered.

[0129] Disable-Interrupts and Enable-Interrupts ensure that the interrupt processing will not be interrupted by other interrupts, ensuring the integrity of data processing.

[0130] The Read-Sensor-Data function is used to read the sensor data.

[0131] The Process-Sensor-Data function processes the collected data.

[0132] The Store-Data-To-Buffer function stores the processed data into the system's buffer.

[0133] Need-Further-Action is used to determine whether a subsequent action is required.

[0134] Log-Interrupt-Event records the log of interrupt events to facilitate debugging and tracing.

[0135] It should be noted that when registering a callback function, it is necessary to select an appropriate priority parameter (such as HIGH_PRIORITY) according to the priority of the interrupt request to ensure priority processing of critical interrupts. In the implementation of the callback function, care should be taken to avoid time-consuming operations to avoid delaying the processing of other interrupts.

[0136] When multiple interrupt requests are triggered simultaneously, the management order of the interrupt requests is selected according to the interrupt request sorting table, including the following steps:

[0137] When multiple interrupt requests are triggered simultaneously, the management order of the interrupt requests is selected according to the positive order of the terminal request sorting table.

[0138] When an interrupt request is selected for management, the interrupt service routine is started first, and the callback function quickly executes the corresponding processing logic, including the following steps:

[0139] The management system monitors the status of various interrupt requests in real time. When an interrupt request is detected, the interrupt service routine (ISR) is triggered immediately. When the interrupt service routine is started, the current CPU context (including register contents, program counter, etc.) needs to be saved first to ensure that after the interrupt processing is completed, the management system can correctly resume and continue to execute the interrupted task.

[0140] In order to ensure the integrity and real-time nature of interrupt processing, the management system may choose to temporarily shut down other interrupt requests to prevent the current interrupt from being interrupted by other low-priority interrupts. This can be achieved by disabling interrupts or increasing the interrupt masking level. According to the registered interrupt vector table, the system calls the corresponding interrupt callback function to start processing the interrupt request. The callback function contains specific processing logic, such as data reading, calculation, storage or other countermeasures.

[0141] In the callback function, the processing logic related to the interrupt request is executed. The processing logic may include the following:

[0142] Read data: read data from related devices or sensors;

[0143] Perform calculations: process or analyze the collected data in real time;

[0144] Control device: control or operate the corresponding device according to the type of interrupt request;

[0145] Log events: Record the results of interrupt processing in a log or buffer.

[0146] After the interrupt processing logic is completed, the interrupt flag is cleared, indicating that the interrupt has been successfully processed. This step is very important to ensure that the system does not repeatedly process the same interrupt. After the callback function is executed, the previously saved CPU context is restored so that the system can continue to execute the interrupted task to ensure the normal operation of the system. If other interrupts are turned off during interrupt processing, after completing the processing of the current interrupt, the disabled interrupt is re-enabled. This ensures that the system can respond to other interrupt requests in a timely manner. After the interrupt processing is completed, the system returns to the main program from the interrupt service routine and continues to execute the interrupted task. At this time, the system returns to normal operation.

[0147] All interrupt requests are divided into real-time tasks and non-real-time tasks. After the interrupt service program of the real-time task is executed, the real-time task is shared with the non-real-time task through the inter-process communication mechanism, including the following steps:

[0148] Real-time task interrupt requests: These interrupt requests involve time-sensitive tasks and usually require immediate processing, such as sensor data acquisition, control signal generation, etc.

[0149] Non-real-time task interrupt requests: These interrupt request processing tasks do not require an immediate response, and the processing delay is acceptable within a certain range, such as logging, data storage, etc.

[0150] According to the characteristics and priority of the interrupt, all interrupt requests are divided into real-time tasks and non-real-time tasks.

[0151] Initialization of inter-process communication (IPC) mechanism

[0152] When the system starts, the inter-process communication mechanisms (such as message queues, shared memory, semaphores, etc.) are initialized to exchange data between real-time tasks and non-real-time tasks. These mechanisms allow different tasks to run in different processes and transfer data through defined channels.

[0153] Data sharing between real-time tasks and non-real-time tasks

[0154] When the interrupt service routine of the real-time task completes the preliminary data processing, it sends the data to the non-real-time task through the inter-process communication mechanism. The process of sharing data includes the following sub-steps:

[0155] Data packaging: Pack the data processed by the interrupt service program into a data packet in a standard format, ready to be sent to non-real-time tasks.

[0156] Send data through the inter-process communication mechanism: Use the inter-process communication mechanism to send the packaged data to the queue or shared memory of the non-real-time task.

[0157] Notify non-real-time tasks: Non-real-time tasks can be notified through signals or flags that there is new data to be processed.

[0158] Non-real-time tasks receive and process data

[0159] The non-real-time task receives data from the real-time task through the inter-process communication mechanism and performs corresponding processing operations. Specific operations may include:

[0160] Record data to log files;

[0161] Store data in a database;

[0162] Analyze and organize data for subsequent tasks or report generation.

[0163] Data processing feedback: As needed, non-real-time tasks can return the processed results or feedback information to real-time tasks through the inter-process communication mechanism, so that the real-time tasks can adjust subsequent operations based on the feedback. This two-way communication ensures the flexibility and adaptability of the system.

[0164] Continuously monitor the data exchange status between real-time tasks and non-real-time tasks, and optimize the inter-process communication mechanism according to the actual operation situation, including the following steps:

[0165] Continuously monitor the data exchange status between real-time tasks and non-real-time tasks. The data exchange status includes the data transmission rate and the data loss rate. Optimize the inter-process communication mechanism according to the actual operation status. The actual operation status includes the processing capacity coefficient of the management system. The processing capacity coefficient, data transmission rate and data loss rate are comprehensively calculated to generate an adjustment index. The expression is: , where To adjust the index, is the processing capacity coefficient, is the data transmission rate, is the data loss rate, , , are the proportional coefficients of processing capacity coefficient, data transmission rate and data loss rate respectively, and , , All are greater than 0;

[0166] The larger the adjustment index is, the larger the buffer of the inter-process communication mechanism needs to be. Therefore, after obtaining the adjustment index, the buffer size of the inter-process communication mechanism is adjusted through the adjustment algorithm, which is expressed as: , where is the adjusted buffer size, is the buffer size before adjustment, To adjust the exponent, the adjusted buffer size is applied in the subsequent processing steps of the inter-process communication mechanism.

[0167] The present invention continuously monitors the data exchange status between real-time tasks and non-real-time tasks, the data exchange status includes the data transmission rate and the data loss rate, optimizes the inter-process communication mechanism according to the actual operation situation, the actual operation situation includes the processing capacity coefficient of the management system, and comprehensively calculates the processing capacity coefficient, the data transmission rate and the data loss rate to generate an adjustment index. After obtaining the adjustment index, the buffer size of the inter-process communication mechanism is adjusted by an adjustment algorithm, and the adjusted buffer size is applied to the subsequent processing steps of the inter-process communication mechanism. This is conducive to improving the data processing performance of the management system.

[0168] The processing power coefficient is obtained by multiplying the CPU frequency of the management system by the number of operations per clock cycle. The processing power of the CPU can be estimated by its frequency (in Hertz) and the number of operations that can be performed in each clock cycle. For example, a 3GHz CPU that performs 4 operations per cycle has a processing power coefficient of 12GFLOPS (billion floating-point operations per second). The lower the processing power coefficient of the management system, the worse the computing efficiency, and the buffer of the inter-process communication mechanism needs to be increased.

[0169] Data transfer rate: If the data transfer rate approaches or exceeds the processing capacity of the current buffer, increase the buffer size to prevent data loss or improve transmission efficiency;

[0170] Data loss rate: The amount of data or the proportion of data packets lost during the transmission process. If the data loss rate is high, it may be due to buffer overflow or shortage. Increasing the buffer can reduce the loss.

[0171] The management system runs non-real-time tasks in the background based on the Linux system, and decides whether to execute corresponding subsequent tasks according to the conditions of the real-time tasks, including the following steps:

[0172] Description: Establish a mechanism to monitor and collect the status and data of real-time tasks in real time. This may include the running status of the task, performance indicators, data input, etc.

[0173] tool:

[0174] cron: Set up periodic tasks to check real-time task status.

[0175] systemd: Use systemd service units to manage and monitor real-time tasks.

[0176] top, htop: view the system's operating status and resource usage in real time.

[0177] Custom scripts: Write scripts to periodically check the status of real-time tasks.

[0178] Description: Defines the specific conditions and triggering rules of the real-time task, such as the completion status of the task, data threshold, abnormal conditions, etc.

[0179] tool:

[0180] Configuration file: A configuration file that defines task conditions, such as / etc / myconfig.conf.

[0181] Database: Store conditions in a database (such as MySQL, PostgreSQL) for dynamic management.

[0182] Description: Determine whether to execute subsequent tasks based on the status of the real-time task and the defined conditions. This step requires regular inspection of the status of the real-time task and making decisions.

[0183] tool:

[0184] Scripting: Write scripts (e.g. in Bash or Python) to implement conditional checks and decision logic.

[0185] systemd: Use systemd's dependency management and service status checking functions.

[0186] Description: Perform corresponding follow-up tasks based on the decision results. This may involve starting new tasks, sending notifications, recording logs, etc.

[0187] tool:

[0188] systemd: Define new service units to perform subsequent tasks.

[0189] Scripting: Write Bash or Python scripts to initiate and manage subsequent tasks.

[0190] Task scheduler: Use at or cron to schedule the execution of subsequent tasks.

[0191] Description: Logs the execution and status of all tasks for auditing and troubleshooting purposes.

[0192] tool:

[0193] syslog, journalctl: record system logs and task execution logs.

[0194] Log file: Configure the task to output logs to the specified log file.

[0195] Description: Handle abnormal situations during execution and issue alarm notifications for timely response.

[0196] tool:

[0197] mail, sendmail: send email notification.

[0198] Nagios, Zabbix: Use monitoring tools to detect anomalies and issue alerts.

[0199] Exception handling scripts: Write scripts to handle exceptions and take corresponding measures (such as retry, rollback).

[0200] Example workflow:

[0201] Real-time tasks: real-time monitoring of data collection;

[0202] Condition definition: data collection reaches the corresponding threshold;

[0203] Condition check: Check the data collection status every minute;

[0204] Subsequent task execution: Once the data reaches the threshold, the data processing task is automatically started;

[0205] Logging: Detailed logs of data collection and processing;

[0206] Exception handling: Send an alarm email to the administrator when data collection fails.

[0207] Embodiment 3: The ARM9 platform management system based on the Linux system described in this embodiment includes a priority sorting module, an interrupt service module, and a task division and processing module;

[0208] Priority sorting module: obtain all interrupt requests of the ARM9 platform, prioritize all interrupt requests, generate an interrupt request sorting table, prioritize to avoid other low-priority interrupt requests affecting high-priority interrupt requests, and send the interrupt request sorting table to the interrupt service module;

[0209] Interrupt service module: After completing the priority sorting of all interrupt requests, register the corresponding interrupt callback function. When multiple interrupt requests are triggered at the same time, select the management order of the interrupt requests according to the interrupt request sorting table. When the interrupt request is selected for management, start the interrupt service program first, and the callback function quickly executes the corresponding processing logic. The execution result of the interrupt service program is sent to the task division and processing module;

[0210] Task division and processing module: All interrupt requests are divided into real-time tasks and non-real-time tasks. After the interrupt service program of the real-time task is executed, the real-time task is shared with the non-real-time task through the inter-process communication mechanism, and the non-real-time task is run in the background based on the Linux system. It also decides whether to execute the corresponding subsequent tasks based on the conditions of the real-time task.

[0211] The above formulas are all dimensionless and numerical calculations. The formula is a formula for the most recent real situation obtained by collecting a large amount of data and performing software simulation. The preset parameters in the formula are set by technicians in this field according to actual conditions.

[0212] It should be understood that the term "and / or" in this article is only a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. A and B can be singular or plural. In addition, the character " / " in this article generally indicates that the associated objects before and after are in an "or" relationship, but it may also indicate an "and / or" relationship. Please refer to the context for specific understanding.

[0213] It should be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0214] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application. Those skilled in the art can clearly understand that for the convenience and simplicity of description, the specific working process of the above-described system, device and unit can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0215] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. ARM9 platform management method based on Linux system, Features: The management method comprises the following steps: The management system obtains all interrupt requests of the ARM9 platform, prioritizes all interrupt requests, generates an interrupt request ranking table, and registers the corresponding interrupt callback function after completing the priority ranking of all interrupt requests; When multiple interrupt requests are triggered at the same time, the management order of the interrupt requests is selected according to the interrupt request sorting table. When the interrupt request is selected for management, the interrupt service program is started first, and the callback function executes the corresponding processing logic; All interrupt requests are divided into real-time tasks and non-real-time tasks. After the interrupt service program of the real-time task is executed, the real-time task is shared with the non-real-time task through the inter-process communication mechanism. The management system runs the non-real-time task in the background based on the Linux system and decides whether to execute the corresponding subsequent tasks according to the conditions of the real-time task. The management system obtains all interrupt requests of the ARM9 platform, prioritizes all interrupt requests, and generates an interrupt request sorting table, including the following steps: The management system obtains all interrupt requests of the ARM9 platform, and obtains the trigger frequency index, importance index and mitigation index of each interrupt request; The trigger frequency index, importance index and mitigation index are calculated comprehensively to obtain the priority coefficient, which is expressed as follows: , where is the priority coefficient, is the trigger frequency index, is the importance index, is the mitigation index, , , are the adjustment coefficients of the trigger frequency index, importance index and mitigation index, respectively, and , , All are greater than 0; After obtaining the priority coefficients of all interrupt requests, all interrupt requests are sorted from large to small according to the priority coefficients to generate an interrupt request sorting table; The calculation expression of the importance index is: , where is the importance index, The number of exception events generated by the interrupt request, The total number of exception events generated for all interrupt requests, is the number of subsystems affected by the interrupt request, is the maximum number of subsystems affected by the interrupt request, , is the weight coefficient, and ; The acquisition logic of the trigger frequency index is as follows: obtaining the trigger frequency and the trigger frequency growth rate of the interrupt request, normalizing the trigger frequency and the trigger frequency growth rate so that the value range of the trigger frequency and the trigger frequency growth rate is mapped to between [0,1], obtaining the normalized value of the trigger frequency and the normalized value of the trigger frequency growth rate, and summing the normalized value of the trigger frequency and the normalized value of the trigger frequency growth rate to obtain the trigger frequency index; The logic for obtaining the mitigation index is as follows: obtaining the average processing time of the interrupt request, and obtaining the number of post-dependencies of the interrupt request, that is, the number of interrupt requests that can be continued to be executed after the interrupt request is executed, normalizing the average processing time and the number of post-dependencies, so that the value range of the average processing time and the number of post-dependencies is mapped to between [0,1], obtaining the normalized value of the average processing time and the normalized value of the number of post-dependencies, and subtracting the normalized value of the number of post-dependencies from the normalized value of the average processing time to obtain the mitigation index; When an interrupt request is selected for management, the interrupt service routine is started first, and the callback function executes the corresponding processing logic, including the following steps: The management system monitors the status of various interrupt requests in real time. When an interrupt request is detected, the interrupt service routine is triggered immediately, and the current CPU context is saved when the interrupt service routine is started; The management system closes other interrupt requests and calls the corresponding interrupt callback function to start processing interrupt requests according to the registered interrupt vector table. The callback function contains processing logic, which includes reading data, performing calculations, controlling devices, and recording events. After the interrupt processing logic is completed, the interrupt flag is cleared, and the saved CPU context is restored after the callback function is executed. After completing the processing of the current interrupt request, the disabled interrupt request is re-enabled, and the main program is returned from the interrupt service routine; Sharing real-time tasks with non-real-time tasks through an inter-process communication mechanism includes the following steps: Initialize the inter-process communication mechanism, which is used to exchange data between real-time tasks and non-real-time tasks. The inter-process communication mechanism allows different tasks to run in different processes and transfer data through defined channels; When the interrupt service routine of the real-time task completes the preliminary data processing, it sends the data to the non-real-time task through the inter-process communication mechanism. The process of sharing data includes the following sub-steps: Pack the data processed by the interrupt service program to form a data packet in a standard format, use the inter-process communication mechanism to send the packed data to the queue or shared memory of the non-real-time task, and notify the non-real-time task through a signal or flag that there is new data to be processed. The non-real-time task receives the data from the real-time task through the inter-process communication mechanism and performs corresponding processing operations, including recording data to a log file, storing data in a database, analyzing and collating data for subsequent tasks or report generation; The non-real-time task returns the processed results or feedback information to the real-time task through the inter-process communication mechanism, continuously monitors the data exchange status between the real-time task and the non-real-time task, and optimizes the inter-process communication mechanism according to the actual operation situation; Continuously monitor the data exchange status between real-time tasks and non-real-time tasks, and optimize the inter-process communication mechanism according to the actual operation situation, including the following steps: Continuously monitor the data exchange status between real-time tasks and non-real-time tasks. The data exchange status includes the data transmission rate and the data loss rate. Optimize the inter-process communication mechanism according to the actual operation status. The actual operation status includes the processing capacity coefficient of the management system. The processing capacity coefficient, data transmission rate and data loss rate are comprehensively calculated to generate an adjustment index. The expression is: , where To adjust the index, is the processing capacity coefficient, is the data transmission rate, is the data loss rate, , , are the proportionality coefficients of processing capacity coefficient, data transmission rate and data loss rate respectively, and , , All are greater than 0; After obtaining the adjustment index, the buffer size of the inter-process communication mechanism is adjusted through the adjustment algorithm, which is expressed as: , where is the adjusted buffer size, is the buffer size before adjustment, To adjust the index, the adjusted buffer size is applied in the subsequent processing steps of the inter-process communication mechanism; The management system runs non-real-time tasks in the background based on the Linux system, and decides whether to execute corresponding subsequent tasks according to the conditions of the real-time tasks, including the following steps: Real-time monitoring data collection; Data is collected to the corresponding threshold; Check data collection status every minute; If the data reaches the threshold, the data processing task is automatically started; Logs recording data collection and processing; When data collection fails, an alarm email is sent to the administrator.

2. The ARM9 platform management method based on the Linux system according to claim 1, Features: Selecting the management order of the interrupt request according to the interrupt request sorting table includes the following steps: When multiple interrupt requests are triggered simultaneously, the management order of the interrupt requests is selected according to the positive order of the terminal request sorting table.

3. An ARM9 platform management system based on a Linux system, used to implement the management method described in claim 1 or 2, Features: It includes priority sorting module, interrupt service module, task division and processing module; Priority sorting module: obtain all interrupt requests of the ARM9 platform, prioritize all interrupt requests, and generate an interrupt request sorting table; Interrupt service module: After completing the priority sorting of all interrupt requests, register the corresponding interrupt callback function. When multiple interrupt requests are triggered at the same time, select the management order of the interrupt requests according to the interrupt request sorting table. When the interrupt request is selected for management, start the interrupt service program first, and the callback function executes the corresponding processing logic; Task division and processing module: All interrupt requests are divided into real-time tasks and non-real-time tasks. After the interrupt service program of the real-time task is executed, the real-time task is shared with the non-real-time task through the inter-process communication mechanism, and the non-real-time task is run in the background based on the Linux system. It also decides whether to execute the corresponding subsequent tasks based on the conditions of the real-time task.

Images