Vehicle-mounted video sharing method based on PCIe bus and automobile central platform

Abstract

The application relates to the technical field of vehicles, in particular to a vehicle-mounted video sharing method based on a PCIe bus, an automobile central platform, an electronic device and a computer readable storage medium. The method comprises the following steps: a plurality of system-level chips are connected in communication through a PCIe switch; in each system-level chip, an independent shared memory space is respectively allocated for each camera; when any system-level chip acquires video data, the video data is stored in the local shared memory space, and the video data is transmitted to a PCIe domain space through direct memory access after address mapping; other system-level chips acquire the video data from the PCIe domain space and store the video data in the local shared memory space; and in response to a reading request of the video data of an application program running on any system-level chip, the video data is read from the local shared memory space by the application program.

Description

Technical Field

[0001] This application relates to the field of automotive technology, and more specifically, to a PCIe bus-based in-vehicle video sharing method, an automotive central platform, electronic devices, and computer-readable storage media. Background Technology

[0002] With the development of automotive intelligence, functions such as autonomous driving and smart cockpits are placing increasing demands on computing power and communication. Currently, automotive electronic architecture is evolving from distributed control to a centralized central platform. Under this central platform architecture, multiple cameras are typically deployed inside the vehicle, covering forward, rear, and surround view functions, forming the vehicle's visual perception system. The video data collected by these cameras needs to be shared among multiple computing units on the central platform to support the collaborative operation of different in-vehicle applications. In existing technologies, in-vehicle Ethernet is typically used as the transmission medium for video data between these computing units.

[0003] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0004] One or more aspects of this application provide a PCIe bus-based in-vehicle video sharing method, an automotive central platform, electronic devices, and a computer-readable storage medium.

[0005] According to a first aspect of this application, a vehicle-mounted video sharing method based on a PCIe bus is provided, comprising: connecting multiple system-on-a-chip (SoCs) via a PCIe switch; allocating an independent shared memory space for each camera within each SoC; when any SoC acquires video data, storing the video data in its local shared memory space, and transmitting the video data to the PCIe domain space via direct memory access after address mapping; other SoCs acquiring the video data from the PCIe domain space and storing it in their local shared memory spaces; and responding to a read request for the video data from an application running on any SoC, having the application read the video data from its local shared memory space.

[0006] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, the plurality of system-on-a-chips includes a root complex chip and at least one endpoint chip.

[0007] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, before transmitting the video data to the PCIe domain space via direct memory access after address mapping, the method further includes: encapsulating the video data into a PCIe video transmission protocol packet, wherein the PCIe video transmission protocol packet includes a camera location field, a command field, a data length field, and a data field.

[0008] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, the command field is used to identify a data transmission command, and the receiving end determines whether to perform a data extraction operation by detecting the value of the command field.

[0009] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, the video data is transmitted to the PCIe domain space via direct memory access after address mapping, including: transmitting the video data from user mode to kernel mode through memory mapping, mapping the local central processing unit domain address to the PCIe domain address by the kernel mode, and transmitting the video data to the PCIe domain space via direct memory access.

[0010] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, other system-on-a-chips obtain the video data from the PCIe domain space, including: after receiving an interrupt signal, the other system-on-a-chips extract the video data from the PCIe domain space and transmit the video data to user space for parsing through memory mapping.

[0011] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, when the system-on-a-chip that acquires the video data is an endpoint chip, the endpoint chip first sends the video data to the root complex chip, the root complex chip receives the video data, stores the video data in its local shared memory space, and sends the video data to at least one other endpoint chip.

[0012] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, when the system-on-a-chip that acquires the video data is the root complex chip, the root complex chip stores the video data in its local shared memory space and then distributes the video data to at least one endpoint chip.

[0013] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, when multiple applications simultaneously request to read video data in the same shared memory space, scheduling is performed according to the priority of each application and a first-in-first-out strategy.

[0014] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, the scheduling includes: when a high-priority application requests to read the video data, the high-priority application preempts the execution resources of the low-priority application currently reading the data; when an application of the same priority requests to read the video data, the applications of the same priority are queued in a first-in-first-out order; when a low-priority application requests to read the video data, the low-priority application enters a blocked state.

[0015] As an alternative or supplement to the above solutions, in a method according to an embodiment of this application, the priority of the applications is set as follows: applications related to the safety of occupants are set to the highest priority; applications related to parking visual perception, single-vehicle imaging, and panoramic surround view display are set to the second highest priority; and applications related to the entertainment system are set to the lowest priority.

