Dual-CPU communication control method

Abstract

The invention provides a double-CPU (central processing unit) communication control system, which relates to the technical field of CPU communication and realizes peer-to-peer task interaction and asynchronous execution between a main CPU and an auxiliary CPU by introducing a bidirectional task request mechanism and a multi-priority task queue. When the system is started, a task queue is initialized, and efficient transmission of tasks is achieved through task sending and receiving services. The task queue supports multiple data types, and the execution sequence can be dynamically scheduled according to the task priority. In addition, the system supports task timeout retransmission, error processing and dynamic load balancing of task threads, and the reliability and the resource utilization rate of the system are further improved. Through a parameter configuration function, a user can flexibly adjust a task priority strategy, overtime setting and other parameters according to actual requirements so as to adapt to different application scenes. The invention aims to optimize the task execution and communication efficiency under the dual-CPU architecture.

Description

Technical Field

[0001] The present invention relates to the technical field of CPU communication, and in particular to a dual-CPU communication control system. Background Art

[0002] In today's computer system architectures, dual-CPU systems are widely used because they can effectively improve computing power, enhance system reliability, and achieve efficient division of labor. However, existing dual-CPU communication methods mostly use a request-reply approach, where the primary CPU initiates a task request to the secondary CPU and waits for the task's execution result before proceeding with the next task request. This communication approach has many limitations and cannot meet the efficient task processing requirements of modern complex systems.

[0003] First, the existing request-response communication method cannot realize the simultaneous processing of multiple tasks. In practical applications, the system often needs to process multiple tasks simultaneously to improve the overall efficiency and response speed of the system. However, the existing communication method can only process tasks sequentially, resulting in increased delays in task processing, and cannot fully utilize the hardware resources of the dual-CPU system, limiting the performance improvement of the system. Secondly, the unidirectional nature of the tasks in this communication method is also an obvious disadvantage. In the existing dual-CPU system, only the main CPU can request tasks from the auxiliary CPU, and the auxiliary CPU cannot actively initiate task requests to the main CPU. This one-way task request mode limits the flexibility and scalability of the system, and cannot fully utilize the collaborative working capabilities of the dual-CPU system, which limits the system's processing capabilities when facing complex tasks.

[0004] Thirdly, the existing communication methods are also deficient in task priority management. In a multi-tasking scenario, the importance and urgency of different tasks often vary, so tasks need to be prioritized to ensure that high-priority tasks are processed first. However, the existing communication methods lack an effective task priority management mechanism and are unable to reasonably schedule and execute tasks according to their priorities, which affects the efficiency and reliability of task processing. Finally, the existing dual-CPU communication methods also have some problems in terms of task reliability and stability. For example, when a task is sent to the peer CPU, if a timeout is exceeded and no confirmation response is received from the peer CPU, the existing communication methods lack an effective retransmission mechanism, which may cause the task to be lost or repeated, affecting the normal operation of the system. In addition, the existing communication methods also have some limitations in the storage and transmission of task data, and cannot effectively support the processing of large-capacity task data, further limiting the application scope of the system.

[0005] In general, the existing dual-CPU communication method has many shortcomings in multi-tasking, task priority management, task reliability and system flexibility, and cannot meet the needs of modern complex systems for efficient, reliable and flexible dual-CPU communication.

[0006] In view of this, this application is filed. Summary of the Invention

[0007] The present invention provides a dual-CPU communication control system, which can at least partially improve the above problems.

[0008] To achieve the above object, the present invention adopts the following technical solutions:

[0009] A dual-CPU communication control system, comprising: a first controller and a second controller, wherein the first controller is communicatively connected to the second controller, wherein the first controller is configured to request a task from the second controller and execute the corresponding task based on a data packet received from the second controller, or send the corresponding data packet to the second controller in response to a task request from the second controller; and the second controller is configured to request a task from the first controller and execute the corresponding task based on a data packet received from the first controller, or send the corresponding data packet to the first controller in response to a task request from the first controller.

[0010] The first controller / the second controller is configured to implement the following steps by executing a computer program stored therein:

[0011] Get a unique task number, generate the corresponding task and its blocking mode, insert the task into the sending task queue, and send a task request to the peer controller;

[0012] Start the task receiving service, initialize the receiving task queue, obtain the data packet sent by the peer controller in the receiving task queue, store it in the buffer area, split the data packet, insert the split result into the request task queue, and notify the task process based on the split result;

[0013] Loop through the tasks in the request task queue and start the corresponding task execution thread according to the priority of the task.

[0014] In summary, the dual-CPU communication control system comprehensively improves existing dual-CPU communication methods, addressing issues such as one-way task requests, inability to process multiple tasks simultaneously, and insufficient task priority management. By introducing a task queue mechanism, it enables two-way task requests and asynchronous task execution between the two CPUs, significantly improving the system's task processing efficiency and flexibility. It supports high, medium, and low priority task queues, and uses task priority identifiers to ensure orderly task execution, ensuring rapid response to high-priority tasks. Furthermore, the shared cache size of the task queues can be configured according to actual needs, effectively avoiding memory fragmentation and enhancing system stability and reliability.

[0015] During task execution, the dual-CPU communication control system dynamically creates and recycles task threads, achieving balanced task load scheduling and further improving system resource utilization. High-priority task threads dynamically adjust the number of timer threads based on the current system load and insert tasks into the task queue of the least-loaded timer thread, thereby achieving efficient task scheduling. Medium- and low-priority task threads are dynamically activated based on task queue creation and enter a dormant state when no tasks are available, awaiting awakening from new tasks, further optimizing system performance.

