A method for data transfer across processor instances and a multiprocessor system

Abstract

This invention provides a data transmission method and multiprocessor system across processor instances, relating to the field of computer communication technology. The method includes: a first processor instance allocating and writing target data blocks in a shared memory area, performing a cache coherence operation, and sending control description information containing relative addresses via an independent control link using logical addressing; a second processor instance performing a cache coherence operation on the shared area based on the relative addresses, reading the data, processing it, and replying with processing completion feedback information containing a block identifier; and the first processor instance reclaiming the blocks accordingly. This invention separates control information from the data path, achieving zero-copy transmission; it achieves communication multiplexing through logical addressing of service identifiers and instance identifiers, supports local loopback self-testing, and solves the problems of poor code reusability, low transmission efficiency, insufficient testability, and thread unsafety in existing technologies. It is suitable for remote display and touch interaction between multiple operating system instances.

Description

Technical Field

[0001] This invention relates to the field of computer communication and data transmission technology, specifically to a data transmission method for realizing cross-processor remote display and touch interaction between multiple operating system instances, and more particularly to a data transmission method and multiprocessor system for cross-processor instances. Background Technology

[0002] In embedded systems, multi-chip or multi-core architectures are widely used in smartwatches, automotive systems, smart home devices, and other scenarios. A device may contain two or more application processor cores, application processor chips, or operating system instances, each capable of running a graphical user interface and generating a display screen. In this architecture, any application processor instance can either transmit its screen to another instance for display or receive a screen from another instance and display it in its local display area. Simultaneously, user input events on the local display area need to be transmitted back to the corresponding remote instance to achieve bidirectional remote display interaction between the two application processor instances.

[0003] In existing technologies, cross-chip display interaction solutions typically suffer from the following problems: First, the communication interface is bound to the processor identity. Existing solutions typically hardcode the communication endpoints and message formats according to the processor names of the sending and receiving ends, such as defining fixed channel names like "AP0_to_AP1_input" and "AP1_to_AP0_fb". When the communication role of a processor instance changes, for example, if an instance needs to both send its own screen and receive the other end's screen, or if new communication functions need to be added, all communication code must be rewritten, making the code unusable across different processor combinations and bidirectional display scenarios.

[0004] Second, transmitting large blocks of pixel data via message channels leads to inefficiency. Embedded message channels, such as Remote Processor Message Passing (RPMsg), typically have a single transmission capacity of several hundred bytes, while a single frame of display pixel data (e.g., 800×480×4 bytes, approximately 1.5MB) far exceeds this limit. Existing solutions directly transmit the entire pixel data of the frame buffer in packets via message channels, requiring numerous packet splitting and reassembly operations, severely reducing transmission efficiency and consuming excessive message channel bandwidth.

[0005] Third, there is a lack of a unified transmission backend abstraction. Existing solutions tightly couple the establishment of communication links, data transmission, and upper-layer business logic into a fixed link, making it impossible to perform closed-loop self-testing and debugging independently in a single-image environment. It is necessary to rely on two real chips to be ready at the same time to verify the correctness of the function, which greatly increases the threshold for development and debugging.

[0006] Fourth, there is a lack of lifecycle management for the frame buffer. After sending frame data, the sending end cannot know whether the receiving end has finished processing it, so the frame buffer cannot be reused safely. If the sending end overwrites the buffer before the receiving end has finished rendering, it will cause display tearing; if the sending end waits indefinitely, it will cause a buffer leak.

[0007] Fifth, thread safety issues. Message reception callbacks in embedded systems typically execute in a separate system thread context, while the rendering and event handling of graphical user interface libraries must be performed on the UI thread. Existing solutions lack effective cross-thread data transfer mechanisms. If the application programming interface of the graphical user interface library is directly called in the message reception callback, it can easily lead to system crashes due to race conditions.

[0008] In summary, the aforementioned deficiencies in existing technologies result in shortcomings in cross-processor remote display interaction solutions regarding code reusability, transmission efficiency, testability, buffer management security, and thread safety. Therefore, achieving efficient and reusable remote display and touch interaction across multiple operating system instances, enabling the same codebase to adapt to different communication role combinations through configuration, and supporting both single-image self-testing and real cross-chip deployment, has become a pressing technical challenge. Summary of the Invention

[0009] To address the shortcomings of existing technologies, this invention provides a data transmission method and a multiprocessor system for cross-processor instances.

[0010] According to the present invention, a data transmission method and a multiprocessor system for cross-processor instances are provided, the solution of which is as follows: In a first aspect, a method for data transfer across processor instances is provided, applied to a first processor instance, wherein the first processor instance is communicatively connected to a second processor instance, the method comprising: In response to the target data to be transmitted, a target storage block is allocated in the shared storage area shared by the first processor instance and the second processor instance, and the target data is written into the target storage block; A first cache coherence operation is performed on the target storage block to make the written target data visible to the second processor instance; Control description information is sent to the second processor instance via a control link independent of the shared storage region, using logical addressing, to achieve multiplexing of communication traffic for multiple logical services on a single physical communication endpoint; wherein, the logical addressing abstracts the communication function into a combination of service identifier and instance identifier, and appends the service identifier and instance identifier to the data packet when sending; the control description information contains the relative address of the target storage block, instructing the second processor instance to read the target data from the shared storage region based on the relative address; In response to receiving processing completion feedback information from the second processor instance via the control link, the target storage block is reclaimed; the processing completion feedback information includes identification information corresponding to the target storage block.