[0016] According to a second aspect of this application, an automotive central platform is provided, comprising: a PCIe switch; and multiple system-on-chips (SoCs) communicatively connected via the PCIe switch; wherein each SoC includes: a shared memory space, independently allocated for each camera; a video capture module configured to, when acquiring video data, store the video data in its local shared memory space and transmit the video data to the PCIe domain space via direct memory access after address mapping; and a video acquisition module configured to acquire video data transmitted from other SoCs from the PCIe domain space and store it in its local shared memory space; wherein an application running on any SoC is configured to: read the video data from its local shared memory space in response to a request to read the video data.

[0017] According to a third aspect of this application, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform any one of the methods described according to the first aspect of this application.

[0018] According to a fourth aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium including instructions that, when executed, perform any one of the methods described according to a first aspect of this application.

[0019] The in-vehicle video sharing method according to one or more embodiments of this application connects multiple system-on-a-chip (SoC) chips via a PCIe switch, and pre-allocates independent shared memory space for each camera within each SoC chip. This allows any chip to acquire video data, store it in its local shared memory, and simultaneously transmit it to the PCIe domain space via direct memory access after address mapping. Other chips can then retrieve the video data from the PCIe domain space and store it in their respective local shared memory. When an application initiates a read request, it directly retrieves the video data from the local shared memory of its respective chip. This method utilizes the high bandwidth of the PCIe bus to achieve fast video data transmission between chips. Simultaneously, by pre-distributing video data to the local shared memory of all chips, applications can obtain remote video data through local access, effectively reducing video access latency, simplifying the process of obtaining video data for applications, and providing an efficient transmission and access mechanism for video sharing in a multi-chip architecture. Attached Figure Description

[0020] The above and / or other aspects and advantages of this application will become clearer and more readily understood from the following description taken in conjunction with the accompanying drawings, in which the same or similar elements are denoted by the same reference numerals. In the drawings: Figure 1 This is a schematic flowchart of an in-vehicle video sharing method 10 according to one or more embodiments of this application; Figure 2 This is a schematic flowchart of an in-vehicle video sharing method 20 according to one or more embodiments of this application; Figure 3 This is a schematic flowchart of an in-vehicle video sharing method 30 according to one or more embodiments of this application; Figure 4 A schematic block diagram of a vehicle central platform 40 according to one or more embodiments of this application; Figure 5 This is a schematic block diagram of an electronic device 50 according to one or more embodiments of this application. Detailed Implementation

[0021] The following detailed description is merely exemplary in nature and is not intended to limit the disclosed technology or its application and use. Furthermore, it is not intended to be bound by any express or implied theory presented in the foregoing technical fields, background art, or the following detailed description.

[0022] In the following detailed description of the embodiments, numerous specific details are set forth in order to provide a more thorough understanding of the disclosed technology. However, it will be apparent to those skilled in the art that the disclosed technology can be practiced without these specific details. In other instances, well-known features have not been described in detail to avoid unnecessarily complicating the description.

[0023] Terms such as "comprising" and "including" indicate that, in addition to the units and steps directly and explicitly described in the specification, the technical solution of this application does not exclude the presence of other units and steps not directly or explicitly described. Terms such as "first" and "second" do not indicate the order of the units in terms of time, space, size, etc., but are merely used to distinguish the units. The technology of this application is generally used in electric vehicles, including but not limited to battery electric vehicles (BEVs), hybrid electric vehicles (HEVs), and fuel cell electric vehicles (FCEVs).

[0024] In the following, exemplary embodiments according to this application will be described in detail with reference to the accompanying drawings.

[0025] Please refer to the attached diagram below. Figure 1 This is a schematic flowchart of an in-vehicle video sharing method 10 according to one or more embodiments of this application.

[0026] In step 101, multiple system-on-a-chips are connected via a PCIe switch.

[0027] PCIe, short for Peripheral Component Interconnect Express, is a high-speed serial computer expansion bus standard widely used in computers and embedded systems to achieve high-bandwidth, low-latency communication between chips or devices. A PCIe switch is a switching device based on the PCIe bus protocol, used to achieve high-speed interconnection between multiple system-on-a-chip (SoC). A system-on-a-chip (SoC) is a system-on-a-chip that integrates a processor, memory controller, and input / output interfaces; in this application, it is used as a computing unit in an automotive central platform. Connecting multiple SoCs via a PCIe switch forms a hardware topology with the PCIe bus as its backbone, providing a physical channel for high-speed transmission of video data between chips. In this topology, each SoC is connected to the PCIe switch via an independent PCIe link, allowing point-to-point or one-to-many data transmission between chips based on the PCIe protocol.

