Cross-processor communication method, in-vehicle gateway, and electronic device

Abstract

The application discloses a cross-processor communication method, a vehicle-mounted gateway and electronic equipment, and relates to the technical field of electronic communication, and comprises a first processor applied to a vehicle-mounted gateway, the vehicle-mounted gateway further comprises a second processor, the cross-processor communication method comprises the following steps: in response to an access event of a virtual device, an access event is encapsulated into an access request through a preset unified protocol and is sent to the second processor, so that the second processor generates a corresponding execution result, the virtual device is obtained based on corresponding hardware resources of the second processor; and the execution result of the access request is received by the second processor. The application cooperates the virtual device with the unified protocol, so that the application side processor accesses different types of hardware resources in a consistent manner, avoids the communication mode fragmentation problem caused by formulating a communication protocol and running a service process for each type of hardware resource, and reduces the cross-processor communication complexity of the vehicle-mounted gateway.

Description

Technical Field

[0001] This application relates to the field of electronic communication technology, and in particular to cross-processor communication methods, vehicle gateways, and electronic devices. Background Technology

[0002] With the development of automotive intelligence, vehicle gateways are gradually adopting a multi-processor heterogeneous architecture. Different processors undertake application computing and real-time control tasks respectively. The application-side processor is responsible for data processing and business logic, while the real-time-side processor is responsible for physical device management and real-time signal acquisition. When the application-side processor executes upper-layer business, it needs to call various hardware resources managed by the real-time-side processor, which generates the need for cross-processor communication.

[0003] Currently, when application-side processors access hardware resources managed by real-time-side processors, different access methods are typically required for different resource types. This includes defining separate communication protocols, running separate service processes, and providing separate access interfaces. When new hardware resources are added, a new set of access methods must be added. In summary, because the access protocols and logic for each hardware resource are independent, different access methods are required for different hardware resources, resulting in high complexity for cross-processor communication in vehicle gateways.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main objective of this application is to provide a cross-processor communication method, an in-vehicle gateway, and an electronic device, aiming to solve the technical problem that the access protocols and access logic of various hardware resources are independent, and different hardware resources need to adopt different access methods, resulting in high complexity of cross-processor communication of the in-vehicle gateway.

[0006] To achieve the above objectives, this application proposes a cross-processor communication method, wherein the cross-processor communication method is applied to a first processor of an in-vehicle gateway, and the in-vehicle gateway further includes a second processor, and the cross-processor communication method includes: In response to an access event of a virtual device, the access event is encapsulated into an access request and sent to the second processor through a preset unified protocol, so that the second processor can generate a corresponding execution result. The virtual device is created based on the hardware resources corresponding to the second processor. Receive the execution result of the access request from the second processor.

[0007] In one embodiment, the cross-processor communication method further includes: Obtain resource information of at least one hardware resource managed by the second processor; Based on the resource information described, create virtual devices corresponding to each of the hardware resources.

[0008] In one embodiment, the step of obtaining resource information of at least one hardware resource managed by the second processor includes: Send a resource discovery request to the second processor, the resource discovery request being used to instruct the second processor to return the resource information; Receive the resource information returned by the second processor in response to the resource discovery request.

[0009] In one embodiment, the first processor is equipped with a Linux system, the virtual device includes a virtual device interface conforming to the Linux device model framework, and the access event is generated by accessing the virtual device interface.

[0010] In one embodiment, the device types under the Linux device model framework include at least one of SocketCAN devices, TTY devices, and gpiochip devices; The step of creating a virtual device corresponding to each of the hardware resources based on the resource information includes: For each of the aforementioned hardware resources, when the resource type of the resource information is a CAN controller, a SocketCAN device is automatically created as the virtual device. When the resource type of the resource information is a UART serial port controller, a TTY device is automatically created as the virtual device; When the resource type of the resource information is GPIO controller, a gpiochip device is automatically created as the virtual device.

[0011] Furthermore, to achieve the above objectives, this application also proposes a cross-processor communication method, wherein the cross-processor communication method is applied to a second processor of an in-vehicle gateway, the in-vehicle gateway further comprising a first processor, and the cross-processor communication method includes: The system receives an access request sent by the first processor. The access request is obtained by encapsulating the access event of the virtual device of the first processor through a preset unified protocol. The virtual device of the first processor is created based on the hardware resources corresponding to the second processor. Based on the access request, the target hardware in the hardware resources is determined, and the target hardware is controlled to execute the request operation contained in the access request, and an execution result is generated; The execution result is returned to the first processor.

[0012] In one embodiment, the cross-processor communication method further includes: In response to the resource discovery request sent by the first processor, the currently managed hardware resources are queried to obtain resource information; The resource information is sent to the first processor so that the first processor can create virtual devices corresponding to each of the hardware resources.

[0013] In one embodiment, the preset unified protocol includes at least a resource identifier field and a command type field; The steps of determining the target hardware in the hardware resources based on the access request, controlling the target hardware to execute the request operation contained in the access request, and generating the execution result include: Parse the access request to obtain the identifier value corresponding to the resource identifier field and the command value corresponding to the command type field; The target hardware is obtained by querying the hardware resources that match the identifier value. The target hardware is controlled to perform the operation corresponding to the command value, and the execution result is obtained.

[0014] Furthermore, to achieve the above objectives, this application also proposes an in-vehicle gateway, which includes a first processor and a second processor, and the in-vehicle gateway includes: The first processor is configured to respond to access events of a virtual device, encapsulate the access event into an access request using a preset unified protocol, and send it to the second processor so that the second processor can generate a corresponding execution result. The virtual device is created based on the hardware resources corresponding to the second processor. The processor also receives the execution result of the access request from the second processor. The second processor is configured to receive an access request sent by the first processor, wherein the access request is obtained by encapsulating the access event of the virtual device of the first processor through a preset unified protocol, and the virtual device of the first processor is created based on the hardware resources corresponding to the second processor; according to the access request, the second processor determines the target hardware in the hardware resources, controls the target hardware to execute the request operation contained in the access request, generates an execution result, and returns the execution result to the first processor.

[0015] In addition, to achieve the above objectives, this application also proposes an electronic device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the cross-processor communication method as described above.

[0016] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the cross-processor communication method described above.

[0017] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the cross-processor communication method described above.

[0018] One or more technical solutions proposed in this application have at least the following technical effects: In this embodiment, the virtual device is pre-created based on the hardware resources corresponding to the second processor, so that the first processor has an entry point to access the remote hardware resources locally. When the virtual device is accessed, the first processor responds to the access event of the virtual device, encapsulates the access event into an access request through a preset unified protocol and sends it to the second processor, which then performs the corresponding operation and returns the execution result. The first processor receives the execution result returned by the second processor, thus completing cross-processor communication.