[0016] In addition, the system provides parameter configuration capabilities, allowing users to flexibly configure parameters such as task priority policies, task request timeouts, task retransmission intervals, and the maximum number of tasks in each priority task queue through the web interface to adapt to different application scenarios and requirements. The parameter configuration of the secondary CPU (i.e., the second controller) is stored in the flash memory on the main CPU (i.e., the first controller). When the device starts, the secondary CPU actively requests parameters. When the web interface requests parameter configuration updates, the main CPU sends a parameter configuration update task request to the secondary CPU, further improving the system's flexibility and scalability.

[0017] Simply put, the dual-CPU communication control system uses an innovative task queue mechanism, dynamic task scheduling strategy, and flexible parameter configuration functions to enable the dual CPUs to request each other to execute tasks. Tasks are executed asynchronously in a queue, and the execution priority of task requests is determined according to priority identifiers, thereby achieving efficient and orderly execution of tasks between the dual CPUs, significantly improving the task processing efficiency of the dual-CPU system, optimizing hardware resource utilization and system reliability, and providing a new solution for multi-tasking and efficient communication in complex systems. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 Schematic diagram of communication and workflow of a dual-CPU communication control system provided by an embodiment of the present invention;

[0019] Figure 2 This is a schematic diagram of the workflow of the sending service provided by an embodiment of the present invention;

[0020] Figure 3 This is a schematic diagram of a receiving service workflow provided by an embodiment of the present invention;

[0021] Figure 4 This is a schematic diagram of a request service workflow provided by an embodiment of the present invention;

[0022] Figure 5 This is a schematic diagram of the task execution service workflow provided by an embodiment of the present invention;

[0023] Figure 6 Schematic diagram of queue initialization and workflow provided by an embodiment of the present invention;

[0024] Figure 7 This is a schematic diagram of a queue storage method provided by an embodiment of the present invention;

[0025] Figure 8 This is a schematic diagram of a high-priority task execution process provided by an embodiment of the present invention;

[0026] Figure 9 This is a schematic diagram of the execution process of medium and low priority tasks provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0027] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention will be further described in detail below in conjunction with the embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0028] refer to Figure 1 As shown, the first embodiment of the present invention discloses a dual CPU communication control system, which includes: a first controller (i.e. Figure 1 CPU1 in), the second controller (i.e. Figure 1 CPU2 in the first controller), the first controller is communicatively connected to the second controller, wherein the first controller is configured to request a task from the second controller and perform a corresponding task according to a data packet received from the second controller, or send a corresponding data packet to the second controller in response to a task request from the second controller; the second controller is configured to request a task from the first controller and perform a corresponding task according to a data packet received from the first controller, or send a corresponding data packet to the first controller in response to a task request from the first controller;

[0029] In this embodiment, the task working modes of the primary and secondary CPUs are equal, that is, the primary CPU can request tasks from the secondary CPU, and the secondary CPU can also request tasks from the primary CPU, which improves the independence and specificity of the CPU business functions.

[0030] The first controller / the second controller is configured to implement the following steps by executing a computer program stored therein:

[0031] See also Figure 4 ,S1, obtains the unique task number, generates the corresponding task and its blocking mode, inserts the task into the sending task queue, and sends a task request to the peer controller;

[0032] Specifically, step S1 includes: using the timestamp and the controller ID as key values ​​to obtain the unique ID of the task, and at the same time, generating the corresponding task priority and blocking mode to obtain the task to be requested;

[0033] Insert the task into the sending task queue, send a task request to the peer controller, and determine whether there is blocking based on its blocking mode;

[0034] If so, suspend the process and wait for the execution result of the requested task. When the execution result is received, wake up the task process, extract the task result information from the result queue according to the unique ID of the task, and remove the task result information from the result queue;

[0035] If not, the result queue is queried cyclically until the task result information can be extracted from the result queue according to the unique ID of the task, and the task result information is removed from the result queue.

[0036] In this embodiment, when the system initiates a task request, it generates a unique ID for the task based on the timestamp and the controller ID. This numbering mechanism ensures the uniqueness of each task in the entire system, ensures that the request and result of the task can be associated, prevents similar or identical tasks from being repeatedly requested and resulting in confusion, thereby avoiding the problem of task confusion and result confusion, and greatly improving the reliability and stability of the system. In addition, while generating the unique ID for the task, the system also assigns a corresponding task priority and blocking mode to each task. The setting of task priority enables the system to perform reasonable scheduling based on the importance and urgency of the task, ensuring that high-priority tasks can be processed first, thereby optimizing the system's response speed and resource utilization. The blocking mode determines the behavior of the task when waiting for the execution result, providing the system with a flexible task processing mechanism.

[0037] Specifically, when a task is generated, the system inserts it into the send task queue and sends a task request to the peer controller. This step demonstrates the system's asynchronous task execution mechanism, allowing tasks to wait in the queue while the system continues processing other tasks, thereby improving task processing concurrency and overall system efficiency. Next, the system determines the task's blocking mode. If the task is configured for blocking mode, the system suspends the current task process, waiting for the peer controller to complete task execution and return the result. This blocking mechanism ensures that the task process does not consume excessive system resources while waiting for the result, thereby improving system resource utilization. When the peer controller completes the task and sends the result back to the current controller, the system extracts the task result information from the result queue based on the task's unique ID and removes it from the result queue. This not only ensures accurate task result extraction but also avoids result queue redundancy by promptly removing completed task results, further optimizing system performance. Task request and execution in this system utilize an asynchronous mode. The send task service and receive task service focus on sending, receiving, and parsing tasks, ensuring efficient utilization of dual-CPU communication channel resources.

[0038] If a task is configured in non-blocking mode, the system will enter a loop, continuously querying the result queue until it can retrieve the task result information based on the task's unique ID. This non-blocking mechanism allows the task process to continue executing other tasks while waiting for the result, further improving the system's concurrent processing capabilities and flexibility. Once the task result is successfully retrieved, the system will also remove it from the result queue, ensuring efficient management of the result queue and stable system operation.