[0028] In one or more embodiments, the hardware configuration of multiple system-on-a-chip (SoCs) can take various forms. For example, all SoCs can be configured as peer nodes, communicating directly with each other via a PCIe switch; alternatively, some chips can be configured as master nodes, and the rest as slave nodes, depending on actual system requirements. In one or more embodiments, the multiple SoCs include a root complex chip and at least one endpoint chip. The root complex chip (RC) is the root node in the PCIe architecture, responsible for managing the PCIe bus topology, enumerating devices, and handling bus transactions; the endpoint chip (EP) acts as a terminal device on the PCIe bus, interacting with the root complex chip or other endpoint chips. This configuration method clearly defines the roles of each chip in the PCIe bus architecture, facilitating the orderly management of bus resources and the orderly transmission of video data. For example, in a specific system architecture, SoC SOC-1 can be configured as the root complex chip, and SoCs SOC-2 and SOC-3 can be configured as endpoint chips, with the chips interconnected via a PCIe switch.

[0029] In one or more embodiments, the camera can be connected to any system-on-a-chip, not limited to a root complex chip or a specific endpoint chip, thereby providing flexibility in the physical deployment of the camera and adapting to the different requirements of different vehicle models for the number of camera interfaces.

[0030] In step 103, each system-on-a-chip allocates an independent shared memory space for each camera.

[0031] Shared memory refers to a specific storage area within the internal memory of a system-on-a-chip (SoC), which can be directly accessed by applications or software modules running on that SoC. By allocating a separate shared memory space for each camera, the video data for each camera has its own dedicated storage location on each SoC. Video data from different cameras is isolated from each other in storage, avoiding data commingling. This allocation method lays the foundation for subsequent cross-chip sharing of video data, allowing applications on any SoC to directly obtain the required camera's video data from their local shared memory space without needing to access it across chips, thereby reducing video data access latency.

[0032] In one or more embodiments, the allocation of shared memory space can be completed during the system initialization phase. For example, at system startup, based on the number and identifiers of cameras configured in the central platform, a fixed-size storage area is reserved in the memory of each system-on-a-chip (SoC). In one or more embodiments, the allocation of shared memory space can also be dynamic. For example, when a new camera is connected to the central platform, each SoC dynamically allocates a corresponding shared memory space for it. Regardless of whether static or dynamic allocation is used, it is necessary to ensure that the shared memory spaces allocated for the same camera in each SoC have consistent identifiers or correspondences to facilitate the location and access of video data.

[0033] In one or more embodiments, the size of the shared memory space can be configured based on factors such as the camera's resolution, frame rate, and encoding format. For example, a larger shared memory space can be allocated to a high-resolution, high-frame-rate camera to accommodate multiple frames of video data; a smaller shared memory space can be allocated to a low-resolution, low-frame-rate camera. In one or more embodiments, the size of the shared memory space allocated by each system-on-a-chip (SoC) for the same camera can be the same, or it can vary depending on the actual purpose of each chip. For example, a SoC that performs the main video processing tasks can allocate a larger shared memory space to the camera, while a SoC that only performs video forwarding tasks can allocate a smaller shared memory space. This flexible memory allocation strategy helps optimize the overall system memory resource utilization.

[0034] In step 105, when any system-on-a-chip acquires video data, it stores the video data in the local shared memory space and then transmits the video data to the PCIe domain space through direct memory access after address mapping.

[0035] The "acquiring video data" mentioned here refers to the system-on-a-chip (SoC) capturing the raw video stream through a locally connected camera. After the video data is stored in the local shared memory space, local storage of the video data at the sending end is complete. To enable the transmission of video data to other SoCs, it needs to be sent out via the PCIe bus. Address mapping refers to mapping the shared memory region in the local Central Processing Unit (CPU) domain address space to the PCIe domain address space, allowing the PCIe bus to directly access the data in that memory region. Direct Memory Access (DMA) is a technology that allows data transfer between memory and external devices without CPU intervention. Through address mapping and DMA transfer, video data can be transferred directly from local shared memory to the PCIe domain space via hardware offloading, eliminating the need for CPU data copying, thus significantly improving transmission efficiency and reducing CPU load.