[0019] This embodiment creates a virtual device on the first processor as an access point, allowing the application-side processor (first processor) to initiate access without needing to know the actual processor location of the hardware resource. Simultaneously, a pre-defined unified protocol carries access requests to different hardware resources, enabling different types of hardware resources to be accessed through the same protocol. This embodiment, through the cooperation of the virtual device and the unified protocol, allows the application-side processor to access different types of hardware resources in a consistent manner, avoiding the communication fragmentation problem caused by developing separate communication protocols and running service processes for each hardware resource, and reducing the cross-processor communication complexity of the vehicle gateway. Attached Figure Description

[0020] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0021] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a flowchart illustrating the cross-processor communication method of the first processor in an embodiment of this application; Figure 2This is a flowchart illustrating the cross-processor communication method of the second processor in an embodiment of this application; Figure 3 This is a schematic diagram of the module structure of the vehicle gateway according to an embodiment of this application; Figure 4 This is a schematic diagram of the architecture of a feasible vehicle gateway in the embodiments of this application; Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the cross-processor communication method in the embodiments of this application.

[0023] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0024] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0025] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0026] With the rapid development of vehicle electrification, intelligence, and connectivity, the functions of vehicle gateways have been continuously expanded. They have evolved from traditional CAN (Controller Area Network) bus gateways into complex vehicle computing platforms that integrate multiple functions such as 5G communication (5th Generation Mobile Communication Technology), OTA (Over-The-Air) upgrades, cloud platform access, Web (World Wide Web) services, and AI (Artificial Intelligence) applications. To simultaneously meet the demands of high-performance computing and real-time response, current vehicle gateways generally adopt a heterogeneous processor architecture that combines application-side processors and real-time processors. The application-side processor is responsible for running applications and handling complex business logic, including high-computing, non-real-time tasks such as 5G communication, OTA upgrades, cloud platform access, web services, and AI applications. A Linux application processor is used as an example for this purpose. The real-time processor is responsible for real-time control and rapid response to external events, including the control and management of real-time I / O (input / output) resources such as CAN, LIN (Local Interconnect Network), RS232 (Recommended Standard 232), RS485 (Recommended Standard 485), GPIO (General Purpose Input / Output), ADC (Analog-to-Digital Converter), and DI / DO (Digital Input / Digital Output). An MCU (Microcontroller Unit) real-time processor is used as an example for this purpose. When the application-side processor executes upper-layer business logic, it needs to call various hardware resources managed by the real-time-side processor, which creates a need for cross-processor communication.

[0027] Currently, to meet the aforementioned cross-processor communication requirements, the industry mainly offers the following implementation solutions: Option 1: Resource-Independent Protocol Approach. This involves developing separate communication protocols for different types of hardware resources. For example, a separate CAN communication protocol is developed for the CAN controller, a separate GPIO communication protocol for the GPIO controller, and a separate UART (Universal Asynchronous Receiver / Transmitter) communication protocol for the UART serial port controller. Each protocol is implemented and maintained independently. In this approach, the Linux side needs to run a separate daemon process for each resource to handle the corresponding protocol messages.

[0028] Option 2: Resource Proxy Mode. This involves the Linux side accessing MCU-side hardware resources via Remote Procedure Calls (RPCs). For example, separate service processes are maintained for GPIO, CAN, and UART, with each resource corresponding to an independent proxy service.

[0029] Option 3: Resource Transparent Transmission Mode. This involves independently transmitting different types of hardware resources using common protocols such as Ethernet and TCP / IP (Transmission Control Protocol / Internet Protocol). For example, CAN bus data can be transmitted via Ethernet (CAN over Ethernet), and UART serial port data can be transmitted via TCP (UART over TCP). Each resource's transmission method is implemented separately.

[0030] However, in the above approach, different hardware resources are configured with independent access protocols and logic, requiring the Linux side to develop and maintain independent communication protocols, service processes, or proxy services for each resource. When new hardware resources are added, a corresponding new access method must be added. Furthermore, because the access protocols and logic of each hardware resource are independent, Linux applications must use different access methods when accessing different hardware resources. This results in complex cross-processor communication software development for the vehicle gateway, difficulties in system expansion, and fragmented resource management.

[0031] Based on this, the first embodiment of this application provides a cross-processor communication method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating a cross-processor communication method applied to a first processor.

[0032] In this embodiment, the cross-processor communication method is applied to the first processor of the vehicle gateway, and the vehicle gateway further includes a second processor. The cross-processor communication method includes steps S1 to S2: It should be noted that the vehicle gateway is a network interconnection device installed in the vehicle, used to enable data interaction between various electronic control units inside the vehicle, as well as between the vehicle and external networks.

[0033] Additionally, it should be noted that the first processor is the application-side processor in the vehicle gateway, used to run the operating system, applications, and handle complex business logic. The operating system on the first processor can be Linux, QNX, Android, etc., preferably Linux. The first processor is responsible for handling high-computing, non-real-time tasks, including but not limited to 5G communication, OTA upgrades, cloud platform access, web services, and AI applications. The application layer of the first processor runs the vehicle gateway's business programs, including Linux CAN tools, Python / ROS (Robot Operating System) applications, and customer-customized applications. The applications access virtual devices through the first processor's operating system standard device access interface.

[0034] Additionally, it should be noted that the second processor is the real-time side processor in the vehicle gateway, used for real-time control and rapid response to external events. The second processor manages various hardware resources and is responsible for managing real-time I / O resources, including but not limited to: CAN, LIN, RS232, RS485, GPIO, ADC, and DI / DO. The second processor can be implemented using an MCU (microcontroller).

[0035] In one embodiment, the first processor is a Linux application processor and the second processor is an MCU real-time processor. The technical solution of this application will be described in detail below using this as an example. The Linux application processor and the MCU real-time processor are connected via a communication link, which includes, but is not limited to, high-speed communication interfaces such as Ethernet, PCIe (Peripheral Component Interconnect Express), USB (Universal Serial Bus), and shared memory.

[0036] Step S1: In response to the access event of the virtual device, the access event is encapsulated into an access request through a preset unified protocol and sent to the second processor so that the second processor can generate the corresponding execution result. The virtual device is created based on the hardware resources corresponding to the second processor. It should be noted that a virtual device is a software entity created by the first processor in the operating system based on the hardware resources managed by the second processor. It is used to map remote hardware resources to local standard devices. The first processor is responsible for creating and maintaining the virtual device, which includes its device status, operating interface, and correspondence with hardware resources. In essence, the virtual device appears as a standard device in the first processor's operating system. Applications do not need to be aware of the actual processor location of the hardware resource to access the virtual device as if it were a local device, thus achieving transparent access to remote hardware resources.