[0011] Preferably, performing the first cache consistency operation on the target storage block includes: After the target data is written to the target storage block and before the control description information is sent, a cache refresh operation and a memory barrier operation are performed on the target storage block to synchronize the target data in the local cache of the first processor instance to physical memory and prevent instruction reordering.

[0012] Preferably, the shared storage area is divided into multiple storage slots, and each storage slot maintains an occupancy status flag; Allocating a target storage block in a shared storage area shared by the first processor instance and the second processor instance includes: traversing the plurality of storage slots, allocating the storage slots whose occupancy status is marked as free as the target storage block, and updating their occupancy status to occupied. Reclaiming the target storage block includes: restoring the occupied status flag of the target storage block to the free state; The relative address is the offset address of the target storage block in the shared storage area, so that the second processor instance can calculate the local virtual address for reading the target data based on the offset address and the local shared memory base address of the second processor instance.

[0013] Preferably, the control description information further includes the data size, data format identifier, and response indication flag of the target data; The control link is an independent communication channel established based on a message passing mechanism. The control description information is transmitted in the form of message packets through the control link, and the target data is transmitted with zero copy through the shared storage area.

[0014] Preferably, the method further includes: When sending the control description information, the sending timestamp of the target storage block is recorded; Initiate timeout monitoring for the target storage block. If the processing completion feedback information containing the corresponding identifier information of the target storage block is not received through the control link within a preset time threshold, the target storage block is forcibly reclaimed, and a timeout alarm is generated.

[0015] Preferably, the control link adopts a logical addressing model, which abstracts the communication function into a combination of service identifier and instance identifier; Control description information is sent to the second processor instance via a control link independent of the shared storage region, including: The service identifier and the instance identifier are appended to the data packet containing the control description information, and the data packet is sent through a single physical communication endpoint to achieve multiplexing of communication traffic for multiple logical services on the single physical communication endpoint.

[0016] Preferably, the underlying transmission backend of the control link includes a message passing backend and a local loopback backend; When configured as the messaging backend, cross-processor communication is performed via the single physical communication endpoint through the messaging interface provided by the operating system. When configured as the local loopback backend, the data packet is intercepted, and without passing through the single physical communication endpoint, the receiving processing function that matches the service identifier and the instance identifier is directly searched in the local service distribution table for delivery, so as to perform closed-loop testing in a single-processor instance environment.

[0017] Secondly, a cross-processor instance data transfer method is also provided, applied to a second processor instance, which is communicatively connected to a first processor instance. The method includes: Control description information from the first processor instance is received via a control link independent of the shared storage region. The control description information includes the relative address of the target storage block, which is the block in the shared storage region where the first processor instance allocates and writes target data. Based on the relative address, a second cache coherence operation is performed on the target storage block in the shared storage area to ensure that the latest data written by the first processor instance is read and the target data is read from the target storage block; The target data is processed, and a processing completion feedback message is sent to the first processor instance via the control link to instruct the first processor instance to reclaim the target storage block; the processing completion feedback message includes identification information corresponding to the target storage block.

[0018] Preferably, the second processor instance includes a message receiving thread and a UI rendering thread, and the processing of the target data includes: In the message receiving thread, the read target data is written to the backend buffer; Under critical section protection, the pointers of the front-end buffer and the back-end buffer are swapped, and a frame ready flag is set so that when the interface rendering thread detects the frame ready flag, it reads the target data from the front-end buffer for rendering. The message receiving thread has exclusive write access to the backend buffer, the interface rendering thread has exclusive read access to the frontend buffer, and the critical section only protects pointer swapping and flag setting operations.

[0019] Thirdly, a multiprocessor system is provided, the system comprising: a first processor, a second processor, shared memory, a message channel, and a memory; The shared memory is configured to provide a shared storage area that can be accessed by both the first processor and the second processor; The message channel is configured to provide a control link independent of the shared storage area; The memory stores a computer program. When the computer program is executed by the first processor, it enables the first processor to act as a first processor instance and implements a method applied to the first processor instance. When the computer program is executed by the second processor, it enables the second processor to act as a second processor and implements a method applied to the second processor instance.