[0036] In one or more embodiments, before transmitting video data to the PCIe domain space via DMA after address mapping, a step of protocol encapsulation of the video data may be included. Specifically, the video data is encapsulated into a PCIe video transmission protocol packet, which includes a camera location field, a command field, a data length field, and a data field. The camera location field identifies which camera the video data originates from, facilitating the receiving end to identify and store it in the corresponding shared memory space; the command field identifies the data transmission command; the data length field indicates the effective length of the data field; and the data field carries the original video data. Through this custom protocol encapsulation, the video data can carry necessary metadata during transmission on the PCIe bus, ensuring that the receiving end can correctly parse and store it.

[0037] In one or more embodiments, a command field is used to identify a video data transmission command. The receiving end determines whether new video data has arrived by polling the value of the command field. For example, when the command field is set to a first value (e.g., 1), it indicates a video data transmission request; upon detecting this value, the receiving end extracts the video data from the PCIe domain space and stores it in local shared memory. When the command field is set to a second value (e.g., 0), it indicates an idle state, and the receiving end does not perform the extraction operation. This command mechanism allows the sending end to actively initiate data transmission, and the receiving end can detect the arrival of data through simple polling, without relying on interrupt signals, thus simplifying the implementation logic of the receiving end.

[0038] In one or more embodiments, the address mapping and DMA transfer are implemented as follows: First, video data is transferred from user space to kernel space via memory mapping (mmap). User space refers to the execution state of an application running at a lower privilege level, unable to directly access hardware resources; kernel space refers to the execution state of the operating system kernel running at a higher privilege level, capable of directly accessing hardware resources. mmap maps the shared memory space to the kernel address space, enabling the kernel to directly access this memory region. Subsequently, the kernel maps the local CPU domain address to the PCIe domain address, that is, converting the physical address of the shared memory space into an address recognizable by the PCIe bus. Finally, the DMA controller transfers the video data from the shared memory space to the PCIe domain space, completing the hardware offloading and transmission of the data. This series of operations achieves a zero-copy data transfer path from the user-space application to the PCIe bus, avoiding multiple copies of data between kernel space and user space, further reducing transmission latency.

[0039] In step 107, other system-on-a-chip obtains video data from the PCIe domain space and stores it in local shared memory space.

[0040] The PCIe domain space, serving as a unified address space on the PCIe bus, stores video data transmitted via DMA by the source system-on-a-chip (SoC). Other SoCs access this address space through the PCIe bus, extract the video data, and store it in their respective local shared memory spaces allocated for that camera. Through this process, video data is distributed from the source SoC to all other SoCs, achieving unified storage of video data in the shared memory of each chip, laying the foundation for subsequent local reading by applications.

[0041] In one or more embodiments, the process of other system-on-a-chip (SoCs) acquiring video data from the PCIe domain space is triggered by an interrupt signal. Specifically, after the source SoC transmits video data to the PCIe domain space, it can send an interrupt signal (such as a Message Signaled Interrupt (MSI)) to other SoCs. Upon receiving the interrupt signal, other SoCs can extract the video data from the PCIe domain space and transmit it to user space for parsing via memory mapping (mmap). The user-space parsing process may include identifying information such as the camera identifier and data length corresponding to the video data to determine where the video data should be stored in local shared memory. This interrupt-driven receiving mechanism enables the receiving end to respond promptly to the arrival of video data, avoiding the resource consumption caused by polling.

[0042] In one or more embodiments, the transmission path of video data between system-on-a-chip (SoC) can vary depending on the roles of the source and receiver. When an endpoint chip acts as the video source, the video data can be transmitted via multiple paths. For example, an endpoint chip can directly transmit video data to other endpoint chips, achieving point-to-point transmission; alternatively, an endpoint chip can transmit video data to the root composite chip, which then distributes it uniformly.

[0043] In one or more embodiments, when the system-on-a-chip (SoC) acquiring video data is an endpoint chip, the endpoint chip first sends the video data to the root composite chip. The root composite chip receives the video data, stores it in its local shared memory space, and then sends the video data to at least one other endpoint chip. This transmission method, which uses the root composite chip as a central node for unified distribution, facilitates centralized management and load balancing of the transmission path.