[0037] Additionally, it should be noted that access events are generated by applications accessing virtual devices, and these access events include, but are not limited to, read events, write events, and control events. For example, an application generates a read event when performing a read operation on a virtual device, a write event when performing a write operation, a control event when configuring parameters or sending control commands, an open event when performing an open operation, and a close event when performing a close operation. The first processor generates corresponding access events based on the application's access to the virtual device and determines the target hardware resource and the operation to be performed accordingly.

[0038] Additionally, it should be noted that the pre-defined unified protocol is a pre-agreed communication protocol between the first and second processors, used to carry access requests for different types of hardware resources. The pre-defined unified protocol defines a unified data frame format, which may include a data header, a resource identifier field, a command type field, a data length field, a data payload field, and a verification information field. Specifically, the data header indicates the start and synchronization information of the data frame; the resource identifier field identifies the target hardware resource to be accessed; the command type field indicates the type of operation to be performed; the data length field indicates the length of the data payload; the data payload field carries the specific data required for the operation; and the verification information field is used for data integrity verification.

[0039] Understandably, by using a pre-defined unified protocol, access requests for different types of hardware resources are transmitted through the same physical communication link. This eliminates the need to establish separate physical links or logical channels for each type of hardware resource, enabling multiple heterogeneous resources to share the same physical communication link and reducing system resource consumption and communication management complexity. Only one protocol stack needs to be maintained between the first and second processors to access all types of hardware resources, further simplifying the system architecture.

[0040] Additionally, it should be noted that the default unified protocol also supports the second processor proactively sending resource status notifications to the first processor. Resource status notifications are used by the second processor to proactively report status change information to the first processor when the status of the hardware resources it manages changes. Resource status notifications include, but are not limited to, events such as CAN bus off, UART serial port anomalies, GPIO pin level changes, and hardware resource offline. Through this resource status notification mechanism, the first processor can promptly learn about the status changes of hardware resources on the second processor side without frequent polling, reducing cross-processor communication overhead and improving the system's response efficiency to hardware resource status changes.

[0041] Additionally, it should be noted that the access request is a data frame generated by the first processor based on the access event of the virtual device using a preset unified protocol.

[0042] For example, consider a user reading CAN bus data using a CAN tool. The application sends a read data request (i.e., an access event) to the SocketCAN (CAN based on the Socket interface) virtual device in the first processor. The first processor determines the target hardware resource as a CAN controller and the operation to be performed as reading CAN data based on the access event. Then, it encapsulates the access event into an access request conforming to a preset unified protocol and sends it to the second processor via Ethernet. The second processor then controls the corresponding CAN controller to perform the data reading operation based on the access request.

[0043] Step S2: Receive the execution result of the second processor on the access request.

[0044] It should be noted that after receiving the access request, the second processor parses the request to determine the target hardware resource and the operation to be executed, controls the corresponding hardware resource to execute the operation and generates an execution result, and then returns the execution result to the first processor. The first processor receives the execution result returned by the second processor, completing this cross-processor communication. After receiving the execution result returned by the second processor, the first processor also updates the device state of the virtual device as needed based on the execution result. For example, when the execution result indicates that the operation was successful or failed, the first processor updates the status information of the virtual device accordingly; when the execution result contains read data, the first processor caches the data in the read buffer of the virtual device for the application to read. By updating the virtual device state, the state of the virtual device is kept synchronized with the actual state of the remote hardware resource.

[0045] In this embodiment, the first processor responds to the access event of the virtual device by sending an access request to the second processor via a preset unified protocol and receiving the execution result returned by the second processor, thus completing cross-processor communication. Through this method, this embodiment uses the virtual device as the access entry point, allowing applications to initiate access to remote hardware resources without needing to know the actual processor location of the hardware resources. Simultaneously, the preset unified protocol carries access requests for different types of hardware resources, enabling different types of hardware resources to be accessed through the same protocol. The virtual device and the unified protocol work together to allow applications to access different types of hardware resources in a consistent manner, avoiding the communication fragmentation problem caused by developing separate communication protocols and running service processes for each type of hardware resource, and reducing the cross-processor communication complexity of the vehicle gateway. Furthermore, the preset unified protocol supports the second processor proactively sending resource status notifications to the first processor, allowing the first processor to promptly learn about changes in the status of hardware resources on the second processor side without frequent polling, reducing cross-processor communication overhead and improving the system's response efficiency to changes in hardware resource status.

[0046] In one feasible implementation, the cross-processor communication method further includes steps A1-A2: Step A1: Obtain resource information of at least one hardware resource managed by the second processor; It should be noted that hardware resources refer to various physical devices managed by the second processor, including but not limited to CAN controller, UART serial port controller, GPIO controller, ADC controller, RS485 controller, etc. The second processor is responsible for the real-time control and management of these hardware resources.

[0047] It's important to understand that resource information is data used to describe the attributes of hardware resources, including resource type, resource number, resource capability information, and current resource status. For example, for a CAN controller, its resource information includes resource type as CAN, resource number as 1, support for CAN 2.0B and CAN FD protocols, and current status as online; for a UART serial port controller, its resource information includes resource type as UART, resource number as 1, support for a maximum baud rate of 115200, and current status as online. After obtaining the above resource information, the first processor can use it to create virtual devices corresponding to each hardware resource in the operating system.

[0048] Understandably, a unified resource object model is constructed by uniformly describing the resource type, resource number, resource capability information, and current status of each hardware resource as resource information. Through this unified resource object model, different types of hardware resources (such as CAN controllers, UART serial port controllers, GPIO controllers, etc.) can be identified and managed by the first processor with a consistent data structure, thereby achieving a unified abstraction of heterogeneous hardware resources.

[0049] For example, the acquisition method may be that the first processor sends a resource discovery request to the second processor, and the second processor responds to the request by returning the hardware resource information currently managed; or the second processor may actively report the hardware resource information it manages to the first processor.

[0050] In one feasible implementation, step A1: obtaining resource information of at least one hardware resource managed by the second processor includes steps A11-A12: Step A11: Send a resource discovery request to the second processor, the resource discovery request being used to instruct the second processor to return the resource information; It should be noted that a resource discovery request is a control message sent by the first processor to the second processor to obtain hardware resource information. Its purpose is to trigger the second processor to report the resource information of the hardware resources it currently manages. The first processor can send a resource discovery request to the second processor during system startup or at a specified time. For example, the first processor may send a resource discovery request after power-on initialization to obtain the status of the hardware resources currently managed by the second processor; or it may send a resource discovery request during system operation according to a preset strategy or external triggering conditions to update resource information.