[0039] The dual-CPU communication control system uses a task queue method to send task requests to the opposite controller to execute tasks, allowing multiple processes to request tasks at the same time to improve the concurrent execution capability of task requests;

[0040] See also Figure 3 、 Figure 7 ,S2, start the task receiving service, initialize the receiving task queue, obtain the data packet sent by the peer controller in the receiving task queue, store it in the buffer area, split the data packet, insert the split result into the request task queue, and notify the task process based on the split result;

[0041] Specifically, step S2 includes: starting the task receiving service, initializing the receiving task queue, binding the communication port, monitoring the port information in real time, and receiving the corresponding data packet sent by the peer controller based on the request task;

[0042] The received data packet is stored in the buffer area, and the data packet is split to obtain the task execution result data;

[0043] Writing the data packet into the request execution queue according to the task priority in the task execution result data, and receiving the next round of data packets;

[0044] The task execution result data is stored in the receiving task queue, and the task process is determined based on the notification attribute corresponding to the task.

[0045] If yes, send a message to the task process; if no, receive the next round of data packets.

[0046] In this embodiment, the task receiving service is first started and the receiving task queue is initialized. This initialization process includes allocating memory space, setting the queue's read-write pointers, and initializing the relevant locking mechanism to ensure the security and reliability of task data during the receiving and storage process. After initialization is completed, the system binds the communication port to the task receiving service, enabling it to monitor port information in real time to promptly receive data packets sent by the opposite controller based on the requested task or the request execution result data packet. This real-time monitoring mechanism ensures that the system can quickly respond to the task request of the opposite controller, improving the system's real-time performance and response speed.

[0047] When the task receiving service monitors the arrival of a data packet on the port, it stores the received data packet in a preset buffer. The buffer area is used to temporarily store the received data for further processing. To ensure the integrity and accuracy of the data, the data packets stored in the buffer area are split and processed. The splitting process includes parsing the header information of the data packet, extracting the task execution result data and other relevant parameters. Through this splitting mechanism, the system can quickly extract the key information in the data packet and prepare for further task processing. Among them, the queue shared cache size is configurable and pre-allocated to prevent memory fragmentation caused by frequent requests for memory release during long-term operation; the task data supports flexible expansion of data and file types.

[0048] The data packet is then written to the request execution queue based on the task priority within the split task execution result data, demonstrating the system's flexible handling of task priorities. By writing tasks into the queue in order of priority, high-priority tasks are prioritized, optimizing system resource allocation and task execution efficiency. After completing the data packet writing operation, the system continues to receive the next round of data packets, maintaining the efficient operation of the task reception service.

[0049] Furthermore, when storing the task execution result data in the receiving task queue, the system determines whether the task process should be notified based on the task's corresponding notification attributes. This determination is based on the task's configuration information, such as whether the task requires real-time feedback and its urgency. If the task is configured with the notification attribute, the system sends a message to the task process informing it of the arrival of the task execution result. The task process can then process the result promptly based on the message prompt. This notification mechanism ensures that the task process receives the task execution result promptly, improving the system's collaborative working capabilities. If the task is not configured with the notification attribute, the system directly receives the next round of data packets and continues the task reception and processing process.

[0050] See also Figure 5 ,S3, cyclically obtains tasks in the request task queue and starts the corresponding task execution thread to execute the task according to the priority of the task.

[0051] Specifically, step S3 includes: initializing the request task queue, cyclically obtaining tasks in the request task queue, removing the request task node, and starting a new thread to execute the task, and the main thread enters the next task request execution;

[0052] Adjust the priority of the corresponding task execution thread according to the priority of the task, and start the corresponding task execution thread according to the priority of the task execution thread;

[0053] The thread obtains the corresponding task from the task queue of different priorities, inserts it into the corresponding timer thread to execute the task, obtains the execution result, inserts the execution result into the sending task queue, and ends the process;

[0054] Among them, the task execution thread can execute tasks with high priority first, and the priorities include high priority, medium priority and low priority.

[0055] In this embodiment, the execution task process is started and the request task queue is initialized; this initialization process includes setting the read and write pointers of the queue, allocating memory space, and initializing the relevant lock mechanism to ensure the security and stability of the task queue in a multi-threaded environment. After the initialization is completed, the task phase of the loop to obtain the task request queue is entered. In each loop, a task node is removed from the queue and a new thread is started to execute the task. After starting a new thread, the main thread will not wait for the current task to be completed, but will directly enter the execution of the next task request. This non-blocking thread startup mechanism significantly improves the concurrent processing capability of the system, allowing multiple tasks to be executed in different threads at the same time, thereby making full use of the hardware resources of the dual-CPU system.

[0056] During task execution, the priority of the corresponding thread executing the task is dynamically adjusted based on the task's priority. Task priorities are categorized as high, medium, and low, and tasks are queued sequentially in the high, normal, and low priority task queues, respectively. The system prioritizes launching threads corresponding to high-priority tasks, then executing threads in the normal priority queue, and finally executing threads in the low-priority queue, ensuring that high-priority tasks are processed quickly. This priority-based thread scheduling mechanism enables the system to rationally allocate resources based on the importance and urgency of tasks, ensuring that critical tasks are prioritized, thereby improving system responsiveness and task processing efficiency.

[0057] After the execution thread retrieves tasks from task queues of varying priorities, it inserts them into the corresponding timer thread for execution. The timer thread is responsible for actually executing the task and generating a result upon completion. This result is then inserted into the send task queue, awaiting transmission to the peer CPU. This process demonstrates the asynchronous and efficient nature of task processing in this system. By assigning tasks to timer threads of varying priorities, the system enables parallel processing, further improving task throughput.