[0020] Compared with the prior art, the present invention has the following technical effects: 1. High code reusability: Through a service-oriented logical addressing model and a customizable architecture, the same code can adapt to different combinations of communication roles simply by changing the configuration. Communication functions are abstracted as combinations of service identifiers and instance identifiers, rather than hard-coding physical endpoints by chip name, avoiding the code reusability issues caused by processor identity binding in traditional solutions. Each functional module is controlled by an independent configuration switch to determine whether it is compiled into the final image; switching communication roles only requires exchanging configuration files, without modifying any communication code. 2. High transmission efficiency: By separating the transmission paths of control information and pixel data, the control description information only contains relative addresses and metadata (usually tens of bytes), leveraging the low latency and high reliability of the control link for control information exchange; large blocks of pixel data are transmitted directly through a shared storage area, completely bypassing the control link, achieving zero-copy transmission. This scheme avoids the numerous packet reassembly operations and bandwidth consumption problems caused by sending large blocks of pixel data in packets through message channels in existing technologies, significantly improving the efficiency of cross-processor data transmission. 3. Excellent testability; the transmission backend abstraction layer supports switching between message passing backend and local loopback backend modes. The local loopback backend intercepts data packets and delivers them directly by searching for the matching receiving and processing function in the local service distribution table without going through a real physical link. This allows developers to perform complete closed-loop testing in a single-processor instance environment without relying on two real chips being ready at the same time, significantly reducing the development and debugging threshold. 4. Secure Frame Buffer Management: Through a protocol that controls the response information for description and processing completion feedback, the sending end only reclaims the corresponding target storage block after confirming that the receiving end has completed processing the target data. The processing completion feedback includes identification information corresponding to the target storage block, enabling the sending end to accurately identify and reclaim the corresponding buffer, avoiding display tearing caused by premature overwriting. Simultaneously, by recording the transmission timestamp and initiating timeout monitoring, forced retrieval and alarm are triggered if processing completion feedback is not received within a preset time threshold, preventing buffer leakage caused by peer anomalies or link interruptions. 5. Thread-safe and reliable: Through critical section protection of intermediate variables and a double-buffer mechanism, the message receiving thread and the UI rendering thread are completely decoupled. The message receiving thread has dedicated write access to the backend buffer, and the UI rendering thread has dedicated read access to the frontend buffer. Critical sections only protect pointer swapping and flag setting operations, not time-consuming operations such as data copying and rendering. The message receiving callback never directly calls the graphical user interface (GUI) application interface. All cross-thread data is passed through critical section-protected intermediate variables or a double-buffer mechanism, avoiding race conditions caused by cross-thread calls to the GUI interface at the architectural level and ensuring system stability.

[0021] Other beneficial effects of the present invention will be explained in detail through the introduction of specific technical features and technical solutions in specific embodiments. Those skilled in the art should be able to understand the beneficial technical effects brought about by these technical features and technical solutions through the introduction of these technical features and technical solutions. Attached Figure Description

[0022] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a schematic diagram of the overall architecture of the present invention; Figure 2 This is a schematic diagram of the service-oriented addressing model and multiplexing in this invention; Figure 3 This is a flowchart illustrating the frame buffer lifecycle management protocol in this invention. Figure 4 This is a flowchart illustrating the session control protocol in this invention. Figure 5 This is a schematic diagram of the thread-safe cross-thread data transfer mechanism in this invention; Figure 6 This is a schematic diagram illustrating the configuration of the customizable architecture in this invention. Detailed Implementation

[0023] The present invention will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present invention, but do not limit the invention in any way. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present invention. These all fall within the scope of protection of the present invention.

[0024] This invention provides a data transmission method across processor instances. By using a "service-oriented logical addressing + descriptor-driven zero-copy frame transmission mechanism", it achieves a unified abstraction of communication, data transmission and deployment debugging environment for cross-processor remote display systems. This allows the same set of code to adapt to different communication role combinations through configuration, while supporting single-system closed-loop verification and real cross-chip deployment.

[0025] Overall architecture: Reference Figure 1 As shown, the overall architecture of this invention is divided into the following layers from top to bottom: graphical interface adaptation layer, remote display framework layer, transmission backend layer, and infrastructure layer for message transmission and shared memory.

[0026] The graphical user interface (GUI) adaptation layer is responsible for interfacing with specific GUI libraries. On the sending side, the GUI adaptation layer automatically captures the frame refresh operations of the GUI library through a hook mechanism, copies pixel data to shared memory, and triggers frame transmission. On the receiving side, the GUI adaptation layer creates a picture-in-picture display area locally, renders the received remote frame data into this area, and captures the user's touch operations on this area.

[0027] The remote display framework layer is the key to this invention, comprising sub-modules such as service registration and distribution tables, multiple customizable functional modules, a shared memory pool manager, and cache consistency operation encapsulation. The service registration and distribution tables are used to implement logical addressing and message distribution. Customizable functional modules include a frame transmission sending module, a frame transmission receiving module, an input event sending module, an input event receiving module, a session control sending module, and a session control receiving module. Each functional module can be independently controlled via a configuration switch to determine whether it is compiled into the final image.

[0028] The transport backend layer provides a unified message sending interface, through which upper-layer modules send messages without being aware of the underlying transport mechanism. This layer can register and switch between different transport backend implementations, supporting both message passing backend and local loopback backend modes.

[0029] The infrastructure layer provides messaging communication capabilities and shared memory access capabilities.

[0030] Service-oriented addressing model: Reference Figure 2 As shown, one of the key designs of this invention is the service-oriented addressing model, which abstracts communication functions into a combination of service identifiers and instance identifiers, replacing the traditional endpoint-binding communication model that names physical endpoints by chip name.