[0051] For example, the first processor sends a resource discovery request to the second processor via a communication link. This communication link includes, but is not limited to, high-speed communication interfaces such as Ethernet, PCIe, USB, and shared memory; preferably, the communication link is Ethernet. The resource discovery request is a data frame conforming to a preset unified protocol, and its command type field indicates a resource query command, enabling the second processor to recognize and respond to the request.

[0052] Step A12: Receive the resource information returned by the second processor in response to the resource discovery request.

[0053] It should be noted that the first processor receives resource information returned by the second processor. This resource information includes the resource type, resource number, resource capability information, and current status of each hardware resource. After receiving the resource information, the first processor saves it locally and establishes a resource information database. The resource type, resource number, resource capability information, and current status of each hardware resource are stored and managed using a unified data structure for subsequent lookup and matching during virtual device creation and resource access.

[0054] For example, after the system boots up, the first processor sends a resource discovery request to the second processor via Ethernet. Upon receiving the request, the second processor queries the currently managed hardware resources and returns the resource information to the first processor. The first processor receives and saves this resource information, confirming that the second processor currently manages hardware resources such as CAN1, CAN2, UART1, and GPIO, providing a basis for subsequently creating corresponding virtual devices.

[0055] In this embodiment, the first processor sends a resource discovery request to the second processor. The second processor responds to this request by returning resource information of the hardware resources it currently manages. This allows the first processor to dynamically obtain the hardware resource status of the second processor without needing to pre-configure or statically specify the type and quantity of hardware resources in the second processor during the system design phase. When the hardware resources managed by the second processor change, such as adding a CAN controller or removing a UART serial port controller, the first processor does not need to modify its software configuration. It only needs to resend the resource discovery request to obtain the updated resource information and automatically complete resource registration. This improves the system scalability and adaptability to different hardware configurations of the vehicle gateway's cross-processor communication.

[0056] Step A2: Based on the resource information, create virtual devices corresponding to each of the hardware resources.

[0057] It should be noted that, based on the acquired resource information, the first processor creates corresponding virtual devices for each hardware resource in the operating system. The resource mapping module of the first processor determines the virtual device type corresponding to each hardware resource based on the resource type and resource number in the resource information returned by the second processor, and establishes a mapping relationship between the hardware resource and the virtual device. For example, the CAN controller in the resource information is mapped to a SocketCAN type virtual device, the UART serial port controller is mapped to a TTY (Teletypewriter) device type virtual device, and the GPIO controller is mapped to a gpiochip type virtual device. The resource mapping module records the above mapping relationship in a mapping table so that when the application accesses the virtual device, the data forwarding module can quickly determine the corresponding target hardware resource based on the mapping table. A virtual device is a software entity in the operating system; each virtual device corresponds to a hardware resource and serves as the local entry point for the application to access remote hardware resources.

[0058] For example, the first processor determines the virtual device type corresponding to each hardware resource based on the resource type in the resource information, and assigns a corresponding device access interface to each virtual device. After the virtual device is created, it appears as a standard device in the operating system of the first processor. Applications can access the virtual device through the standard device access interface of the operating system without needing to know the actual processor location of the hardware resource.

[0059] In this embodiment, the first processor obtains resource information of the hardware resources managed by the second processor, and creates a corresponding virtual device in the local operating system based on this resource information, enabling the remote hardware resources to obtain a corresponding local access entry on the first processor side. The virtual device appears as a standard device in the first processor's operating system, and the application can access the virtual device through the operating system's standard device access interface without needing to know the actual processor location of the hardware resources. This achieves transparent access to remote hardware resources, reduces the complexity of cross-processor communication, and avoids strong coupling between the application and the underlying hardware resources.

[0060] In one feasible implementation, the first processor is equipped with a Linux system, and the virtual device includes a virtual device interface conforming to the Linux device model framework, and the access event is generated by accessing the virtual device interface.

[0061] It's important to note that the Linux Device Model (LDM) is the fundamental architecture within the Linux kernel used to uniformly manage all hardware devices, drivers, and buses in the system. Officially introduced in the Linux 2.6 kernel, LDM aims to provide a unified common interface and data model for device subsystems of different bus types (such as PCI (Peripheral Component Interconnect), USB, and platform buses). Within the LDM framework, all hardware devices are described and registered using a unified data structure, and a hierarchical view of the devices is exported to user space through the sysfs (system filesystem) virtual file system.

[0062] Additionally, it should be noted that the virtual device interface refers to the access point exposed by a virtual device to applications within the operating system. In the implementation where the first processor runs on a Linux system, the first processor, based on the resource information of the hardware resources managed by the second processor, creates corresponding virtual devices for each hardware resource within the LDM framework. Each virtual device is registered as a standard device object in the LDM framework and exposes an access point to applications through its corresponding virtual device interface. Applications trigger access events by accessing this virtual device interface (such as performing read, write, or control operations).

[0063] Understandably, since virtual devices in Linux systems follow the LDM standard framework, applications can access the virtual device in accordance with the standard device access methods of the Linux system (such as through device files, network interfaces, or sysfs property files), without needing to know the actual processor location of the hardware resource, thereby achieving transparent access to remote hardware resources.

[0064] In this embodiment, a virtual device conforming to the LDM framework is created in the Linux system by the first processor, enabling remote hardware resources to obtain standard local device access on the first processor side. Since LDM is the standard framework of the Linux kernel, the virtual device is registered as a standard device object under the LDM framework. Applications can access the virtual device according to the standard device access method of the Linux system without needing to know the actual processor location of the hardware resource or call special interfaces for specific hardware resources. This achieves transparent access to remote hardware resources and reduces the complexity of cross-processor communication.

[0065] In one feasible implementation, the device types under the Linux device model framework include at least one of SocketCAN devices, TTY devices, and gpiochip (General Purpose Input / Output chip) devices; It should be noted that SocketCAN is the official implementation of the CAN protocol family in the Linux kernel, which abstracts CAN devices as network interfaces, and applications access them through the Socket API; TTY devices are the standard device type in the Linux terminal / serial port subsystem, with a corresponding device file under / dev / , and applications access them through the standard file operation interface; gpiochip is the standard device type used to represent GPIO controllers in the Linux kernel GPIO subsystem, with a corresponding gpiochip device file under / dev / , and applications access it through the ioctl system call.

[0066] Step A2: Based on the resource information, creating virtual devices corresponding to each of the hardware resources further includes steps A21 to A23: In one embodiment, the first processor registers and creates each virtual device according to the standard framework of the SocketCAN, TTY subsystem and GPIO subsystem, so that each virtual device presents itself as a standard device in its respective subsystem.