[0058] It's worth noting that the task execution thread prioritizes high-priority tasks when processing them. This priority-driven task execution mechanism ensures that when faced with multiple tasks, the system prioritizes urgent and important tasks, thereby optimizing system resource allocation and task processing order. For example, when there are many high-priority tasks, the system will prioritize allocating more resources to these tasks to ensure their rapid completion, while lower-priority tasks will be processed gradually as resources allow. This flexible task scheduling approach enables the system to adapt to diverse workload scenarios, improving its flexibility and adaptability.

[0059] See also Figure 8 Preferably, the steps for the high-priority task thread to execute the task are specifically as follows:

[0060] Read task information, obtain the load of the current timer thread, and determine whether a new timer thread needs to be created based on the load and the upper limit of the timer thread, where the load is the number of current high-priority task timer threads and the upper limit is a preset upper limit of the number of threads;

[0061] When it is determined that the number of current high-priority task timer threads does not exceed the preset thread limit, a new timer thread is created and the timer tasks are scheduled according to the timer task load ratio. The high-load tasks are scheduled to be executed on the low-load timer thread. At the same time, the timer thread that has been scheduled multiple times and is in an idle state is exited to reclaim the timer task queue resources.

[0062] When it is determined that the number of current high-priority task timer threads exceeds the preset thread limit, no new timer thread is created, and the task is inserted into the timer thread task queue with the lowest load.

[0063] In this embodiment, when a high-priority task thread initiates task execution, it first reads task information and simultaneously obtains the load of the current timer thread. The load here refers to the number of high-priority task timer threads, while the upper limit refers to the preset upper limit of the number of timer threads. This design allows the system to dynamically monitor the current thread load, providing a basis for subsequent thread scheduling.

[0064] If the number of current high-priority task timer threads does not exceed the preset thread limit, a new timer thread is created. This mechanism ensures that the system can dynamically expand thread resources to meet task processing needs when processing high-priority tasks. The newly created timer thread schedules tasks based on the timer task load ratio. Specifically, high-load tasks are dispatched to low-load timer threads, achieving a balanced distribution of task loads. This load balancing mechanism not only improves system resource utilization but also prevents some threads from being overloaded while others are idle, further optimizing system performance.

[0065] At the same time, the system monitors the load status of timer threads. If a timer thread remains idle after multiple scheduling attempts, it is controlled to exit and the timer task queue resources it occupies are reclaimed. This resource recovery mechanism ensures that the system can effectively avoid resource waste while dynamically adjusting the number of threads, improving overall system efficiency and stability.

[0066] Conversely, if the number of current high-priority task timer threads has reached or exceeded the preset thread limit, no new timer threads will be created. In this case, the system will insert the new task into the task queue of the timer thread with the lowest load. This strategy ensures that high-priority tasks are processed first even when system resources are limited, while also avoiding system overload caused by an excessive number of threads. In general, high-priority tasks can be processed simultaneously, enabling load balancing and improved task throughput; and resources can be dynamically reclaimed and released when task threads are unloaded.

[0067] See also Figure 9Preferably, the steps of executing tasks by the medium-priority task thread and the low-priority task thread are as follows: obtaining queue information through a queue type identifier, obtaining tasks from the corresponding priority task queue, wherein, when there is no task in the queue, entering a self-sleeping state and waiting for a new task to wake up, and when there is a task in the queue, executing the next task after a fixed self-sleeping time;

[0068] Determine whether the current priority task thread and the low priority task thread have been created;

[0069] If so, insert it into the timer task queue;

[0070] If not, create a new timer task thread, set the corresponding priority, execute the current task, generate the task execution result, and insert the task execution result into the header position of the corresponding priority list according to the task priority, so as to send the execution result to the opposite controller.

[0071] In this embodiment, when a medium-priority task thread or a low-priority task thread starts task execution, it first obtains queue information through the queue type identifier and obtains tasks from the task queue of the corresponding priority, which reflects the refined management of the task queue; through the clear queue type identifier, tasks can be quickly located and obtained, reducing the time overhead of task retrieval. If there are no tasks in the queue, the thread will enter a self-sleep state and wait for the arrival of new tasks. This self-sleep mechanism not only saves system resources, but also avoids the ineffective operation of the thread when there are no tasks, thereby improving the overall efficiency of the system. When there are tasks in the queue, the thread will be awakened after a fixed self-sleep time and execute the next task. This combination of self-sleep and wake-up mechanisms ensures that tasks can be processed in a timely manner, while avoiding frequent thread switching and optimizing system performance.

[0072] After acquiring a task, the system checks whether a task thread of the current priority has already been created. If so, the task is inserted into the timer task queue, awaiting execution. This process demonstrates the system's flexible and dynamic approach to task execution, allowing tasks to dynamically adjust their execution strategy based on the creation of the current thread. If a task thread of the current priority has not yet been created, a new timer task thread is created and assigned the corresponding priority. This dynamic thread creation mechanism ensures that the system can flexibly allocate resources based on task requirements, avoiding task delays caused by insufficient threads.

[0073] The newly created timer task thread will execute the current task and generate a task execution result. The task execution result is then inserted into the corresponding priority list head based on the task's priority. This design not only ensures that task execution results are quickly transmitted to the peer controller, but also, through the priority list head insertion mechanism, ensures that the results of high-priority tasks are processed and transmitted first. This priority-based task result management mechanism further optimizes system resource allocation and task processing order, ensuring efficient system operation.

[0074] Among them, the fixed self-sleep duration of medium and low priority timer task threads can be configured separately through the WEBUI; in simple terms, the task priority, scheduling strategy, and self-sleep duration of this system can be configured to adapt to different usage scenarios.

[0075] See also Figure 6 , preferably, it also includes: when it is determined that the parameter configuration program is started, initializing the shared parameter memory, loading the configuration parameters from the flash module of the first controller into the shared parameter memory, and monitoring and receiving the parameter configuration request of the webui in real time;