[0044] When the root composite chip acts as the video source, video data transmission can also employ various methods. For example, the root composite chip can send video data to some endpoint chips or to all endpoint chips; alternatively, the root composite chip can selectively send data based on the load of each endpoint chip or application requirements. In one or more embodiments, when the system-on-a-chip acquiring video data is the root composite chip, the root composite chip stores the video data in its local shared memory space and then distributes the video data to at least one endpoint chip. This direct distribution method eliminates intermediate relay links, further reducing transmission latency.

[0045] Regardless of the transmission path used, other system-on-a-chip (SoCs) retrieve video data from the PCIe domain and store it in their local shared memory. Thus, each camera's video data has a complete copy in the local shared memory of each SoC, enabling pre-distribution of video data among the chips and providing a data foundation for local reading by applications.

[0046] In step 109, in response to a request from an application running on any system-on-a-chip to read video data, the application reads the video data from the local shared memory space.

[0047] Since the video data for each camera has been pre-distributed to the local shared memory space of all system-on-a-chip (SoC) via the PCIe bus in the preceding steps, when an application initiates a read request, it does not need to access across chips; it can directly read the required video data from the local shared memory of its respective SoC. This remote video localization access mechanism allows applications to obtain video captured by remote cameras by accessing local data, avoiding the additional latency and communication overhead caused by cross-chip access, and significantly improving the efficiency of video data access.

[0048] In one or more embodiments, multiple applications may simultaneously request to read video data from the same shared memory space. Since the shared memory space is a critical resource, concurrent access by multiple applications needs to be coordinated to ensure data consistency and integrity. For this purpose, a scheduling mechanism can be used to manage the application read requests. For example, when multiple applications simultaneously request to read video data from the same shared memory space, scheduling is performed based on the priority of each application and a first-in-first-out (FIFO) strategy. Priority is used to identify the urgency or importance of the application obtaining the video data, and the FIFO strategy is used to manage the access order of applications with the same priority.

[0049] In one or more embodiments, the scheduling mechanism specifically includes the following processing methods: When a high-priority application requests to read video data, the high-priority application preempts the execution resources of the currently reading low-priority application; that is, the low-priority application pauses reading, and the high-priority application immediately gains access. When applications of the same priority request to read video data, these applications of the same priority are queued in a first-in-first-out order, that is, they gain access in the order their requests arrive. When a low-priority application requests to read video data, the low-priority application enters a blocked state, that is, it waits for other applications currently reading to release their access permissions before it can continue. Through this priority-based scheduling strategy, it is possible to ensure that critical applications obtain video data in a timely manner, while ensuring that ordinary applications are served within the limits of system resources.

[0050] In one or more embodiments, the priority of applications can be set according to their functional attributes. For example, applications related to occupant safety are set to the highest priority, such as driver assistance applications, road recognition applications, and driver behavior monitoring applications. These applications have the highest real-time requirements for video data, and any delay can affect driving safety. Applications related to parking vision perception, single-vehicle imaging, and panoramic surround view displays are set to the second highest priority. While these applications are related to driving, their real-time requirements are slightly lower than those of safety applications. Applications related to the entertainment system are set to the lowest priority, such as rear-seat entertainment systems and streaming media playback applications. These applications have relatively low real-time requirements for video data and can provide services when system resources are idle. This hierarchical priority setting ensures that the video data access needs of critical applications are prioritized when system resources are strained, thereby achieving a balance between resource sharing and service quality.

[0051] The following is for reference. Figure 2 , Figure 2 This is a schematic flowchart of an in-vehicle video sharing method 20 according to one or more embodiments of this application. Figure 2 Method 20 illustrates the complete process of how video data is shared to other system-on-a-chips when it is captured by the local camera of the endpoint chip (EP).

[0052] In step 201, the endpoint chip's local camera acquires video data. This camera can be connected to the endpoint chip's camera interface to obtain the raw video stream through the video capture module.

[0053] In step 203, the video capture module of the endpoint chip stores the captured video data into the shared memory space allocated locally for the camera, and sends a message (msg) to the local PCIe video stream transmission module to notify it that there is new video data to be transmitted.

[0054] In step 205, the PCIe video stream module of the endpoint chip responds to the received message, extracts video data from the shared memory space, and encapsulates it into a PCIe video transmission protocol packet. Additionally, the command field can be set to 1 to indicate that a data transmission request is initiated.

[0055] In step 207, the endpoint chip transmits the encapsulated PCIe video transmission protocol packet from user space to kernel space via memory mapping (mmap).