[0067] In another embodiment, the first processor implements a unified virtual device driver framework that handles communication with the second processor in a unified manner and adapts to different types of hardware resources as SocketCAN interface, TTY device file or gpiochip device file form respectively, so that applications can still access them through their respective standard interfaces.

[0068] Step A21: For the resource information corresponding to each of the hardware resources, when the resource type of the resource information is CAN controller, automatically create a SocketCAN device as the virtual device; Optionally, the first processor automatically creates a virtual device of type SocketCAN in the Linux system based on the CAN controller information in the resource information. This virtual device is presented as a network interface (such as can0) in the system. Applications can access this interface through the standard Socket API without being aware that the underlying hardware resources are actually located in the second processor.

[0069] Step A22: When the resource type of the resource information is a UART serial port controller, automatically create a TTY device as the virtual device; Optionally, the first processor automatically creates a virtual device of type TTY device in the Linux system based on the UART serial port controller information in the resource information. This virtual device is presented as a TTY device file (such as / dev / ttyMCU0) in the system. The application can access the device file through the standard file operation interface without being aware that the underlying hardware resources are actually located in the second processor.

[0070] Step A23: When the resource type of the resource information is GPIO controller, automatically create a gpiochip device as the virtual device.

[0071] Optionally, the first processor automatically creates a virtual device of type gpiochip in the Linux system based on the GPIO controller information in the resource information. This virtual device is presented as a gpiochip device file (such as / dev / gpiochip0) in the system. Applications can access this device file through the ioctl system call without needing to know that the underlying hardware resources are actually located on the second processor.

[0072] For example, consider a second processor managing CAN1, UART1, and GPIO1. After system startup, the first processor obtains the resource information through resource discovery and creates the can0 network interface (corresponding to CAN1), the / dev / ttyMCU0 device file (corresponding to UART1), and the / dev / gpiochip0 device file (corresponding to GPIO1). Subsequently, when the application reads CAN data via the candump command, the first processor encapsulates the read operation into an access request conforming to a preset unified protocol and sends it to the second processor. The second processor parses the request, controls the CAN1 controller to perform the read, and returns the read CAN data frame to the first processor, ultimately presenting it to the application. Throughout this process, the application only operates on can0 through the standard SocketCAN interface, completely unaware that the data actually comes from the remote second processor. The access to UART and GPIO is similar. In this way, the virtual device, in conjunction with the unified protocol, allows the application to access remote hardware resources as if they were local devices, without needing to be aware of the actual processor location of the hardware resources, thus achieving transparent access to remote hardware resources.

[0073] In this embodiment, standard virtual devices of corresponding types are created in the Linux system according to different types of hardware resources, so that different types of remote hardware resources can be presented on the first processor side in their respective standard device forms. Since these virtual devices are all standard device types under their respective subsystems, applications can reuse existing standard tools and interfaces in the Linux system to access them, without the need to develop special access tools for different hardware resources, further reducing the difficulty of application development for cross-processor communication.

[0074] The second embodiment of this application also provides a cross-processor communication method, referring to... Figure 2 , Figure 2 This is a flowchart illustrating the cross-processor communication method applied to a second processor according to this application.

[0075] In this embodiment, the cross-processor communication method is applied to the second processor of the vehicle gateway, and the vehicle gateway further includes a first processor. The cross-processor communication method includes steps B1 to B3: Step B1: Receive an access request sent by the first processor. The access request is obtained by encapsulating the access event of the virtual device of the first processor through a preset unified protocol. The virtual device of the first processor is created based on the hardware resources corresponding to the second processor. It should be noted that the virtual device on the first processor side is created based on the hardware resources managed by the second processor. The creation process is described in steps A1 to A2 of the first embodiment above, and will not be repeated here. When the application accesses the virtual device on the first processor side, the first processor encapsulates the access event into an access request through a preset unified protocol and sends it to the second processor. The access request is used to instruct the second processor to perform operations on the corresponding hardware resources.

[0076] Additionally, it should be noted that the second processor receives access requests sent by the first processor via a communication link, which includes, but is not limited to, Ethernet, PCIe, USB, shared memory, etc., preferably Ethernet. The access request is a data frame encapsulated using a preset unified protocol and sent by the first processor in response to an application's access event to a virtual device, instructing the second processor to perform operations on the corresponding hardware resources.

[0077] Step B2: Based on the access request, determine the target hardware in the hardware resources, and control the target hardware to execute the request operation contained in the access request, and generate the execution result; It should be noted that after receiving the access request, the second processor parses the access request to determine the target hardware resource and the operation to be executed. Based on the parsing result, it determines the target hardware from the currently managed hardware resources, controls the target hardware to execute the corresponding operation, and generates the execution result.

[0078] Step B3: Return the execution result to the first processor.

[0079] It should be noted that the second processor returns the execution result to the first processor via the communication link, completing this cross-processor communication. The execution result includes indications of success or failure, as well as the data returned by the operation.

[0080] In this embodiment, the second processor receives an access request sent by the first processor through a preset unified protocol, parses the access request to determine the target hardware and the operation to be performed, controls the target hardware to execute the corresponding operation, and returns the execution result. This enables the second processor to respond to cross-processor access requests initiated by the first processor and complete operations on hardware resources, thus realizing a complete closed loop of cross-processor communication. Through this method, the second processor does not need to be aware of the application logic on the first processor side; it only needs to parse the access request according to the preset unified protocol and execute the corresponding operation, achieving clear decoupling of functions between processors.

[0081] In one feasible implementation, the cross-processor communication method of the second embodiment further includes steps C1-C2: Step C1: In response to the resource discovery request sent by the first processor, query the currently managed hardware resources to obtain resource information; It should be noted that after receiving the resource discovery request sent by the first processor via the communication link, the second processor responds to the request by querying the currently managed hardware resources and obtaining the resource information of each hardware resource. The resource information includes resource type, resource number, resource capability information, and current resource status. The resource type indicates the type of hardware resource, including but not limited to CAN controllers, UART serial port controllers, GPIO controllers, ADC controllers, RS485 controllers, etc.; the resource number uniquely identifies the resource within the same type, such as CAN1, CAN2; the resource capability information describes the supported capability parameters of the hardware resource, such as the baud rate range, operating mode, and filter configuration capabilities supported by the CAN controller, and the baud rate range, data bit length, stop bit length, and parity method supported by the UART serial port controller; the current resource status indicates the current operating status of the hardware resource, including online, offline, busy, idle, and abnormal. For example, for the CAN1 controller managed by the second processor, its resource information includes: resource type is CAN controller, resource number is 1, resource capability information is support for CAN 2.0B and CAN FD protocols, support for a maximum baud rate of 1Mbps, support for extended frames and standard frames, support for hardware filtering, and the current status of the resource is online.