[0076] Based on the configuration parameters, the task priority strategy of the first controller and the second controller, the timeout period for sending task requests, the interval period for task retransmission, the maximum number of tasks corresponding to each priority task queue, the upper limit number of high-priority timer task threads, the high-priority timer task load threshold and recycling threshold, and the fixed self-rest period of medium-priority tasks and low-priority tasks are configured.

[0077] In this embodiment, the shared parameter memory is initialized. This initialization process includes allocating memory space, setting memory access permissions, and initializing related data structures to ensure the security and consistency of parameter configuration data in a multi-controller environment. The configuration parameters are then loaded from the Flash module of the first controller into the shared parameter memory. As a non-volatile storage medium, the Flash module can store configuration parameters for a long time, ensuring the integrity and persistence of the parameters even in the event of a system power outage or restart. By loading parameters from the Flash module, the system can quickly restore to the last configuration state at startup, reducing the system initialization time and improving the system startup efficiency.

[0078] After loading the configuration parameters, it enters the real-time listening state and receives parameter configuration requests from the Web UI. The Web UI provides a user-friendly interface that allows users to flexibly configure system parameters according to actual needs. This Web UI-based configuration method eliminates the need for users to directly operate the underlying hardware or system files, lowers the system's usage threshold, and improves the system's usability and maintainability. Based on the configuration requests submitted by users through the Web UI, parameters such as the task priority policy of the first controller and the second controller, the timeout period for sending task requests, the interval period for task retransmission, the maximum number of tasks corresponding to each priority task queue, the upper limit number of high-priority timer task threads, the high-priority timer task load threshold and recycling threshold, and the fixed self-sleep period for medium-priority and low-priority tasks can be configured. The flexible configuration of these parameters enables the system to be optimized and adjusted according to different application scenarios and task requirements, thereby achieving efficient task scheduling and resource management.

[0079] For example, by configuring task priority policies, users can specify which tasks require priority processing, ensuring that critical tasks receive a quick response. The timeout duration for sending task requests and the interval between task retransmissions can be adjusted based on the network environment and the urgency of the task to improve system reliability and stability. Configuring the maximum number of tasks in each priority task queue prevents task queue overload, ensuring smooth system operation. Configuring the upper limit number of high-priority timer task threads, load thresholds, and recycle thresholds further optimizes the system's resource allocation and task scheduling strategies, ensuring that high-priority tasks receive sufficient resource support while avoiding resource waste.

[0080] In addition, the configuration of fixed self-sleep time for medium-priority tasks and low-priority tasks enables the system to dynamically adjust the sleep time of threads according to the importance and urgency of the tasks, thereby optimizing the resource utilization of the system while ensuring the task response speed. Among them, the parameter configuration of the second controller is stored on the flash of the first controller. When the device starts, the second controller actively requests to obtain the parameters from the flash of the first controller. When the webui has a parameter configuration update, the first controller sends a parameter configuration update task request to the second controller. The default insertion priority of the sending task queue is return result > high priority task > normal priority task > low priority task. In simple terms, the configured parameters can be saved on the flash of one end using dual CPU communication, effectively saving hardware resources.

[0081] This parameter configuration mechanism enables flexible management and dynamic adjustment of dual-CPU system operating parameters, improving system scalability and adaptability while also simplifying system usage through a user-friendly Web UI, enhancing the user experience. Furthermore, by flexibly configuring parameters such as task priority policies, timeout durations, retransmission intervals, task queue limits, thread limits, load thresholds, and recycle thresholds, the system can be optimized for different application scenarios and task requirements, enabling efficient task scheduling and resource management, further enhancing system performance and reliability.

[0082] See also Figure 2 , preferably, it also includes: upon receiving a task sending request from the peer controller, starting a task sending service and initializing a sending task queue, wherein, when the task queue is empty, suspending the waiting wake-up task sending, and when the task queue is not empty, entering the next task execution request operation;

[0083] When a task request is detected, the wake-up service obtains the task from the task queue and sends a data packet to the peer controller to request task execution;

[0084] When no confirmation response is received from the peer controller within the timeout period, the task is moved to the retransmission queue, and a timer is started to periodically check the retransmission queue, and the position of the task queue is selected according to the task priority;

[0085] When receiving a response from the peer controller that a task error has occurred, the response information is written to the result queue, and based on the task attributes, it is determined whether to send a message to notify the task process.

[0086] If yes, send the message; if no, do not send the message and remove the task from the send queue;

[0087] When the peer controller acknowledges that the task has been received correctly, the task is removed from the sending queue.

[0088] In this embodiment, when a controller receives a task request from a peer controller, it immediately starts the task sending service and initializes the sending task queue. After initialization is complete, the status of the task queue is checked. If the task queue is empty, the task sending service will suspend and wait to be awakened, thereby avoiding unnecessary resource usage and system overhead. Conversely, if there are tasks in the task queue, the system will directly proceed to the execution request operation of the next task, thereby ensuring that the tasks can be processed quickly.

[0089] When the system detects a task request, the task dispatch service is activated and retrieves the task from the task queue. It then sends a data packet containing the task information to the peer controller, requesting that the peer controller execute the task. This embodies an asynchronous task execution mechanism, allowing tasks to wait in the queue while the system continues processing other tasks, thereby improving task processing concurrency and overall system efficiency.

[0090] However, some exceptions may occur during task communication. For example, if the system times out after sending a task request and does not receive an acknowledgment from the peer controller, the task sending service moves the task to a retransmission queue. Subsequently, a timer is started to periodically check the status of tasks in the retransmission queue. Based on the task's priority, the task is reinserted into the task queue at an appropriate location, ensuring that high-priority tasks are retransmitted first. This priority-based retransmission mechanism not only improves system reliability but also optimizes the order in which tasks are processed, ensuring that critical tasks are prioritized.