[0056] In step 209, the kernel mode of the endpoint chip maps the local CPU domain address to the PCIe domain address, that is, converts the physical address of the shared memory space in the CPU domain into an address recognizable by the PCIe bus. Subsequently, video data is transferred from the shared memory space to the PCIe domain space via Direct Memory Access (DMA).

[0057] In step 211, after the video data transmission is completed, the endpoint chip sends a Message Signal Interrupt (MSI) to the root complex chip to notify it that the video data has arrived in the PCIe domain space.

[0058] In step 213, after receiving an interrupt signal, the PCIe video acquisition module of the root complex chip extracts video data from the PCIe domain space. This module obtains the video data by reading the PCIe domain address space and stores it in the kernel-mode buffer.

[0059] In step 215, the root composite chip transfers video data from kernel mode to user mode via memory mapping (mmap), and parses the PCIe video transport protocol packets in user mode. The parsing process may include reading the camera location field to identify which camera the video data originates from, reading the command field to determine if the current operation type is a data transfer request, reading the data length field to determine the data size, and extracting the raw video data from the data fields. After parsing, the root composite chip stores the video data in the shared memory space allocated locally for that camera, allowing local applications on the root composite chip to directly access the video data.

[0060] In step 217, the root complex chip's video distribution module re-encapsulates the video data into PCIe video transport protocol packets. Additionally, the command field can be set to 1 or maintained at 1 to indicate the initiation of a data transmission request. The root complex chip can determine the target endpoint chips that need to receive the video data based on system configuration or application requirements. For example, the root complex chip can send the video data to all other endpoint chips, or selectively send it to some endpoint chips according to a load balancing strategy.

[0061] In step 219, the root complex chip transmits the repackaged protocol packet to the kernel mode of the target endpoint chip (e.g., EP-2) via memory mapping (mmap). The kernel mode of the target endpoint chip then uses DMA to transfer the video data from the kernel mode to the address mapped in the PCIe domain for retrieval by the receiving end.

[0062] In step 221, the PCIe video acquisition module of the target endpoint chip polls and detects the PCIe domain mapping address. When the command field is detected to be 1, it indicates that the receiving end needs to extract video data from the mapping address. At this time, the video data is extracted from the mapping address, and the command field is cleared to remove the flag.

[0063] In step 223, the target endpoint chip transmits video data from kernel mode to user mode through memory mapping (mmap), and parses PCIe video transmission protocol packets in user mode.

[0064] In step 225, the target endpoint chip stores the parsed video data into the shared memory space allocated locally for the camera. At this point, the video data has been transferred from the source endpoint chip through the root composite chip and finally stored in the local shared memory of the target endpoint chip.

[0065] The following is for reference. Figure 3 , Figure 3 This is a schematic flowchart of an in-vehicle video sharing method 30 according to one or more embodiments of this application. Figure 3 Method 30 shown details the complete process of how video data, when captured by a local camera on the root composite chip, is directly shared to other system-on-a-chip. Figure 2 The method shown is different from 20. Figure 3 The Zhonggen composite chip, as the video source, directly distributes video data to each endpoint chip without going through an intermediate relay.

[0066] In step 301, the root complex chip's local camera acquires video data. This camera can be connected to the root complex chip's camera interface to obtain the raw video stream through the video capture module.

[0067] In step 303, the video capture module of the root composite chip stores the captured video data into the shared memory space allocated locally for the camera, and sends a message to the local PCIe video stream transmission module to notify it that there is new video data to be transmitted.

[0068] In step 305, the PCIe video stream module of the root composite chip responds to the received message, extracts video data from the shared memory space, and encapsulates it into a PCIe video transmission protocol packet. This protocol packet includes a camera position field (position), a command field (cmd), a data length field (data_len), and a data field (data). In this step, the root composite chip, acting as the video source, initiates data transmission; the command field can be set to 1 to indicate that a video data transmission request has been initiated.

[0069] In step 307, the root complex chip transmits the encapsulated PCIe video transmission protocol packet from user space to kernel space via memory mapping (mmap).

[0070] In step 309, the kernel mode of the root complex chip maps the local CPU domain address to the PCIe domain address, that is, converts the physical address of the shared memory space in the CPU domain into an address recognizable by the PCIe bus. Subsequently, video data is transferred from the shared memory space to the PCIe domain space via Direct Memory Access (DMA). The root complex chip can determine the target endpoint chips that need to receive the video data based on system configuration or application requirements. For example, the root complex chip can send video data to all endpoint chips simultaneously, or selectively send it to some endpoint chips according to a load balancing strategy. During the DMA transfer, the root complex chip routes the video data to the PCIe domain mapped addresses of each target endpoint chip via a PCIe switch.