[0082] For example, after receiving the resource discovery request sent by the first processor, the second processor traverses the list of currently managed hardware resources, and sequentially obtains the resource type, resource number, resource capability and current status of each hardware resource, and summarizes the obtained information into resource information.

[0083] Step C2: Send the resource information to the first processor so that the first processor can create virtual devices corresponding to each of the hardware resources.

[0084] It should be noted that the second processor sends the resource information to the first processor via the communication link. After receiving the resource information, the first processor creates virtual devices corresponding to each hardware resource in the operating system based on the resource information of each hardware resource. For example, the first processor creates a corresponding SocketCAN virtual device based on the resource information of the CAN1 controller, a corresponding TTY virtual device based on the resource information of the UART1 serial port controller, and a corresponding gpiochip virtual device based on the resource information of the GPIO1 controller. The process of creating virtual devices is described in step A2 of the first embodiment above, and will not be repeated here.

[0085] In this embodiment, in response to a resource discovery request sent by the first processor, the second processor sends resource information of all currently managed hardware resources to the first processor. This enables the first processor to dynamically obtain the hardware resource status of the second processor and create corresponding virtual devices accordingly. When the second processor adds or removes hardware resources, the first processor can obtain updated resource information by resending the resource discovery request, thus improving the system scalability and flexibility of cross-processor communication in the vehicle gateway.

[0086] In one feasible implementation, the pre-defined unified protocol includes at least a resource identifier field and a command type field; It should be noted that the resource identifier field is a field in the data frame of the pre-defined unified protocol used to indicate the target hardware resource to be accessed. Its value (i.e., the identifier value) corresponds to the hardware resource managed by the second processor; for example, "CAN1" corresponds to the first CAN controller, and "UART1" corresponds to the first UART serial port controller. The command type field is a field in the data frame of the pre-defined unified protocol used to indicate the type of operation to be performed. Its value (i.e., the command value) includes, but is not limited to, reading data, sending data, and configuring parameters. Through the combination of the resource identifier field and the command type field, the access request can accurately express the two core pieces of information: "which hardware resource to access" and "what operation to perform."

[0087] Step B2: Based on the access request, determine the target hardware among the hardware resources, and control the target hardware to execute the request operation contained in the access request, generating the execution result, including steps B21~B23: Step B21: Parse the access request to obtain the identifier value corresponding to the resource identifier field and the command value corresponding to the command type field; It should be noted that after receiving the access request, the second processor parses the access request according to the data frame format of the preset unified protocol. It reads the value of the resource identifier field from the corresponding field position in the data frame as the identifier value, and reads the value of the command type field as the command value. The identifier value uniquely indicates the target hardware resource to be accessed; for example, "CAN1" indicates the first CAN controller. The command value indicates the type of operation to be performed; for example, "read data" indicates reading data from the target hardware.

[0088] Step B22: Query the hardware that matches the identifier value from the hardware resources to obtain the target hardware; It should be noted that the target hardware refers to the hardware resource that the second processor determines from the currently managed hardware resources that matches the identifier value; that is, the hardware resource that this access request actually intends to operate on. The second processor uses the identifier value as a query condition to search through the currently managed hardware resources and determines the hardware resource that matches the identifier value as the target hardware. For example, when the identifier value is "CAN1", the second processor queries the currently managed hardware resources and finds the CAN1 controller as the target hardware; when the identifier value is "UART1", it queries and finds the UART1 serial port controller as the target hardware.

[0089] Step B23: Control the target hardware to perform the operation corresponding to the command value, and obtain the execution result.

[0090] It should be noted that the second processor determines the type of operation to be executed based on the command value, calls the corresponding driver program of the target hardware to control the target hardware to execute the corresponding operation, and obtains the operation result. For example, when the command value is "read data", the second processor calls the target hardware's read interface to perform a data read operation; when the command value is "send data", it calls the target hardware's send interface to perform a data send operation; when the command value is "configure parameters", it calls the target hardware's configuration interface to perform a parameter configuration operation. After the target hardware completes the corresponding operation, the second processor records the operation result as the execution result, which includes indication information of success or failure of the operation and the data returned by the operation.

[0091] For example, assume that the second processor currently manages hardware resources such as CAN1, CAN2, UART1, and GPIO. The access request sent by the first processor has an identifier value of "CAN1" and a command value of "read data". After receiving the access request, the second processor parses it according to the data frame format of the preset unified protocol, reads the identifier value "CAN1" from the resource identifier field, reads the command value "read data" from the command type field, then matches the CAN1 controller as the target hardware from the currently managed hardware resources using "CAN1" as the query condition, and then controls the CAN1 controller to perform a data reading operation according to the command value "read data", reads the data frame on the CAN bus, and generates an execution result containing the read CAN data.

[0092] In this embodiment, the second processor obtains the identifier value and command value by parsing the access request, determines the target hardware from the currently managed hardware resources based on the identifier value, and controls the target hardware to perform the corresponding operation based on the command value. This achieves accurate response to the access request and ensures the correctness and reliability of hardware resource calls in cross-processor communication.

[0093] This application also provides an in-vehicle gateway; please refer to... Figure 3 The vehicle gateway includes: The first processor 10 is configured to respond to an access event of a virtual device, encapsulate the access event into an access request through a preset unified protocol and send it to the second processor, so that the second processor can generate a corresponding execution result. The virtual device is created based on the hardware resources corresponding to the second processor. The processor 10 also receives the execution result of the access request from the second processor. It should be noted that the first processor is the application-side processor in the vehicle gateway, used to run the operating system, applications, and handle complex business logic, and is responsible for high-computing-power, non-real-time tasks. Logically, the first processor includes a resource management module, used to achieve unified management of hardware resources and protocol conversion for cross-processor communication.

[0094] The resource management module includes a resource discovery module, a resource mapping module, and a data forwarding module. The resource discovery module acquires resource information of the hardware resources managed by the second processor, including sending a resource discovery request to the second processor and receiving resource information returned by the second processor. This resource information includes the resource type, resource number, resource capability information, and current status of each hardware resource. The resource mapping module creates virtual devices corresponding to each hardware resource in the operating system of the first processor based on the resource information acquired by the resource discovery module, and sets corresponding device access interfaces for each virtual device. The data forwarding module responds to application access events to virtual devices by encapsulating the access events into access requests conforming to a preset unified protocol, sending them to the second processor via a communication link, receiving the execution results returned by the second processor, and feeding the execution results back to the application. The data forwarding module also associates the execution results with the corresponding virtual devices according to a mapping table after receiving the execution results returned by the second processor, updates the virtual device status, and feeds the execution results back to the application.