[0091] If the system receives a task failure response from the peer controller, the task delivery service writes the response to the result queue. The system then determines, based on the task's attributes, whether a message should be sent to notify the task process. If the task is configured with the notification attribute, the system sends a message to the task process informing it of the task failure so that it can take appropriate action. Conversely, if the task is not configured with the notification attribute, the system does not send a message and directly removes the task from the delivery queue, thus avoiding redundant task queues and wasting resources.

[0092] When the controller receives a response from the peer controller confirming that the task has been successfully received, the task delivery service removes the task from the delivery queue. This process not only ensures efficient task queue management and stable system operation, but also prevents excessive task queue expansion by promptly clearing completed tasks, further optimizing system performance.

[0093] Preferably, the sending task queue is initialized as follows:

[0094] Apply for the shared memory buffer area of ​​the sending task queue, initialize the read and write pointers and queue task numbers of the four task queues: high, medium, low, and resend;

[0095] The shared memory buffer area includes: a queue information header and a task node, wherein the queue information header includes a list start address pointer, a list end address pointer, a maximum number of task nodes, a current number of task nodes, a current node write address pointer, and a current read address pointer; and the task node includes a task ID, a task name, a task priority, a task command, parameters, a task data type, and data.

[0096] Register read / write lock objects for the high, medium, low, and resend task queues, identify the queue type, and return the initialization result.

[0097] In this embodiment, when initializing the sending task queue, a shared memory buffer area is first applied to the operating system for storing the relevant data of the task queue. This buffer area is the core storage structure of the task queue. It supports the storage and management of multiple tasks and allows task queues of different priorities to share the same memory space, thereby improving memory utilization. The design of the shared memory buffer area enables task data to be efficiently transmitted in a dual-CPU system, reducing data transmission delays. Among them, the queue buffer area size is applied to the system for shared memory size based on the system's pre-set maximum number of task nodes and the maximum number of bytes of data in the node. The maximum number of nodes and the maximum number of bytes of data can be configured and modified in the WEBUI according to the actual usage scenario.

[0098] The shared memory buffer contains two components: a queue header and a task node. The queue header is the metadata component of the task queue, recording the queue's basic structure and status information. Specifically, the queue header includes the list's starting address pointer, ending address pointer, maximum number of task nodes, current number of task nodes, current node write address pointer, and current read address pointer. This information provides essential guidance for task queue management and operation, enabling the system to quickly locate the head and tail of the queue, determine queue fullness or emptyness, and efficiently perform task read and write operations. A task node is the unit within the queue that stores specific task data. Each task node contains information such as the task ID, task name, task priority, task command, parameters, task data type, and data. The task ID uniquely identifies each task, ensuring traceability and manageability within the system. The task priority provides a basis for task scheduling, enabling the system to prioritize and execute tasks based on their importance and urgency. The task command and parameters define the specific operation content of the task, while the task data type and data store the data required for task execution. This detailed task node design enables the task queue to flexibly support various types of tasks and provides rich information support for the efficient execution of tasks.

[0099] During initialization, read / write lock objects are registered for each of the four task queues: high, medium, low, and retry. Locking is introduced to ensure data consistency within task queues in a multi-threaded environment. Because task queues may be accessed and modified simultaneously by multiple threads, locks are required to prevent data conflicts and race conditions. Read / write lock objects are registered independently for each task queue, enabling fine-grained concurrency control for task queues of different priorities. Identifying each queue type further enhances system manageability, enabling the system to quickly identify and process task queues of different priorities.

[0100] After initialization is complete, the initialization result is returned to inform the caller whether the task queue has been successfully initialized. This feedback mechanism provides an important basis for the system's error handling and status monitoring, allowing the system to take timely remedial measures when initialization fails, thereby improving reliability and stability.

[0101] See also Figure 6 ,Preferably, the step of writing a task to a queue by a task process is specifically: obtaining queue information, and locking the queue write operation according to the queue information;

[0102] After executing the write queue lock, determine whether the current remaining buffer area cannot meet the task insertion based on the queue information, where the queue information includes the queue type, read and write pointers, and the remaining space in the queue buffer area;

[0103] If yes, suspend and wait until the condition is met to wake up; if not, do not suspend and wait, insert the send task data, update the write pointer and cache space information, and exit the write task queue operation;

[0104] The steps for the task process to read tasks from the queue are as follows:

[0105] Obtain queue information and lock the queue read operation according to the queue information;

[0106] After the lock is completed, the read pointer position of the queue is obtained, the list data is read, the read pointer and cache space information are updated, and it is determined whether there is a write task service that needs to be woken up;

[0107] If yes, send a signal to wake up; if no, do not wake up.

[0108] In this embodiment, when a task process needs to write a task to a queue, it first obtains queue information. This information provides the task process with a comprehensive view of the queue's current state, enabling it to make reasonable write operation decisions. After obtaining the queue information, the task process uses this information to lock the queue for write operations. The purpose of locking is to ensure that the queue is not interfered with by other processes or threads during the writing of task data, thereby ensuring data integrity and consistency. This locking mechanism is a key guarantee for data security in a multi-threaded environment. After locking, the task process uses the queue information to determine whether the remaining buffer area can accommodate the task data insertion requirements. If the remaining buffer area is insufficient to accommodate the task data to be inserted, the task process enters a suspended state and waits until a condition is met before being awakened. This suspension mechanism prevents the task process from making invalid write attempts when resources are insufficient, thereby conserving system resources and reducing unnecessary waiting time. Conversely, if the remaining buffer area is sufficient to accommodate the task data, the task process directly inserts the task data and updates the queue's write pointer and buffer space information. After completing these operations, the task process exits the task queue write operation. This efficient writing mechanism ensures that task data can be stored in the queue quickly and accurately, while avoiding write failures due to insufficient resources.