[0071] In step 311, the PCIe video acquisition module of each target endpoint chip polls and detects its respective PCIe domain mapping address. When a command field of 1 is detected, it indicates that the receiving end needs to extract video data from the mapping address. At this time, the video data is extracted from the mapping address, and the command field is cleared to remove the flag.

[0072] In step 313, each target endpoint chip transmits video data from kernel mode to user mode via memory mapping (mmap), and parses the PCIe video transmission protocol packets in user mode. The parsing process includes reading the camera location field to determine the camera corresponding to the video data, and reading the data length field and data field to obtain the raw video data.

[0073] In step 315, each target endpoint chip stores the parsed video data into the shared memory space allocated locally for that camera. At this point, the video data has been directly distributed from the root composite chip to each target endpoint chip and stored in the local shared memory of each endpoint chip.

[0074] The following is for reference. Figure 4 , Figure 4 This is a schematic block diagram of a vehicle central platform 40 according to one or more embodiments of this application. Figure 4 As shown, the automotive central platform 40 includes a PCIe switch 410 and multiple system-on-a-chips 420 that are communicatively connected via the PCIe switch.

[0075] The PCIe switch 410 acts as a central switching device, providing a high-speed data transmission channel between the various system-on-chips 420. The multiple system-on-chips 420 may include a root composite chip and at least one endpoint chip, and the camera can be connected to any one of the system-on-chips 420.

[0076] Each system-on-chip (SoC) 420 may include a shared memory space, a video capture module, and a video acquisition module. The shared memory space is independently allocated for each camera and is used to store the corresponding camera's video data. The video capture module is configured to store the acquired video data in its local shared memory space and then transmit it to the PCIe domain space via direct memory access after address mapping. The video acquisition module is configured to retrieve video data transmitted from other SoCs from the PCIe domain space and store it in its local shared memory space. Through the collaborative work of these modules, a complete copy of the video data corresponding to each camera is formed in the local shared memory of each SoC, realizing the pre-distribution of video data among the chips. An application running on any SoC responds to a read request by reading video data from the local shared memory space of its SoC.

[0077] In one or more embodiments, the vehicle central platform 40 may further include a load balancing middleware for allocating read requests based on the load of each system-on-a-chip. When multiple applications simultaneously request to read video data in the same shared memory space, scheduling is performed according to the priority of each application and a first-in-first-out (FIFO) strategy. Higher-priority applications can preempt the execution resources of lower-priority applications, applications of the same priority are queued in FIFO order, and lower-priority applications enter a blocked state.

[0078] Figure 5This is a schematic block diagram of an electronic device 50 according to one or more embodiments of this application. The electronic device 50 is the core hardware carrier for implementing the in-vehicle video sharing method described in this application, and includes a memory 510, a processor 520, and a computer program 530 stored on the memory 510 and executable on the processor 520. In one or more embodiments, the electronic device 50 may be a vehicle central platform, an in-vehicle domain controller, an in-vehicle infotainment system host, an advanced driver assistance system controller, or a vehicle computing unit integrating the above functions. When the processor 520 executes the computer program 530, it implements the method described in any of the above embodiments.

[0079] Furthermore, as described above, this application can also be implemented as a computer-readable storage medium storing a program for causing a computer to perform the methods described in any of the above embodiments. Here, various types of computer-readable storage media can be used, such as disks (e.g., magnetic disks, optical disks, etc.), cards (e.g., memory cards, optical cards, etc.), semiconductor memory (e.g., ROM, non-volatile memory, etc.), and tapes (e.g., magnetic tape, cassette tape, etc.).

[0080] This application can also be implemented as a computer program product, which includes a computer program that, when executed by a processor, implements the method described in any of the above embodiments.

[0081] Where applicable, the various embodiments provided in this application may be implemented using hardware, software, or a combination of hardware and software. Furthermore, where applicable, without departing from the scope of this application, the various hardware and / or software components described herein may be combined into composite components comprising software, hardware, and / or both. Where applicable, without departing from the scope of this application, the various hardware and / or software components described herein may be divided into sub-components comprising software, hardware, or both. Additionally, where applicable, it is contemplated that software components may be implemented as hardware components, and vice versa.