[0095] The second processor 20 is configured to receive an access request sent by the first processor, wherein the access request is obtained by encapsulating the access event of the virtual device of the first processor through a preset unified protocol, and the virtual device of the first processor is created based on the hardware resources corresponding to the second processor; according to the access request, determine the target hardware in the hardware resources, and control the target hardware to execute the request operation contained in the access request, generate an execution result; and return the execution result to the first processor.

[0096] The second processor is the real-time side processor in the vehicle gateway, used for real-time control, rapid response to external events, and management of various hardware resources. Logically, the second processor includes a resource proxy layer, which runs on the second processor's RTOS system and is used to parse resource requests from the first processor side and invoke underlying hardware resources.

[0097] The resource proxy layer comprises a protocol parsing module, a resource management module, and a driver invocation module. The protocol parsing module receives access requests from the first processor, parses them according to a preset unified protocol data frame format, and obtains the identifier value corresponding to the resource identifier field and the command value corresponding to the command type field. The protocol parsing module also parses the data length field and data payload field in the access request to obtain the length and content of the data to be sent or received, providing complete data parameters for the driver invocation module to perform data read / write operations. For example, when the command type field of the access request indicates "send data," the protocol parsing module reads the data content to be sent from the data payload field and the data length from the data length field. The driver invocation module then controls the target hardware to perform the data sending operation based on these parameters. The resource management module maintains the status information of each hardware resource, including resource initialization, parameter configuration, status maintenance, and permission management. Based on the identifier value obtained by the protocol parsing module, it queries the currently managed hardware for matching target hardware. The driver invocation module, based on the command value obtained by the protocol parsing module, invokes the driver program corresponding to the target hardware, controls the target hardware to perform the corresponding operation, generates the execution result, and returns the execution result to the first processor via the communication link.

[0098] Based on the above module configuration, this embodiment forms a complete data access link: the application accesses the virtual device through the standard device access interface of the first processor's operating system; the data forwarding module of the first processor encapsulates the access event into an access request conforming to a preset unified protocol and sends it to the second processor through the communication link; the protocol parsing module of the second processor parses the access request; the resource management module determines the target hardware; the driver invocation module invokes the driver program corresponding to the target hardware to perform the operation and returns the execution result to the first processor through the communication link, which then feeds back to the application. In this data access link, the application only needs to interact with the virtual device through the standard device access interface, without needing to be aware of the mapping relationship between the virtual device and remote hardware resources, nor needing to be aware of the protocol encapsulation and transmission details of data in the cross-processor communication process, thus achieving decoupling between the application layer and the underlying communication mechanism.

[0099] Specifically, refer to Figure 4The first processor (Linux application processor) logically includes an application layer and a virtual device layer. The application layer runs the vehicle gateway business program, including Linux CAN tools, Python / ROS applications, and customer-customized applications. Applications access virtual devices through the first processor's operating system standard device access interface. The resource management module includes a resource discovery module, a resource mapping module, and a data forwarding module. The resource discovery module obtains resource information of the hardware resources managed by the second processor, including sending resource discovery requests to the second processor and receiving resource information returned by the second processor. This resource information includes the resource type, resource number, resource capability information, and current status of each hardware resource. The resource mapping module creates virtual devices corresponding to each hardware resource in the first processor's operating system based on the resource information obtained by the resource discovery module, and sets corresponding device access interfaces for each virtual device. The data forwarding module responds to application access events to virtual devices by encapsulating the access events into access requests conforming to a preset unified protocol, sending them to the second processor via a communication link, receiving the execution results returned by the second processor, and feeding the execution results back to the application. The virtual device layer includes virtual devices created in the operating system of the first processor, corresponding to the hardware resources managed by the second processor. A virtual device is a software entity created by the first processor in its operating system based on the hardware resources managed by the second processor, used to map remote hardware resources to local standard devices. In one embodiment, the first processor runs a Linux system, and the virtual devices are created using interfaces conforming to the Linux device model framework, including SocketCAN devices, TTY devices, gpiochip devices, etc. The first processor is responsible for creating and maintaining the virtual devices, which include device status, operation interfaces, and their correspondence with hardware resources. It is understood that the virtual devices appear as standard devices in the first processor's operating system, and applications do not need to be aware of the actual processor location of the hardware resources to access the virtual devices as if they were local devices, thereby achieving transparent access to remote hardware resources. The second processor (MCU real-time processor) logically includes a resource proxy layer and a microcontroller resource layer. The resource proxy layer runs in the second processor's RTOS system and is used to parse resource requests from the first processor side and invoke underlying hardware resources. The resource proxy layer includes a protocol parsing module, a resource management module, and a driver invocation module. The protocol parsing module is used to receive access requests sent by the first processor, parse them according to the data frame format of the preset unified protocol, obtain the identifier value corresponding to the resource identifier field and the command value corresponding to the command type field, and also parse the data length field and data payload field in the access request to obtain the data length and data content to be sent or received, providing complete data parameters for the driver calling module to perform data read and write operations.The resource management module maintains the status information of each hardware resource, including resource initialization, parameter configuration, status maintenance, and permission management. Based on the identifier value obtained by the protocol parsing module, it queries the currently managed hardware resources for matching target hardware. The driver invocation module invokes the corresponding driver program for the target hardware based on the command value obtained by the protocol parsing module, controls the target hardware to perform corresponding operations, generates execution results, and returns the execution results to the first processor via the communication link. The microcontroller resource layer contains various hardware resources managed by the second processor. Hardware resources refer to various physical devices managed by the second processor, including but not limited to CAN controllers, UART serial port controllers, GPIO controllers, ADC controllers, RS485 controllers, etc. The second processor is responsible for the real-time control and management of these hardware resources. In one embodiment, the second processor is an MCU real-time processor, and the microcontroller resource layer is the MCU's on-chip peripheral resources, including CAN controllers, UART serial port controllers, GPIO controllers, etc. The second processor receives and parses the access requests sent by the first processor through the resource proxy layer, determines the target hardware resource and the operation to be executed based on the access request, controls the corresponding hardware resource to perform the operation and generates the execution result, and then returns the execution result to the first processor.