[0031] Service identifiers are used to identify functional categories, including but not limited to frame data transmission services, input event services, and session control services. Instance identifiers are used to distinguish different communication directions within the same service category, allowing multiple pairs of logical communication relationships to be carried on the same physical message endpoint.

[0032] Specifically, taking the frame data transmission service as an example: the frame transmission sending module and the frame transmission receiving module belong to the same frame data transmission service. Under this service, instance identifier 0 is used for the receiving channel of frame descriptor messages (FB_DESC), and instance identifier 1 is used for the receiving channel of frame completion messages (FB_DONE). In the input event service, instance identifier 0 is used for the receiving channel of input events. In the session control service, instance identifier 0 is used for the receiving channel of session control commands, and instance identifier 1 is used for the receiving channel of response messages.

[0033] The framework layer maintains a service distribution table, where each entry contains a service identifier, an instance identifier, and a pointer to the corresponding receive callback function. When a message arrives from the other end, the transport backend layer first strips the transport layer header, extracts the service identifier and instance identifier, then searches for a matching entry in the service distribution table and calls the corresponding receive callback function. This design enables multiplexing of communication traffic from multiple logical services on a single physical message link.

[0034] When sending a message, all functional modules call a unified sending interface, specifying the target service identifier and instance identifier. This interface forwards the message to the underlying registered transport backend instance. If it's a message delivery backend, the backend appends channel header information to the message body, which contains a service identifier string and an instance identifier value, and then sends it through the physical message endpoint. After receiving the message, the receiving end has the backend strip the channel header information, extract the service identifier and instance identifier, and distribute it through the service distribution table. If it's a local loopback backend, the message is directly delivered to the matching receive callback function in the local service distribution table; the entire process does not involve a real physical link.

[0035] This design completely decouples the "logical addressing" and "physical transmission" of communication: the functional modules only care about which logical service address to send data to, while the establishment, maintenance and switching of the physical transmission link are managed independently by the transmission backend layer.

[0036] Transport backend abstraction layer: The transmission backend abstraction layer of this invention defines a unified message sending interface, eliminating the need for upper-layer functional modules to be aware of the underlying communication mechanism. The framework defines a unified transmission backend operation interface, which includes at least a message sending method. This interface serves as the sole channel for all functional modules within the framework to send messages. Specific transmission backend implementations can be registered at runtime, supporting both message-passing backend and local loopback backend modes.

[0037] When configured as a messaging backend, it performs actual cross-processor communication through the messaging interface provided by the operating system. This backend creates a single, multiplexed physical messaging endpoint during framework initialization, through which all logical service messages are transmitted. Before sending each message, the backend automatically appends channel header information, including the target service identifier and instance identifier; upon receiving a message, it automatically removes the channel header information and dispatches it based on a lookup table.

[0038] When configured as a local loopback backend, incoming data packets are intercepted and, without passing through a real physical link, are directly delivered by searching the local service distribution table for a receiving processing function that matches the target service identifier and instance identifier. This backend is used for complete closed-loop testing in a single operating system instance environment. Developers can simultaneously enable frame sending and receiving modules on the same operating system instance without a second chip, verifying the correctness of all communication logic through the local loopback backend.

[0039] This abstract design completely decouples all upper-layer functional modules from the physical transmission mechanism. Functional modules do not need to contain any conditional compilation or runtime judgment code related to specific transmission methods; they can simply call the sending interface. A local loopback backend is used for testing, and a message passing backend is used for deployment, requiring zero modification to the upper-layer code.

[0040] Shared memory pool and cache consistency management: The shared memory pool is the pixel data transmission infrastructure of this invention. The first processor instance and the second processor instance achieve address space unification by mapping the same shared memory region. The shared memory pool divides the entire shared memory region into multiple storage slots, each of which can hold at least one complete frame of pixel data. Each storage slot maintains an occupancy status flag. During allocation, a free storage slot is searched, and its occupancy status flag is updated to occupied; during release, its occupancy status flag is restored to free.

[0041] The shared memory pool provides a bidirectional translation interface between virtual addresses and shared memory offset addresses. Offset addresses are used as relative addresses in frame descriptor messages, rather than absolute physical addresses, ensuring that the virtual address spaces of the first and second processor instances are independent. The second processor instance calculates its locally available virtual address based on the offset address in the descriptor and its local shared memory base address.

[0042] Regarding cache consistency management, this invention defines an abstract interface for cache operations, including three operations: cache refresh, cache invalidation, and memory barrier. In simulated or single-image environments, these operations can be implemented without an underlying hardware implementation; in real cross-chip deployments, the board-level support package provides the underlying hardware-related implementations. This design encapsulates platform-specific cache operations into replaceable interfaces, maintaining the platform independence of the framework's core code.

[0043] Frame buffer lifecycle management protocol: Reference Figure 3 As shown, one of the key designs of this invention is a descriptor-based frame buffer transmission and lifecycle management protocol. This protocol separates the transmission paths of control information and pixel data: control information is transmitted through a control link, while pixel data is transmitted directly through a shared memory area.