[0109] In this embodiment, when a task process needs to read a task from a queue, it also first obtains queue information. This information provides the task process with a comprehensive view of the queue's current state, enabling it to make reasonable read operation decisions. After obtaining the queue information, the task process uses this information to lock the queue for read operations. The purpose of this locking operation is to ensure that the queue is not interfered with by other processes or threads while reading task data, thereby ensuring data integrity and consistency. This locking mechanism is also a key guarantee for data security in a multi-threaded environment. After locking, the task process obtains the queue's read pointer position and reads the list data based on this position. After reading the data, the task process updates the queue's read pointer and cache space information. These updates ensure that the queue's state accurately reflects the current read status, providing a reliable foundation for subsequent task reads. After completing the data read and status update, the task process determines whether any write task services need to be awakened. If there are any waiting write task services, the task process sends a signal to wake them up so that they can continue writing task data. This wake-up mechanism ensures timely response to queue write operations, thereby improving overall system efficiency. On the contrary, if there is no write task service that needs to be woken up, the task process will directly exit the read operation.

[0110] The queue operates on a first-in-first-out (FIFO) principle for cyclic read and write operations. The current task node performs atomic read and write operations. Task data types can be character, numeric, or file. When the data type is character or numeric, the corresponding character or number is directly stored in the data; when the data type is file, the address of the file corresponding to the data is stored in the data. If the task data type is character or numeric and exceeds the maximum number of bytes for data storage, the data type is converted to file and transferred to the system flash to ensure efficient data storage and transmission.

[0111] In summary, in terms of task queue management, the dual-CPU communication control system initializes the sending task queue and allocates independent queue space for tasks of different priorities, including high, medium, low, and retransmission task queues. This multi-priority queue design allows the system to schedule tasks based on their importance and urgency, ensuring that high-priority tasks are processed first. Furthermore, through the optimized design of the shared memory cache, the system can efficiently store and manage task data, avoiding frequent memory allocation and release operations, thereby reducing memory fragmentation and improving system stability and resource utilization.

[0112] During task sending and receiving, the system introduces an asynchronous task execution mechanism and a bidirectional task request model. Upon startup, the task sending service initializes a task queue and dynamically adjusts its task sending strategy based on the queue's status. If the task queue is empty, the service suspends itself, awaiting new tasks. Once a task is available, the service immediately wakes up and sends a task request. This mechanism not only improves task processing concurrency but also ensures the proper allocation of system resources through dynamic scheduling based on task priorities. Furthermore, the system optimizes handling of exceptions during task execution. For example, if a task times out without receiving an acknowledgment, the system moves the task to a resend queue and reschedules its execution based on its priority. This resend mechanism effectively prevents task loss or duplicate execution, improving task processing reliability. Furthermore, if an error response is received from the peer controller, the system writes the error information to the result queue and, based on the task's attributes, decides whether to notify the task process, further enhancing the system's flexibility and fault tolerance.

[0113] During the task execution phase, the system achieves balanced scheduling of task loads by dynamically creating and recycling task threads. High-priority task threads dynamically adjust the number of threads based on the load of the current timer thread and dispatch high-load tasks to low-load threads for execution. This load balancing mechanism not only improves system resource utilization but also further optimizes system performance by dynamically recycling unloaded threads. Furthermore, the dual-CPU communication control system provides flexible parameter configuration capabilities, allowing users to configure parameters such as task priority policies, task timeout settings, retransmission intervals, and queue limits through a Web UI interface. This configuration mechanism enables the system to be optimized and adjusted according to different application scenarios and task requirements, thereby improving the system's adaptability and scalability. The secondary CPU's parameter configuration is stored in Flash on the primary CPU, further conserving hardware resources and enhancing system reliability.

[0114] This dual-CPU communication control system significantly improves task processing efficiency, resource utilization, and system reliability through innovative task queue management, asynchronous task execution mechanisms, dynamic task scheduling strategies, and flexible parameter configuration capabilities. This not only addresses the shortcomings of existing dual-CPU communication methods but also provides a new solution for efficient communication and task processing in complex environments, making it particularly suitable for complex application scenarios that require handling large numbers of concurrent tasks.

[0115] The above is a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A dual CPU communication control system, characterized in that: include: a first controller and a second controller, wherein the first controller is communicatively connected to the second controller, wherein the first controller is configured to request a task from the second controller and perform a corresponding task based on a data packet received from the second controller, or send a corresponding data packet to the second controller in response to a task request from the second controller; and the second controller is configured to request a task from the first controller and perform a corresponding task based on a data packet received from the first controller, or send a corresponding data packet to the first controller in response to a task request from the first controller; The first controller / the second controller is configured to implement the following steps by executing a computer program stored therein: Get a unique task number, generate the corresponding task and its blocking mode, insert the task into the sending task queue, and send a task request to the peer controller; Start the task receiving service, initialize the receiving task queue, obtain the data packet sent by the peer controller in the receiving task queue, store it in the buffer area, split the data packet, insert the split result into the request task queue, and notify the task process based on the split result; Loop through the tasks in the request task queue and start the corresponding task execution thread according to the priority of the task.

2. The dual CPU communication control system according to claim 1, characterized in that: Get a unique task number, generate the corresponding task and its blocking mode, insert the task into the sending task queue, and send a task request to the peer controller. Specifically: Use the timestamp and controller ID as key values ​​to obtain the unique ID of the task. At the same time, generate the corresponding task priority and blocking mode to obtain the task to be requested. Insert the task into the sending task queue, send a task request to the peer controller, and determine whether there is blocking based on its blocking mode; If so, suspend the process and wait for the execution result of the requested task. When the execution result is received, wake up the task process, extract the task result information from the result queue according to the unique ID of the task, and remove the task result information from the result queue; If not, the result queue is queried cyclically until the task result information can be extracted from the result queue according to the unique ID of the task, and the task result information is removed from the result queue.