[0100] In the vehicle gateway provided in this embodiment, the first processor is configured with a resource management module, and the second processor is configured with a resource proxy layer. The two work together to complete cross-processor communication. The first processor sends a resource discovery request to the second processor through the resource discovery module in the resource management module to obtain resource information of the hardware resources currently managed by the second processor. This eliminates the need to pre-configure or statically specify the type and quantity of hardware resources for the second processor during the system design phase, enabling the system to dynamically adapt to different hardware configurations. Based on the obtained resource information, the resource mapping module creates virtual devices corresponding to each hardware resource in the operating system, allowing remote hardware resources to obtain corresponding local access entries on the first processor side. The data forwarding module responds to application access events to virtual devices by sending access requests to the second processor through a preset unified protocol. The resource proxy layer of the second processor parses the access request through the protocol parsing module. The resource management module determines the target hardware, and the driver invocation module controls the target hardware to execute corresponding operations and returns the execution results, thereby completing cross-processor communication. Through the cooperation of the above modules, the application can access different types of hardware resources in a consistent manner without needing to know the actual processor location of the hardware resources. This avoids the fragmented communication problems caused by developing separate communication protocols and running service processes for each type of hardware resource, and reduces the cross-processor communication complexity of the vehicle gateway. Furthermore, when the hardware resources managed by the second processor change, the first processor only needs to resend the resource discovery request through the resource discovery module to obtain the updated resource information, without modifying the software configuration, thus improving the system's scalability and flexibility.

[0101] This application provides an electronic device, which includes: 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 the cross-processor communication method in Embodiment 1 above.

[0102] The following is for reference. Figure 5 The diagram illustrates a structural schematic of an electronic device suitable for implementing embodiments of this application. The electronic devices in these embodiments may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0103] like Figure 5 As shown, the electronic device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the electronic device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. The communication device 1009 allows the electronic device to communicate wirelessly or wiredly with other devices to exchange data. Although the diagrams show electronic devices with various systems, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems may be implemented alternatively.

[0104] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0105] The electronic device provided in this application, employing the cross-processor communication method described in the above embodiments, can solve the technical problem of high complexity in cross-processor communication of vehicle gateways caused by the independent access protocols and logic of various hardware resources and the need for different access methods for different hardware resources. Compared with the prior art, the beneficial effects of the electronic device provided in this application are the same as those of the cross-processor communication method provided in the above embodiments, and other technical features of this electronic device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0106] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0107] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0108] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the cross-processor communication method in the above embodiments.

[0109] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0110] The aforementioned computer-readable storage medium may be included in an electronic device or may exist independently without being assembled into an electronic device.

[0111] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0112] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0113] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0114] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described cross-processor communication method. This solves the technical problem that the access protocols and access logic of various hardware resources are independent, requiring different access methods for different hardware resources, leading to high complexity in cross-processor communication of the vehicle gateway. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the cross-processor communication method provided in the above embodiments, and will not be repeated here.

[0115] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the cross-processor communication method described above.

[0116] The computer program product provided in this application can solve the technical problem that the access protocols and access logic of various hardware resources are independent, and different hardware resources need to adopt different access methods, resulting in high complexity of cross-processor communication in vehicle gateways. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the cross-processor communication method provided in the above embodiments, and will not be repeated here.

[0117] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A cross-processor communication method, characterized in that, A first processor is applied to an in-vehicle gateway, the in-vehicle gateway further comprising a second processor, the cross-processor communication method comprising: In response to an access event of a virtual device, the access event is encapsulated into an access request and sent to the second processor through a preset unified protocol, so that the second processor can generate a corresponding execution result. The virtual device is created based on the hardware resources corresponding to the second processor. Receive the execution result of the access request from the second processor.

2. The cross-processor communication method as described in claim 1, characterized in that, The cross-processor communication method further includes: Obtain resource information of at least one hardware resource managed by the second processor; Based on the resource information described, create virtual devices corresponding to each of the hardware resources.

3. The cross-processor communication method as described in claim 2, characterized in that, The step of obtaining resource information of at least one hardware resource managed by the second processor includes: Send a resource discovery request to the second processor, the resource discovery request being used to instruct the second processor to return the resource information; Receive the resource information returned by the second processor in response to the resource discovery request.

4. The cross-processor communication method as described in claim 2, characterized in that, The first processor is equipped with a Linux system, and the virtual device includes a virtual device interface that conforms to the Linux device model framework. The access event is generated by accessing the virtual device interface.

5. The cross-processor communication method as described in claim 4, characterized in that, The device types under the Linux device model framework include at least one of SocketCAN devices, TTY devices, and gpiochip devices; The step of creating a virtual device corresponding to each of the hardware resources based on the resource information includes: For each of the aforementioned hardware resources, when the resource type of the resource information is a CAN controller, a SocketCAN device is automatically created as the virtual device. When the resource type of the resource information is a UART serial port controller, a TTY device is automatically created as the virtual device; When the resource type of the resource information is GPIO controller, a gpiochip device is automatically created as the virtual device.

6. A cross-processor communication method, characterized in that, A second processor is applied to an in-vehicle gateway, the in-vehicle gateway further comprising a first processor, the cross-processor communication method comprising: The system receives an access request sent by the first processor. The access request is obtained by encapsulating the access event of the virtual device of the first processor through a preset unified protocol. The virtual device of the first processor is created based on the hardware resources corresponding to the second processor. Based on the access request, the target hardware in the hardware resources is determined, and the target hardware is controlled to execute the request operation contained in the access request, and an execution result is generated; The execution result is returned to the first processor.

7. The cross-processor communication method as described in claim 6, characterized in that, The cross-processor communication method further includes: In response to the resource discovery request sent by the first processor, the currently managed hardware resources are queried to obtain resource information; The resource information is sent to the first processor so that the first processor can create virtual devices corresponding to each of the hardware resources.

8. The cross-processor communication method as described in claim 6, characterized in that, The preset unified protocol includes at least a resource identifier field and a command type field; The steps of determining the target hardware in the hardware resources based on the access request, controlling the target hardware to execute the request operation contained in the access request, and generating the execution result include: Parse the access request to obtain the identifier value corresponding to the resource identifier field and the command value corresponding to the command type field; The target hardware is obtained by querying the hardware resources that match the identifier value. The target hardware is controlled to perform the operation corresponding to the command value, and the execution result is obtained.

9. A vehicle-mounted gateway, characterized in that, The vehicle gateway includes a first processor and a second processor, and the vehicle gateway includes: The first processor is configured to respond to access events of a virtual device, encapsulate the access event into an access request using a preset unified protocol, and send it to the second processor so that the second processor can generate a corresponding execution result. The virtual device is created based on the hardware resources corresponding to the second processor. The processor also receives the execution result of the access request from the second processor. The second processor is configured to receive an access request sent by the first processor, wherein the access request is obtained by encapsulating the access event of the virtual device of the first processor through a preset unified protocol, and the virtual device of the first processor is created based on the hardware resources corresponding to the second processor; according to the access request, the second processor determines the target hardware in the hardware resources, controls the target hardware to execute the request operation contained in the access request, generates an execution result, and returns the execution result to the first processor.

10. An electronic device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the cross-processor communication method as described in any one of claims 1 to 8.

Images