[0044] At the protocol level, this invention defines two types of control messages: control description information (FB_DESC) and processing completion feedback information (FB_DONE). The fields of the control description information include, but are not limited to: relative address (i.e., shared memory offset address), data size, image width, image height, line stride, pixel format, frame sequence number, buffer number, and flag bits. The flag bits include an acknowledgment flag (acknowledgment required flag), used to indicate whether the second processor instance needs to reply with processing completion feedback information after processing. The fields of the processing completion feedback information include, but are not limited to: frame sequence number, buffer number, and processing status. The processing completion feedback information contains identification information corresponding to the target storage block, i.e., the buffer number, enabling the first processor instance to accurately identify and reclaim the corresponding target storage block.

[0045] The complete workflow of this agreement is as follows: Step A1 (Buffer Allocation): The frame transmission module of the first processor instance allocates an available target storage block from the shared memory pool. During allocation, it iterates through multiple storage slots in the shared storage area, allocates the storage slots whose occupancy status is marked as free as the target storage block, and updates their occupancy status to occupied.

[0046] Step A2 (Pixel Write and Cache Synchronization): The first processor instance copies the pixel data of the current frame as the target data to the allocated target storage block. After the copy is complete, a first cache consistency operation is performed on the target storage block. The first cache consistency operation specifically includes: after writing the target data to the target storage block and before sending the control description information, performing a cache refresh operation and a memory barrier operation on the target storage block to synchronize the target data in the local cache of the first processor instance to physical memory, prevent instruction reordering, and make the written target data visible to the second processor instance.

[0047] Step A3 (Descriptor Sending and Status Marking): The first processor instance constructs control description information, filling in the relative address, data size, image width, image height, line step, pixel format, frame sequence number, buffer number, and flag bits (including acknowledgment flag) of the target storage block. The first processor instance marks the target storage block as waiting, records the sending timestamp, and then sends the control description information to the second processor instance in the form of a message packet via the control link. The control link is an independent communication channel established based on a message passing mechanism. The control description information is transmitted through the control link, while the target data is transmitted zero-copy through the shared storage area, without passing through the control link.

[0048] Step A4 (Receiver Cache Synchronization): After receiving the control description information via the control link, the frame transmission receiving module of the second processor instance performs a second cache coherence operation on the target storage block in the shared storage area based on the relative address. The second cache coherence operation specifically includes performing cache invalidation and memory barrier operations on the memory region corresponding to the target storage block to ensure that the latest data written by the first processor instance is read. Then, the second processor instance calculates a locally available virtual address based on the relative address and the local shared memory base address, and reads the target data from the target storage block.

[0049] Step A5 (Pixel Data Consumption): The second processor instance processes the target data. This invention employs a dual-buffer mechanism to achieve parallel decoupling of receiving and rendering. The second processor instance includes a message receiving thread and a UI rendering thread. In the message receiving thread, the read target data is written to the back-end buffer; under critical section protection, the pointers of the front-end and back-end buffers are swapped, and a frame ready flag is set. When the frame ready flag is detected, the UI rendering thread reads the target data from the new front-end buffer and performs rendering. The message receiving thread has exclusive write access to the back-end buffer, and the UI rendering thread has exclusive read access to the front-end buffer. The critical section only protects the two extremely short operations of pointer swapping and flag setting, and does not protect time-consuming operations such as data copying and rendering, allowing the two threads to execute in parallel for the vast majority of the time with minimal performance loss.

[0050] Step A6 (Completion Notification): After the second processor instance completes the consumption processing of the target data, it constructs a processing completion feedback message. The processing completion feedback message includes the identification information (i.e., buffer number), frame sequence number, and processing status corresponding to the target storage block, and is sent to the first processor instance via the control link.

[0051] Step A7 (Buffer Reclamation): After receiving the processing completion feedback information via the control link, the frame transmission module of the first processor instance verifies whether the identification information (buffer number and frame sequence number) matches the target storage block to be reclaimed. If the verification is successful, the occupancy status flag of the target storage block is restored to the idle state, and the target storage block can be reused for subsequent frame transmissions.

[0052] Furthermore, the present invention also includes a timeout protection mechanism. When sending control description information, the first processor instance records the sending timestamp of the target storage block and initiates timeout monitoring for the target storage block. If processing completion feedback information containing the corresponding identifier information of the target storage block is not received through the control link within a preset time threshold, the target storage block is forcibly reclaimed, its occupancy status flag is restored to the idle state, and a timeout alarm message is generated to avoid permanent buffer leakage due to peer anomalies or link interruptions.

[0053] Crucially, in the above protocol, the control description information only includes relative addresses and metadata (typically tens of bytes), excluding the target data itself. The actual target data (potentially several MB) is transmitted directly through a shared storage area accessible to both parties, bypassing the control link entirely. This is the core difference between this invention and existing solutions that "send pixel data directly in packets through a message channel," and it is also key to achieving efficient transmission.

[0054] Session control protocol: Reference Figure 4 As shown, the present invention defines a session control protocol for establishing and terminating remote display sessions between a first processor instance and a second processor instance.