[0082] The software (such as program code and / or data) according to this application can be stored on one or more computer storage media. It is also contemplated that the software identified herein can be implemented using one or more networked and / or otherwise general-purpose or special-purpose computers and / or computer systems. Where applicable, the order of the various steps described herein can be changed, combined into compound steps, and / or divided into sub-steps to provide the features described herein.

[0083] The embodiments and examples presented herein are provided to best illustrate embodiments of this application and its particular applications, thereby enabling those skilled in the art to implement and use this application. However, those skilled in the art will understand that the above description and examples are provided for ease of illustration and example only. The descriptions presented are not intended to cover all aspects of this application or to limit this application to the precise forms disclosed.

Claims

1. A method for sharing in-vehicle video based on a PCIe bus, characterized in that, include: Multiple system-on-a-chips are connected via a PCIe switch; Each system-on-a-chip allocates a separate shared memory space for each camera. When any system-on-a-chip acquires video data, it stores the video data in the local shared memory space, and then transmits the video data to the PCIe domain space through direct memory access after address mapping. Other system-on-a-chip obtains the video data from the PCIe domain space and stores it in local shared memory space; as well as In response to a request from an application running on any system-on-a-chip to read the video data, the application reads the video data from its local shared memory space.

2. The method according to claim 1, wherein, The plurality of system-on-a-chips includes a root complex chip and at least one endpoint chip.

3. The method according to claim 1, wherein, Before transmitting the video data to the PCIe domain space via direct memory access after address mapping, the method further includes: The video data is encapsulated into a PCIe video transmission protocol packet, which includes a camera location field, a command field, a data length field, and a data field.

4. The method according to claim 3, wherein, The command field is used to identify the data transmission command. The receiving end determines whether to perform the data extraction operation by detecting the value of the command field.

5. The method according to claim 1, wherein, The video data is then address-mapped and transmitted to the PCIe domain space via direct memory access, including: The video data is transferred from user space to kernel space through memory mapping. The kernel space maps the local central processing unit domain address to the PCIe domain address and transfers the video data to the PCIe domain space through direct memory access.

6. The method according to claim 1, wherein, Other system-on-a-chips obtain the video data from the PCIe domain space, including: After receiving the interrupt signal, other system-on-a-chip extracts the video data from the PCIe domain space and transmits the video data to user space for parsing via memory mapping.

7. The method according to claim 2, wherein, When the system-on-a-chip that acquires the video data is an endpoint chip, the endpoint chip first sends the video data to the root complex chip. The root complex chip receives the video data, stores the video data in its local shared memory space, and sends the video data to at least one other endpoint chip.

8. The method according to claim 2, wherein, When the system-on-a-chip that acquires the video data is the root complex chip, the root complex chip stores the video data in its local shared memory space and then distributes the video data to at least one endpoint chip.

9. The method according to claim 1, wherein, When multiple applications simultaneously request to read video data from the same shared memory space, scheduling is performed based on the priority of each application and a first-in-first-out (FIFO) strategy.

10. The method according to claim 9, wherein, The scheduling includes: When a high-priority application requests to read the video data, the high-priority application preempts the execution resources of the low-priority application that is currently reading the data. When an application of the same priority requests to read the video data, the applications of the same priority are queued in a first-in-first-out order; When a low-priority application requests to read the video data, the low-priority application enters a blocked state.

11. The method according to claim 9 or 10, wherein, Application priority is set as follows: Applications related to the safety of occupants should be set to the highest priority. Applications involving parking visual perception, single-vehicle imaging, and panoramic surround view display are set to the second highest priority. Applications involving entertainment systems are set to the lowest priority.

12. A central platform for automobiles, characterized in that, include: PCIe switches; Multiple system-on-a-chips are communicated and connected through the PCIe switch; Each system-on-a-chip includes: Shared memory space, allocated independently for each camera; The video capture module is configured to, when acquiring video data, store the video data in a local shared memory space, and then transmit the video data to the PCIe domain space via direct memory access after address mapping. The video acquisition module is configured to acquire video data transmitted by other system-on-a-chip from the PCIe domain space and store it in the local shared memory space. The application running on any system-on-a-chip is configured to read the video data from the local shared memory space in response to a request to read the video data.

13. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes instructions that, when executed, perform the method according to any one of claims 1-11.

Images