3. The dual CPU communication control system according to claim 1, characterized in that: Start the task receiving service, initialize the receiving task queue, obtain the data packet sent by the peer controller in the receiving task queue, store it in the buffer area, split the data packet, insert the split result into the request task queue, and notify the task process based on the split result. Specifically: Start the task receiving service, initialize the receiving task queue, bind the communication port, monitor the port information in real time, and receive the corresponding data packets sent by the peer controller based on the request task; The received data packet is stored in the buffer area, and the data packet is split to obtain the task execution result data; Writing the data packet into the request execution queue according to the task priority in the task execution result data, and receiving the next round of data packets; The task execution result data is stored in the receiving task queue, and the task process is determined based on the notification attribute corresponding to the task. If so, send a message to the task process; If not, receive the next round of data packets.

4. The dual CPU communication control system according to claim 1, characterized in that: Loop through the tasks in the request task queue and start the corresponding task execution thread according to the priority of the task, specifically: Initialize the request task queue, loop to obtain the tasks in the request task queue, remove the request task node, and start a new thread to execute the task. The main thread enters the next task request execution; Adjust the priority of the corresponding task execution thread according to the priority of the task, and start the corresponding task execution thread according to the priority of the task execution thread; The thread obtains the corresponding task from the task queue of different priorities, inserts it into the corresponding timer thread to execute the task, obtains the execution result, inserts the execution result into the sending task queue, and ends the process; Among them, the task execution thread can execute tasks with high priority first, and the priorities include high priority, medium priority and low priority.

5. The dual-CPU communication control system according to claim 4, characterized in that: The steps for a high-priority task thread to execute a task are as follows: Read task information, obtain the load of the current timer thread, and determine whether a new timer thread needs to be created based on the load and the upper limit of the timer thread, where the load is the number of current high-priority task timer threads and the upper limit is a preset upper limit of the number of threads; When it is determined that the number of current high-priority task timer threads does not exceed the preset thread limit, a new timer thread is created and the timer tasks are scheduled according to the timer task load ratio. The high-load tasks are scheduled to be executed on the low-load timer thread. At the same time, the timer thread that has been scheduled multiple times and is in an idle state is exited to reclaim the timer task queue resources. When it is determined that the number of current high-priority task timer threads exceeds the preset thread limit, no new timer thread is created, and the task is inserted into the timer thread task queue with the lowest load.

6. The dual-CPU communication control system according to claim 4, characterized in that: The steps for medium-priority task threads and low-priority task threads to execute tasks are as follows: Get queue information through queue type identifier, and get tasks from the corresponding priority task queue. When there is no task in the queue, it enters a self-sleep state and waits for a new task to wake up. When there is a task in the queue, it executes the next task after a fixed self-sleep time. Determine whether the current priority task thread and the low priority task thread have been created; If so, insert it into the timer task queue; If not, create a new timer task thread, set the corresponding priority, execute the current task, generate the task execution result, and insert the task execution result into the header position of the corresponding priority list according to the task priority, so as to send the execution result to the opposite controller.

7. The dual-CPU communication control system according to claim 1, characterized in that: Also includes: When it is determined that the parameter configuration program is started, the shared parameter memory is initialized, the configuration parameters are loaded from the flash module of the first controller into the shared parameter memory, and the parameter configuration request received from the webui is monitored in real time; Based on the configuration parameters, the task priority strategy of the first controller and the second controller, the timeout period for sending task requests, the interval period for task retransmission, the maximum number of tasks corresponding to each priority task queue, the upper limit number of high-priority timer task threads, the high-priority timer task load threshold and recycling threshold, and the fixed self-rest period of medium-priority tasks and low-priority tasks are configured.

8. The dual-CPU communication control system according to claim 1, characterized in that: Also includes: When receiving a task request from the peer controller, the task sending service is started and the sending task queue is initialized. When the task queue is empty, the task is suspended and waits for the wake-up task to be sent. When the task queue is not empty, the next task is executed. When a task request is detected, the wake-up service obtains the task from the task queue and sends a data packet to the peer controller to request task execution; When no confirmation response is received from the peer controller within the timeout period, the task is moved to the retransmission queue, and a timer is started to periodically check the retransmission queue, and the position of the task queue is selected according to the task priority; When receiving a response from the peer controller that a task error has occurred, the response information is written to the result queue, and based on the task attributes, it is determined whether to send a message to notify the task process. If so, send a message; If not, do not send the message and remove the task from the send queue; When the peer controller acknowledges that the task has been received correctly, the task is removed from the sending queue.

9. The dual-CPU communication control system according to claim 8, characterized in that: Initialize the sending task queue, specifically: Apply for the shared memory buffer area of ​​the sending task queue, initialize the read and write pointers and queue task numbers of the four task queues: high, medium, low, and resend; The shared memory buffer area includes: a queue information header and a task node, wherein the queue information header includes a list start address pointer, a list end address pointer, a maximum number of task nodes, a current number of task nodes, a current node write address pointer, and a current read address pointer; and the task node includes a task ID, a task name, a task priority, a task command, parameters, a task data type, and data. Register read / write lock objects for the high, medium, low, and resend task queues, identify the queue type, and return the initialization result.

10. The dual-CPU communication control system according to claim 1, characterized in that: The steps for the task process to write tasks to the queue are as follows: Obtain queue information and lock the queue write operation according to the queue information; After executing the write queue lock, determine whether the current remaining buffer area cannot meet the task insertion based on the queue information, where the queue information includes the queue type, read and write pointers, and the remaining space in the queue buffer area; If so, suspend and wait until the condition is met to wake up; If not, do not suspend waiting, insert the sending task data, update the write pointer and cache space information, and exit the write task queue operation; The steps for the task process to read tasks from the queue are as follows: Obtain queue information and lock the queue read operation according to the queue information; After the lock is completed, the read pointer position of the queue is obtained, the list data is read, the read pointer and cache space information are updated, and it is determined whether there is a write task service that needs to be woken up; If so, send a signal to wake up; If not, do not wake up.

Images