[0055] The session state machine includes the following states: Idle, Requesting, Confirming, and Active. Session control messages include the following types: session request messages, containing subtype fields to distinguish the initiation direction (screen sharing or remote viewing), session accept messages, session reject messages, and session close messages. Specifically, session request messages contain subtype fields to indicate whether the initiation intent is screen sharing or remote viewing.

[0056] The complete workflow of this agreement is as follows: Step B1: Initially, both parties are in an idle state. Either party can initiate a session request.

[0057] Step B2 (Initiating a Session): The initiator sends a session request message, including a subtype field indicating the initiation intent. The initiator's session state switches to the requesting state.

[0058] Step B3 (Waiting for Confirmation): After receiving the session request message, the receiver switches the session state to the confirming state. The receiver waits for confirmation from the local user.

[0059] Step B4a (Accept Session): If the receiver accepts the session, it sends a session acceptance message, and the session state switches to active. Upon receiving the session acceptance message, the initiator's session state also switches to active. Once the session is active, the sending end automatically installs a frame refresh hook, automatically capturing frame refresh operations from the graphical interface library through the hook mechanism, and begins capturing and transmitting each frame. The receiving end automatically creates a picture-in-picture display area and begins receiving and displaying the sending end's real-time feed.

[0060] Step B4b (Session Rejection): If the receiver rejects the session, it sends a session rejection message, and the session state returns to the idle state. Upon receiving the session rejection message, the initiator's session state returns to the idle state.

[0061] Step B5 (Close Session): In the active state, either end can actively end the session. The end that initiates the closure sends a session close message. Upon receiving the message, the other end performs cleanup operations, including unloading the frame refresh hook and destroying the picture-in-picture display area. The session state of both ends returns to the idle state.

[0062] In an active session, this invention also supports bidirectional input event forwarding. The receiving end captures the user's touch operation on the picture-in-picture display area and maps the local coordinates of the touch point proportionally to the global coordinates of the sending end's screen. The mapping relationship is: global coordinates equal local coordinates multiplied by the sending end's screen size divided by the picture-in-picture display area size. The mapped coordinates are sent to the sending end through the input event service. After receiving the remote touch coordinates, the sending end injects them into the local input system through a thread-safe mechanism, driving the user interface (UI) interaction as if it were a local touch operation.

[0063] A key feature of this session control protocol is its bidirectional initiation capability: session requests can be initiated in both directions, with each peer acting as either a requester or a confirmer. Regardless of which end is configured as a frame sender or receiver, it can initiate a session request and accept or reject requests initiated by the other. This symmetrical design ensures the independence of communication roles from user operation roles, enhancing the framework's flexibility and applicability.

[0064] Thread-safe cross-thread data transfer mechanism: Reference Figure 5 As shown, this invention designs a complete thread-safe data transmission mechanism to solve the data race problem between the message receiving thread and the graphical user interface rendering thread in embedded systems. In embedded systems, message receiving callbacks execute in an independent system thread context, while the rendering and event handling of the graphical user interface library must be executed in the UI thread. If the interface of the graphical user interface library is directly called in the message receiving callback, unpredictable race conditions will occur, which may lead to system crashes. This invention ensures thread safety through the following mechanism.

[0065] (a) Double-buffered transfer mechanism for frame data The receiving end maintains two temporary buffers (a front buffer and a back buffer) and a frame ready flag. When receiving frame data, the message receiving thread always writes pixel data to the back buffer. After writing, under critical section protection, the following atomic operations are performed: the front buffer pointer and the back buffer pointer are swapped, the frame size information is updated, and the frame ready flag is set to true. The timer callback in the UI thread checks the frame ready flag under critical section protection. Once the frame is confirmed to be ready, it reads data from the front buffer for rendering, and clears the frame ready flag after rendering is complete.

[0066] The key design principle is that the message receiving thread has dedicated write access to the backend buffer, while the UI thread has dedicated read access to the frontend buffer. Critical sections only protect two extremely short operations: pointer swapping and flag operations; they do not protect time-consuming operations such as data copying and rendering. This allows the two threads to execute in parallel for the vast majority of the time with minimal performance overhead.

[0067] (ii) Intermediate variable transfer mechanism of touch coordinates Touch coordinates are transmitted using an intermediate variable mechanism. The first processor instance maintains a set of intermediate variables for the touch coordinates, including the X and Y coordinates and a pressed state flag. Upon receiving a remote touch event, the message receiving thread writes the coordinates and state into the intermediate variables under critical section protection. The input device read function of the graphical user interface library (GUI) reads the intermediate variables in the interface rendering thread, also under critical section protection, and injects the remote touch coordinates into the GUI's input system. Both writing and reading of the intermediate variables are protected by critical sections, ensuring the atomicity of the operation.

[0068] (iii) Mechanism for Passing Flags for Session Control Events Session control events are transmitted using a flag-based mechanism. The receiving end maintains a session control event structure, containing an event validity flag, command type, subtype, and sequence number. Upon receiving a session control message, the message receiving thread, under critical section protection, fills in the event content and sets the validity flag to true. The timer callback in the UI rendering thread checks the validity flag under critical section protection; if true, it consumes the event and clears the validity flag.

[0069] The three mechanisms described above all follow the same core principle: never directly call any graphical interface library interface in the message reception callback. This principle is an important engineering practice in the development of graphical interfaces for embedded systems, and this invention systematizes and solidifies it as a framework design constraint.

[0070] Customizable functional module architecture: This invention enables the independent compilation and on-demand combination of functional modules through a configuration system. Each functional module, including a frame transmission sending module, a frame transmission receiving module, an input event sending module, an input event receiving module, a session control sending module, a session control receiving module, a shared memory pool management module, and a graphical interface adaptation layer, is controlled by an independent configuration switch to determine whether it is compiled into the final image.

[0071] The communication role assigned to each instance is entirely determined by the combination of switches in the configuration file, rather than by hard-coding the chip's identity in the code. For example, the first processor instance enables both the frame transmission sending module and the input event receiving module, assuming the responsibility of "sending frame images and receiving remote input"; the second processor instance enables both the frame transmission receiving module and the input event sending module, assuming the responsibility of "receiving frame images and forwarding local input". If the roles of the two instances need to be swapped, only the configuration files of both instances need to be exchanged, without modifying any line of communication code. The actual sending or receiving role undertaken by each instance is determined entirely by the combination of configuration items, not pre-fixed. For example, the first processor instance can act as either a sender or, through configuration, a receiver.

[0072] The framework provides a unified initialization entry function, which executes the initialization of each module in a defined order: first, the service distribution table is reset to ensure a clean state; then, the transport backend is initialized, registering the corresponding backend instances according to the configuration; next, the shared memory pool management module is initialized; and finally, all enabled functional modules are initialized in sequence. This initialization order design ensures that dependencies between layers are satisfied.

[0073] The application scenario of single-image self-test configuration has significant engineering value: During the development phase, developers can simultaneously enable the frame transmission sending module, frame transmission receiving module, input event sending module, and input event receiving module, and select a local loopback backend. Messages sent by the sending module are then directly processed by the local receiving module, forming a complete closed loop. Developers can independently complete all functional verifications on a single chip without waiting for the hardware and software of another chip to be ready.

[0074] Multiprocessor systems: Reference Figure 6 As shown, the present invention also provides a multiprocessor system, including a first processor, a second processor, shared memory, a message channel, and a memory.

[0075] The shared memory configuration provides a shared storage area accessible to both the first and second processors. The message channel configuration provides a control link independent of the shared storage area for transmitting control information.

[0076] The memory stores a computer program that, when executed by a first processor, causes the first processor, as a first processor instance, to implement the above-described method steps for the sending end; and when executed by a second processor, causes the second processor, as a second processor instance, to implement the above-described method steps for the receiving end.

[0077] The communication roles of the first and second processor instances can be flexibly determined through configuration. In one configuration, the first processor instance is configured to enable frame transmission and input event reception, and the second processor instance is configured to enable frame reception and input event transmission. In another configuration, by switching configurations, both the first and second processor instances enable frame reception and input event transmission.

[0078] This invention provides a cross-processor instance data transmission method and a multiprocessor system. Through service-oriented logical addressing and a descriptor-driven zero-copy frame transmission mechanism, communication functions are abstracted into a combination of service identifiers and instance identifiers. This allows the same codebase to adapt to different communication role combinations through configuration, solving the problem of binding communication interfaces to processor identities in traditional solutions. By separating the transmission paths of control information and pixel data, control description information carries only metadata and is transmitted via the control link, while large blocks of pixel data are transmitted directly through a shared storage area, significantly improving cross-processor data transmission efficiency. The transmission backend abstraction layer supports flexible switching between message passing backends and local loopback backends, enabling complete closed-loop self-testing in a single-processor instance environment, greatly reducing development and debugging barriers. The handshake response protocol and timeout protection mechanism between control description information and processing completion feedback information ensure the safe reuse of frame buffers, avoiding data races and buffer leaks. Through critical section protection of intermediate variables and a double-buffer mechanism, the message receiving thread and the interface rendering thread are completely decoupled, eliminating race conditions caused by cross-thread calls to the graphical interface library interface at the architectural level, ensuring system stability.

[0079] Those skilled in the art will understand that, besides implementing the system and its various devices, modules, and units provided by this invention in the form of purely computer-readable program code, the same functions can be achieved entirely through logical programming of the method steps, making the system and its various devices, modules, and units of this invention function in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, the system and its various devices, modules, and units provided by this invention can be considered as a hardware component, and the devices, modules, and units included therein for implementing various functions can also be considered as structures within the hardware component; alternatively, the devices, modules, and units for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0080] Specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the specific embodiments described above, and those skilled in the art can make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. Unless otherwise specified, the embodiments and features described in this application can be arbitrarily combined with each other.

Claims

1. A method for data transmission across processor instances, applied to a first processor instance, wherein the first processor instance is communicatively connected to a second processor instance, characterized in that, include: In response to the target data to be transmitted, a target storage block is allocated in the shared storage area shared by the first processor instance and the second processor instance, and the target data is written into the target storage block; A first cache coherence operation is performed on the target storage block to make the written target data visible to the second processor instance; Control description information is sent to the second processor instance via a control link independent of the shared storage region, using logical addressing, to achieve multiplexing of communication traffic for multiple logical services on a single physical communication endpoint; wherein, the logical addressing abstracts the communication function into a combination of service identifier and instance identifier, and appends the service identifier and instance identifier to the data packet when sending; the control description information contains the relative address of the target storage block, instructing the second processor instance to read the target data from the shared storage region based on the relative address; In response to receiving processing completion feedback information from the second processor instance via the control link, the target storage block is reclaimed; the processing completion feedback information includes identification information corresponding to the target storage block.

2. The data transfer method across processor instances according to claim 1, characterized in that, Performing the first cache consistency operation on the target storage block includes: After the target data is written to the target storage block and before the control description information is sent, a cache refresh operation and a memory barrier operation are performed on the target storage block to synchronize the target data in the local cache of the first processor instance to physical memory and prevent instruction reordering.

3. The data transmission method across processor instances according to claim 2, characterized in that, The shared storage area is divided into multiple storage slots, and each storage slot maintains an occupancy status flag. Allocating a target storage block in a shared storage area shared by the first processor instance and the second processor instance includes: traversing the plurality of storage slots, allocating the storage slots whose occupancy status is marked as free as the target storage block, and updating their occupancy status to occupied. Reclaiming the target storage block includes: restoring the occupied status flag of the target storage block to the free state; The relative address is the offset address of the target storage block in the shared storage area, so that the second processor instance can calculate the local virtual address for reading the target data based on the offset address and the local shared memory base address of the second processor instance.

4. The cross-processor instance data transfer method according to claim 1, characterized in that, The control description information also includes the data size, data format identifier, and response indication flag of the target data; The control link is an independent communication channel established based on a message passing mechanism. The control description information is transmitted in the form of message packets through the control link, and the target data is transmitted with zero copy through the shared storage area.

5. The cross-processor instance data transfer method according to claim 4, characterized in that, The method further includes: When sending the control description information, the sending timestamp of the target storage block is recorded; Initiate timeout monitoring for the target storage block. If the processing completion feedback information containing the corresponding identifier information of the target storage block is not received through the control link within a preset time threshold, the target storage block is forcibly reclaimed, and a timeout alarm is generated.

6. The data transfer method across processor instances according to claim 1, characterized in that, The control link adopts a logical addressing model, abstracting communication functions into a combination of service identifiers and instance identifiers; Control description information is sent to the second processor instance via a control link independent of the shared storage region, including: The service identifier and the instance identifier are appended to the data packet containing the control description information, and the data packet is sent through a single physical communication endpoint to achieve multiplexing of communication traffic for multiple logical services on the single physical communication endpoint.

7. The data transfer method across processor instances according to claim 6, characterized in that, The underlying transmission backend of the control link includes a message passing backend and a local loopback backend; When configured as the messaging backend, cross-processor communication is performed via the single physical communication endpoint through the messaging interface provided by the operating system. When configured as the local loopback backend, the data packet is intercepted, and without passing through the single physical communication endpoint, the receiving processing function that matches the service identifier and the instance identifier is directly searched in the local service distribution table for delivery, so as to perform closed-loop testing in a single-processor instance environment.

8. A method for data transmission across processor instances, applied to a second processor instance, wherein the second processor instance is communicatively connected to a first processor instance, characterized in that, include: Control description information from the first processor instance is received via a control link independent of the shared storage region. The control description information includes the relative address of the target storage block, which is the block in the shared storage region where the first processor instance allocates and writes target data. Based on the relative address, a second cache coherence operation is performed on the target storage block in the shared storage area to ensure that the latest data written by the first processor instance is read and the target data is read from the target storage block; The target data is processed, and a processing completion feedback message is sent to the first processor instance via the control link to instruct the first processor instance to reclaim the target storage block; the processing completion feedback message includes identification information corresponding to the target storage block.

9. The data transfer method across processor instances according to claim 8, characterized in that, The second processor instance includes a message receiving thread and a UI rendering thread, and the processing of the target data includes: In the message receiving thread, the read target data is written to the backend buffer; Under critical section protection, the pointers of the front-end buffer and the back-end buffer are swapped, and a frame ready flag is set so that when the interface rendering thread detects the frame ready flag, it reads the target data from the front-end buffer for rendering. Specifically, the message receiving thread has exclusive write access to the backend buffer, the interface rendering thread has exclusive read access to the frontend buffer, and the critical section only protects pointer swapping and flag setting operations.

10. A multiprocessor system, characterized in that, include: First processor, second processor, shared memory, message channel, and storage; The shared memory is configured to provide a shared storage area that can be accessed by both the first processor and the second processor; The message channel is configured to provide a control link independent of the shared storage area; The memory stores a computer program, which, when executed by the first processor, causes the first processor, as a first processor instance, to implement the method as described in any one of claims 1 to 7; and when executed by the second processor, causes the second processor, as a second processor instance, to implement the method as described in any one of claims 8 or 9.

Images