CN113950033A

CN113950033A - Data transmission method and device

Info

Publication number: CN113950033A
Application number: CN202010690693.7A
Authority: CN
Inventors: 张岩锋
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2020-07-17
Filing date: 2020-07-17
Publication date: 2022-01-18
Anticipated expiration: 2040-07-17
Also published as: CN113950033B

Abstract

The present application relates to the field of near field communication technologies, and in particular, to a data transmission method and device. The data transmission method is applied to a scene that a first device and a second device establish USB communication connection and switch to an accessory mode, and comprises the following steps: the method comprises the steps that a first device distributes a queue identification for data to be sent in an application program layer; the first equipment puts the data to be sent carrying the queue identification into a shared write memory; a write thread in the first device acquires data to be sent carrying a queue identifier from the shared write memory, and encapsulates the data to be sent and the queue identifier carried by the data to be sent into a message packet to be sent; and the writing thread sends the message packet to be sent to a kernel file node so as to send the message packet to be sent to second equipment through the kernel file node. Based on this application embodiment, can realize under the accessory mode that the multichannel data transmission between tall and erect equipment of ann and the USB accessory.

Description

Data transmission method and device

Technical Field

The present application relates to the field of near field communication technologies, and in particular, to a data transmission method and device.

Background

The android system is used as an intelligent operating system based on open source Linux, and is widely applied to devices such as mobile phones and tablet computers. Among the various interfaces provided by android devices, the Universal Serial Bus (USB) interface is a common interface. The android device can support various USB peripheral devices through a USB interface, such as a mouse, a keyboard, a printer and the like. In an Android Open Access (AOA) protocol, according to a role of an Android device in USB communication, the USB communication of the Android device can be divided into a Host Mode (Host Mode) and an Accessory Mode (access Mode).

In host mode, the android device acts as a USB host and powers USB peripheral devices connected to its bus. But some android devices on the market do not have the hardware required by the USB host, and android devices typically have limited power and are difficult to continuously power USB peripheral devices. Therefore, although the host mode expands the connection capability of the android device, the host mode is difficult to be applied to application program development.

In accessory mode, the android device acts as a USB slave, and the USB peripheral device to which the android device is connected acts as a host and powers the bus. In accessory mode, the USB peripheral becomes an android accessory. This mode provides the ability for android devices without host functionality to interact with USB devices.

In the accessory mode, data transmission can be carried out between the android device and the USB accessory based on the AOA protocol. However, in the data transmission process based on the AOA protocol, there is only one channel, i.e. AOA channel. Based on the channel, data transmission of multiple channels cannot be supported between the android device and the USB accessory.

Disclosure of Invention

The application provides a data transmission method and device, which can realize multi-channel data transmission between an android device and a USB accessory in an accessory mode.

In a first aspect, the present technical solution provides a data transmission method. The method is applied to a scene that the first device and the second device establish USB communication connection and switch to an accessory mode. When the method is executed, the first device can be an android device, and the second device is a USB accessory; optionally, the first device may also be a USB accessory, and the second device is an android device. Specifically, the method comprises the following steps:

the first device allocates a queue identifier for data to be sent in the application layer. And the first equipment puts the data to be sent carrying the queue identification into a shared write memory. And the data to be sent in the shared write memory can be read by a write thread in the first device. And the write thread acquires the data to be sent carrying the queue identification from the shared memory and encapsulates the data to be sent and the queue identification carried by the data to be sent into a message packet to be sent. And then, the writing thread sends the message packet to be sent to the kernel file node so as to send the message packet to be sent to the second device through the kernel file node.

In this embodiment of the application, when the first device and the second device transmit data in the accessory mode, a queue identifier may be allocated to data to be transmitted in the application layer. When the queue identifier allocated to the data to be transmitted is multiple, it can be considered that multiple data transmission channels correspond to the queue identifier. In order to distinguish the data to be sent of each application, the data to be sent carries the alignment identifier. Further, the first device puts the data to be sent carrying the queue identifier into the shared write memory. And sending the data to be sent in the shared write memory to the kernel file node through the write thread, namely sending the data to be sent in the shared write memory to the second device through the AOA channel. Therefore, in the scheme of the embodiment of the application, multiplexing of multiple channels is realized by allocating the queue identifier to the data to be sent and putting the data to be sent carrying the queue identifier into the shared write memory.

With reference to the first aspect, in certain implementations of the first aspect, the first device supports not only multi-channel transmission of application layer data, but also multi-channel reception of data. Specifically, the first device creates a receive queue and a receive thread, and assigns a queue identifier to the created receive queue. Optionally, the queue identifier of the receive queue is a queue identifier of a message sent by the second device application layer. It should be noted that, in the accessory mode, the manner of sending data by the second device is the same as the manner of sending data by the first device, and a message packet sent by the second device also carries a corresponding queue identifier, for example, Channel ID 01. Then the queue identification of the receive queue created by the first device for receiving the message packet is also Channel ID 01. The message data packet sent by the second device is firstly put into the kernel file node through the AOA channel. And the read thread of the first device receives the message data packet sent by the second device from the kernel file node. And the read thread analyzes the acquired message data packet and puts the received data carrying the queue identification into a shared read memory according to the analysis result. And the receiving thread puts the received data into a corresponding receiving queue from the shared read memory according to the queue identification carried by the received data. Further, the receive thread provides corresponding receive data from the receive queue to an application at the application layer, thereby enabling receipt of application layer data.

In the embodiment of the application, data to be sent of an application layer is placed in a shared write memory, received data is placed in a shared read memory, and based on the mode, bidirectional multichannel data transmission can be achieved between a first device and a second device in an accessory mode, for example, the first device sends map data and voice data to the second device; the second device transmits the position data, the image data, and the like to the first device.

With reference to the first aspect, in some implementations of the first aspect, the creating, by the first device, a receive queue includes: the first device creates a receive queue for at least one application in the application layer that is to receive data, wherein queue identifications of the receive queues of different applications are different. In the embodiment of the application, when one or more applications in the application program layer need to receive a message, a receiving queue may be created for each application that is to receive data, where queue identifications of receiving queues of different applications are different. Based on this, the first device can realize the receiving of the multi-application data through a plurality of receiving channels.

With reference to the first aspect, in some implementations of the first aspect, the creating, by the first device, a receive queue includes: the first device creates at least one receiving queue for the same application, and queue identifications of the receiving queues corresponding to the same application are different. In this manner, data for the same application may be received over multiple data channels.

With reference to the first aspect, in certain implementations of the first aspect, the method further includes: the first device allocates a queue identity to the receive queue according to a queue identity allocation scheme. Wherein, the queue identification allocation scheme may be pre-stored in the first device and the second device. Optionally, the first device negotiates to determine the queue identifier allocation scheme during the process of interactively switching to the accessory mode with the second device.

In this embodiment of the application, the first device and the second device may determine a queue identifier allocation scheme in an interaction process of switching to the accessory mode, and the first device and the second device may determine, according to the queue identifier allocation scheme, a queue identifier available for each application. Based on this, when creating the receive queue, the first device may determine the queue identifier of the created receive queue according to the acquired queue identifiers of the applications.

With reference to the first aspect, in some implementations of the first aspect, the allocating, by the first device, a queue identifier for data to be sent in an application layer includes: the first device allocates a queue identifier for data to be sent of at least one application in the application program layer, wherein the queue identifiers of the data to be sent of different applications are different.

With reference to the first aspect, in some implementations of the first aspect, the allocating, by the first device, a queue identification for data to be sent of at least one application in the application layer includes: the first device allocates a plurality of queue identifications to the same application according to the data type of the data to be sent. Optionally, the first device allocates a queue identifier for the data to be sent according to the queue identifier allocation scheme.

With reference to the first aspect, in certain implementations of the first aspect, the method further includes: the first equipment sets priority for the queue identification of the data to be sent; correspondingly, the write thread in the first device determines the sequence of sending the data to be sent in the shared write memory to the kernel file node according to the priority of the queue identifier of the data to be sent;

the first equipment sets priority for the receiving queue; correspondingly, the reading thread in the first device determines the sequence of putting the message data packets into the shared read memory according to the priority of the receiving queue, and/or the receiving thread determines the sequence of putting the received data into the corresponding receiving queue according to the priority of the receiving queue, and/or the receiving thread determines the sequence of providing the received data in the receiving queue to the application program layer according to the priority of the receiving queue.

In a second aspect, the present technical solution provides an electronic device, including:

a display screen; one or more processors; a memory; and one or more computer programs, wherein the one or more computer programs are stored in the memory, the one or more computer programs comprising instructions which, when executed by the device, cause the device to perform the following steps in a scenario in which a USB communication connection is established with a second device and switched to accessory mode: distributing a queue identifier for data to be sent in an application program layer; putting data to be sent carrying a queue identification into a shared write memory; the write thread acquires data to be sent carrying queue identification from the shared write memory, and encapsulates the data to be sent and the queue identification carried by the data to be sent into a message packet to be sent; and the writing thread sends the message packet to be sent to a kernel file node so as to send the message packet to be sent to second equipment through the kernel file node.

With reference to the second aspect, in certain implementations of the second aspect, the instructions, when executed by the apparatus, cause the apparatus to further perform the steps of: creating a receiving queue and a receiving thread, and distributing a queue identification for the receiving queue; a read thread receives a message data packet sent by second equipment from a kernel file node, wherein a queue identifier is encapsulated in the message data packet; the reading thread analyzes the message data packet and puts the received data carrying the queue identification into a shared reading memory according to the analysis result; the receiving thread puts the received data into a corresponding receiving queue according to the queue identification carried by the received data; the receive thread further provides receive data from the receive queue to an application at an application layer.

With reference to the second aspect, in certain implementations of the second aspect, the instructions, when executed by the apparatus, cause the apparatus to perform the steps of: a receive queue is created for at least one application in the application layer that is to receive data, wherein queue identifications of receive queues of different applications are different.

With reference to the second aspect, in certain implementations of the second aspect, the instructions, when executed by the apparatus, cause the apparatus to perform the steps of: and allocating a queue identifier for data to be sent of at least one application in the application program layer, wherein the queue identifiers of the data to be sent of different applications are different.

With reference to the second aspect, in certain implementations of the second aspect, the instructions, when executed by the apparatus, cause the apparatus to perform the steps of: and distributing a plurality of queue identifications for the same application according to the data type of the data to be sent.

With reference to the second aspect, in certain implementations of the second aspect, the instructions, when executed by the apparatus, cause the apparatus to perform the steps of: and allocating a queue identifier for the data to be transmitted according to the queue identifier allocation scheme and/or allocating a queue identifier for the receiving queue according to the queue identifier allocation scheme.

With reference to the second aspect, in certain implementations of the second aspect, the instructions, when executed by the apparatus, cause the apparatus to perform the steps of:

setting priority for a queue identification of data to be sent; correspondingly, the write thread determines the sequence of sending the data to be sent in the shared write memory to the kernel file node according to the priority of the queue identifier of the data to be sent;

setting a priority for a receive queue; correspondingly, the reading thread determines the sequence of putting the message data packets into the shared read memory according to the priority of the receiving queue, and/or the receiving thread determines the sequence of putting the received data into the corresponding receiving queue according to the priority of the receiving queue, and/or the receiving thread determines the sequence of providing the received data in the receiving queue to the application program layer according to the priority of the receiving queue.

In a third aspect, the present technical solution provides an electronic device, where the device includes a storage medium and a central processing unit, where the storage medium may be a non-volatile storage medium, and a computer-executable program is stored in the storage medium, and the central processing unit is connected to the non-volatile storage medium and executes the computer-executable program to implement the method in any possible implementation manner of the first aspect.

In a fourth aspect, the present technical solution provides a chip, where the chip includes a processor and a data interface, and the processor reads an instruction stored in a memory through the data interface to execute the method in any possible implementation manner of the first aspect.

Optionally, as an implementation manner, the chip may further include a memory, the memory stores instructions, and the processor is configured to execute the instructions stored on the memory, and when the instructions are executed, the processor is configured to execute the method in any possible implementation manner of the first aspect.

In a fifth aspect, the present technical solution provides a computer-readable storage medium storing program code for execution by a device, the program code including instructions for performing the method of any one of the possible implementations of the first aspect.

Drawings

Fig. 1 is a schematic structural diagram of an electronic device provided in an embodiment of the present application;

fig. 2 is a software structure diagram of an electronic device according to an embodiment of the present application;

fig. 3 is a flowchart illustrating switching of a mobile phone and a car-in-device to an AOA accessory mode according to an embodiment of the present disclosure;

FIG. 4 is a flowchart illustrating the execution of a read thread and a write thread in an embodiment of the present application;

FIG. 5 is a schematic diagram of an interface of a multi-channel management service in an embodiment of the present application;

FIG. 6 is a flowchart of an embodiment of the present application in which an android device sends data to an android accessory;

FIG. 7 is a flowchart of an embodiment of the present application in which an android device receives data sent by an android accessory;

fig. 8 is another schematic structural diagram of an electronic device in the embodiment of the present application.

Detailed Description

The technical solution in the present application will be described below with reference to the accompanying drawings.

The embodiment of the application provides a data transmission method. The method expands the data transmission scheme on the basis of the AOA protocol. The method supports multi-channel multiplexing on the application program level, and realizes bidirectional multi-channel data transmission between the android device and the android accessory. Specifically, the method sets a shared write memory, and when a first device needs to send data to a second device, the first device allocates a queue identifier for the data to be sent. The first device puts data to be sent carrying the queue identification into a shared write memory, and the write thread writes the data to be sent in the shared write memory into a kernel file node so as to send the data to be sent to the second device through an AOA channel. Therefore, the multiplexing of multiple data channels can be realized in the application layer by allocating the queue identifier to the data to be sent in the embodiment of the application.

Further, the first device creates a receive queue and a receive thread when receiving data, and assigns a queue identification to the receive queue. The message data packet sent by the second device is firstly transmitted to the kernel file node of the first device through the AOA channel. A read thread in the first device obtains a message packet from a kernel file node. And the read thread puts the message data packet acquired from the kernel file node into the shared read memory. And the receiving thread puts the data in the shared read memory into a corresponding receiving queue according to the queue identification of the message data packet and provides the received data in the receiving queue for the application of the application program layer. Therefore, the embodiment of the application can realize the receiving of the multi-queue data by creating the receiving queue and distributing the queue identification for the receiving queue.

Similarly, the way in which the second device sends data to the first device refers to the way in which the first device sends data; the way in which the second device receives the data sent by the first device is referred to as the way in which the first device receives the data. Therefore, in the embodiment of the application, bidirectional multichannel transmission of data can be performed between the first device and the second device. Namely, the data transmission mode is further expanded on the basis of the AOA protocol, and the multi-channel multiplexing of an application program layer is realized on the basis of transmitting data based on the AOA channel.

The first device can be an android device, and the second device is an android accessory; optionally, the first device may be an android accessory, and the second device is an android device.

In one example, the first device is an android device, which may be an electronic device such as a cell phone, a tablet, a television, a wearable device, a smart home device, an Augmented Reality (AR)/Virtual Reality (VR) device, and so on. The embodiment of the present application does not set any limit to the specific type of the electronic device.

For example, fig. 1 shows a schematic structural diagram of an electronic device 100 provided in an embodiment of the present application. As shown in fig. 1, the electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a Universal Serial Bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, a Subscriber Identity Module (SIM) card interface 195, and the like. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, and the like.

It is to be understood that the illustrated structure of the embodiment of the present invention does not specifically limit the electronic device 100. In other embodiments of the present application, electronic device 100 may include more or fewer components than shown, or some components may be combined, some components may be split, or a different arrangement of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

Processor 110 may include one or more processing units, such as: the processor 110 may include an Application Processor (AP), a modem processor, a Graphics Processing Unit (GPU), an Image Signal Processor (ISP), a controller, a video codec, a Digital Signal Processor (DSP), a baseband processor, and/or a neural-Network Processing Unit (NPU), etc. The different processing units may be separate devices or may be integrated into one or more processors.

The controller can generate an operation control signal according to the instruction operation code and the timing signal to complete the control of instruction fetching and instruction execution.

A memory may also be provided in processor 110 for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may hold instructions or data that have just been used or recycled by the processor 110. If the processor 110 needs to reuse the instruction or data, it can be called directly from the memory. Avoiding repeated accesses reduces the latency of the processor 110, thereby increasing the efficiency of the system.

In some embodiments, processor 110 may include one or more interfaces. The interface may include an integrated circuit (I2C) interface, an integrated circuit built-in audio (I2S) interface, a Pulse Code Modulation (PCM) interface, a universal asynchronous receiver/transmitter (UART) interface, a Mobile Industry Processor Interface (MIPI), a general-purpose input/output (GPIO) interface, a Subscriber Identity Module (SIM) interface, and/or a Universal Serial Bus (USB) interface, etc.

The USB interface 130 is an interface conforming to the USB standard specification, and may specifically be a Mini USB interface, a Micro USB interface, a USB Type C interface, or the like. The USB interface 130 may be used to connect a charger to charge the electronic device 100, and may also be used to transmit data between the electronic device 100 and a peripheral device. And the earphone can also be used for connecting an earphone and playing audio through the earphone. The interface may also be used to connect other electronic devices, such as AR devices, in-vehicle devices, etc.

It should be understood that the connection relationship between the modules according to the embodiment of the present invention is only illustrative, and is not limited to the structure of the electronic device 100. In other embodiments of the present application, the electronic device 100 may also adopt different interface connection manners or a combination of multiple interface connection manners in the above embodiments.

The wireless communication module 160 may provide a solution for wireless communication applied to the electronic device 100, including Wireless Local Area Networks (WLANs) (e.g., wireless fidelity (Wi-Fi) networks), bluetooth (bluetooth, BT), Global Navigation Satellite System (GNSS), Frequency Modulation (FM), Near Field Communication (NFC), Infrared (IR), and the like. The wireless communication module 160 may be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, performs frequency modulation and filtering processing on electromagnetic wave signals, and transmits the processed signals to the processor 110. The wireless communication module 160 may also receive a signal to be transmitted from the processor 110, perform frequency modulation and amplification on the signal, and convert the signal into electromagnetic waves through the antenna 2 to radiate the electromagnetic waves.

The electronic device 100 implements display functions via the GPU, the display screen 194, and the application processor. The GPU is a microprocessor for image processing, and is connected to the display screen 194 and an application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 may include one or more GPUs that execute program instructions to generate or alter display information.

The display screen 194 is used to display images, video, and the like. The display screen 194 includes a display panel. The display panel may adopt a Liquid Crystal Display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (active-matrix organic light-emitting diode, AMOLED), a flexible light-emitting diode (FLED), a miniature, a Micro-oeld, a quantum dot light-emitting diode (QLED), and the like. In some embodiments, the electronic device 100 may include 1 or N display screens 194, with N being a positive integer greater than 1.

The electronic device 100 may implement a shooting function through the ISP, the camera 193, the video codec, the GPU, the display 194, the application processor, and the like.

The ISP is used to process the data fed back by the camera 193. For example, when a photo is taken, the shutter is opened, light is transmitted to the camera photosensitive element through the lens, the optical signal is converted into an electrical signal, and the camera photosensitive element transmits the electrical signal to the ISP for processing and converting into an image visible to naked eyes. The ISP can also carry out algorithm optimization on the noise, brightness and skin color of the image. The ISP can also optimize parameters such as exposure, color temperature and the like of a shooting scene. In some embodiments, the ISP may be provided in camera 193.

The camera 193 is used to capture still images or video. The object generates an optical image through the lens and projects the optical image to the photosensitive element. The photosensitive element may be a Charge Coupled Device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The light sensing element converts the optical signal into an electrical signal, which is then passed to the ISP where it is converted into a digital image signal. And the ISP outputs the digital image signal to the DSP for processing. The DSP converts the digital image signal into image signal in standard RGB, YUV and other formats. In some embodiments, the electronic device 100 may include 1 or N cameras 193, N being a positive integer greater than 1.

The digital signal processor is used for processing digital signals, and can process digital image signals and other digital signals. For example, when the electronic device 100 selects a frequency bin, the digital signal processor is used to perform fourier transform or the like on the frequency bin energy.

Video codecs are used to compress or decompress digital video. The electronic device 100 may support one or more video codecs. In this way, the electronic device 100 may play or record video in a variety of encoding formats, such as: moving Picture Experts Group (MPEG) 1, MPEG2, MPEG3, MPEG4, and the like.

The NPU is a neural-network (NN) computing processor that processes input information quickly by using a biological neural network structure, for example, by using a transfer mode between neurons of a human brain, and can also learn by itself continuously. Applications such as intelligent recognition of the electronic device 100 can be realized through the NPU, for example: image recognition, face recognition, speech recognition, text understanding, and the like.

The external memory interface 120 may be used to connect an external memory card, such as a Micro SD card, to extend the memory capability of the electronic device 100. The external memory card communicates with the processor 110 through the external memory interface 120 to implement a data storage function. For example, files such as music, video, etc. are saved in an external memory card.

The internal memory 121 may be used to store computer-executable program code, which includes instructions. The internal memory 121 may include a program storage area and a data storage area. The storage program area may store an operating system, an application program (such as a sound playing function, an image playing function, etc.) required by at least one function, and the like. The storage data area may store data (such as audio data, phone book, etc.) created during use of the electronic device 100, and the like. In addition, the internal memory 121 may include a high-speed random access memory, and may further include a nonvolatile memory, such as at least one magnetic disk storage device, a flash memory device, a universal flash memory (UFS), and the like. The processor 110 executes various functional applications of the electronic device 100 and data processing by executing instructions stored in the internal memory 121 and/or instructions stored in a memory provided in the processor.

The electronic device 100 may implement audio functions via the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, the headphone interface 170D, and the application processor. Such as music playing, recording, etc.

In one example, the second device is an android accessory, which may be an electronic device such as an in-vehicle device, a robot, a wearable device, a smart home device, an AR/VR device, and so on. The embodiment of the present application does not set any limit to the specific type of the electronic device. Illustratively, the second device may include a processor, a memory, a communication processing module, an input module, an output module, and the like. These components may be connected by a bus. Wherein the processor is operable to read and execute the computer readable instructions. In a specific implementation, the processor may mainly include a controller, an operator, and a register. The controller is mainly responsible for instruction decoding and sending out control signals for operations corresponding to the instructions. The arithmetic unit is mainly responsible for executing fixed-point or floating-point arithmetic operation, shift operation, logic operation and the like, and can also execute address operation and conversion. The register is mainly responsible for storing register operands, intermediate operation results and the like temporarily stored in the instruction execution process. In a Specific implementation, the hardware architecture of the processor may be an Application Specific Integrated Circuits (ASIC) architecture, an MIPS architecture, an ARM architecture, or an NP architecture, etc.

The memory is coupled to the processor for storing various software programs and/or sets of instructions. In particular implementations, the memory may include high speed random access memory and may also include non-volatile memory, such as one or more magnetic disk storage devices, flash memory devices, or other non-volatile solid state storage devices. The memory may store an operating system, such as an embedded operating system like windows, Android, etc. The memory may also store a communication program that may be used to communicate with the first device, one or more servers, or additional devices.

The communication processing module may include one or more of a bluetooth communication processing module, a WLAN communication processing module, and a USB communication module. For example, in the embodiment of the present application, the second device performs data transmission with the first device through the USB communication module.

In the embodiment of the present application, the software systems of the first device and the second device may adopt a layered architecture, an event-driven architecture, a micro-core architecture, a micro-service architecture, or a cloud architecture. The embodiment of the application takes an Android system with a layered architecture as an example, and exemplarily illustrates software structures of a first device and a second device. Fig. 2 is a block diagram of a software structure of an electronic device according to an embodiment of the present disclosure. The layered architecture divides the software into several layers, each layer having a clear role and division of labor. The layers communicate with each other through a software interface. In some embodiments, the Android system is divided into four layers, an application layer, an application framework layer, an Android runtime (Android runtime) and system library, and a kernel layer from top to bottom.

The application layer may include a series of application packages. As shown in fig. 2, the application package may include: applications such as telephony, maps, navigation, WLAN, bluetooth, music, video, etc.

The application framework layer provides an Application Programming Interface (API) and a programming framework for the application program of the application layer. The application framework layer includes a number of predefined functions. As shown in fig. 2, the application framework layer may include a multi-channel management service configured to implement the data transmission method according to the embodiment of the present application. Through the multi-channel management service, when the application program layer needs to send data, a queue identifier can be distributed for the data to be sent, and the data to be sent carrying the queue identifier is placed in the shared write memory. The multi-channel management service can also create a receiving queue and a receiving thread when the application program layer needs to receive data, allocate a queue identifier to the receiving queue, and provide the received data carrying the queue identifier from the shared read memory to the corresponding application of the application program layer.

Further, the application framework layer may include a window manager, content provider, view system, phone manager, resource manager, notification manager, and the like.

The window manager is used for managing window programs. The window manager can obtain the size of the display screen, judge whether a status bar exists, lock the screen, intercept the screen and the like.

The content provider is used to store and retrieve data and make it accessible to applications. The data may include video, images, audio, calls made and received, browsing history and bookmarks, phone books, etc. For example, data to be transmitted and data received by the multi-channel management service may be accessed by the content provider provisioning application.

The view system includes visual controls such as controls to display text, controls to display pictures, and the like. The view system may be used to build applications. The display interface may be composed of one or more views. For example, a view showing text and a view showing pictures may be included.

The phone manager is used to provide communication functions of the electronic device. Such as management of call status (including on, off, etc.). The resource manager provides various resources for the application, such as localized strings, icons, pictures, layout files, video files, and the like.

The Android Runtime comprises a core library and a virtual machine. The Android runtime is responsible for scheduling and managing an Android system.

The core library comprises two parts: one part is a function which needs to be called by java language, and the other part is a core library of android.

The application layer and the application framework layer run in a virtual machine. And executing java files of the application program layer and the application program framework layer into a binary file by the virtual machine. The virtual machine is used for performing the functions of object life cycle management, stack management, thread management, safety and exception management, garbage collection and the like.

The system library may include a plurality of functional modules. For example: surface managers (surface managers), Media Libraries (Media Libraries), three-dimensional graphics processing Libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), and the like.

The kernel layer is a layer between hardware and software. The kernel layer at least comprises a display driver, a camera driver, an audio driver, a sensor driver, a USB driver and the like. In the embodiment of the application, the electronic device can realize the USB data transmission function through the USB driver. Further, the AOA protocol in this embodiment may be included in a kernel layer, and the AOA protocol may include the kernel file node in this embodiment.

The data transmission method according to the embodiment of the present application will be described below with reference to the electronic device described above. In one example, the first device is a mobile phone, and the second device is a car machine device. Both the mobile phone and the vehicle machine equipment support the AOA protocol. Before executing the data transmission method in the embodiment of the present application, the mobile phone and the in-vehicle device first establish a USB communication connection and switch to the AOA accessory mode.

Fig. 3 is a flowchart of switching a mobile phone and a car machine device to an AOA accessory mode according to an embodiment of the present application. Based on this flow, the handset and in-vehicle device can switch to AOA accessory mode, as shown in fig. 3. The mobile phone is called an android device, and the car machine device is called an android accessory. After the android device and the car machine device establish the USB communication connection, as shown in fig. 3, the method includes:

101, the android accessory initiates device enumeration to the android device.

102, the android device sends device description information to the android accessory, wherein the device description information returned by the android device comprises information such as a device descriptor and a configuration descriptor. At this time, the android device reports to the usb disk or the MTP device.

103, the android accessory initiates a first control transmission command to the android device. Wherein the first control transmission command can be used to query the android device whether the android device supports the AOA protocol. In particular implementations, the android ACCESSORY can initiate a command number 51 (ACCESSORY _ GET _ PROTOCOL) to the android device based on the AOA PROTOCOL. In the AOA protocol, the instruction 51 is a command for inquiring whether the android device supports the AOA protocol.

And 104, if the android device supports the AOA protocol, sending the version number of the AOA protocol supported by the android device to the android accessory.

105, after the android accessory determines that the connected device is the android device and supports the AOA protocol, the android accessory sends authentication information to the android device and sends an instruction for starting communication. Specifically, the android ACCESSORY can initiate a command number 52 (access _ SEND _ training) to the android device based on the AOA protocol, accompanied by some authentication information. The authentication information may include information such as manufacturer name, model name, description, version, etc. After receiving the authentication information, the android device can determine an application program corresponding to the accessory; if the android device does not have the application program matched with the authentication information, a dialog box can be popped up to prompt the user to download the corresponding application program.

106, if the android accessory is an audio device, the android accessory also initiates a command to the android device to open audio support. Specifically, the android accessory can send a 58 # command (SET _ AUDIO _ MODE) to the android device based on the AOA protocol to start the AUDIO function.

107, the android accessory sends a request to the android device to open the accessory mode. Specifically, the android ACCESSORY can send a 53 # command (access _ START) to the android device based on the AOA protocol, informing the android device to switch to the ACCESSORY mode.

And 108, after the android device receives the request for starting the accessory mode, switching the USB communication mode of the android device to the AOA mode. Specifically, after receiving a request for opening the accessory mode, the android device automatically resets the USB bus. After the USB bus is reset, the android accessory initiates device enumeration to the android device again. The android device sends new device information to the android accessory, and the information is USB information in the accessory mode. And then the android accessory and the android device interact data in the AOA accessory mode.

After the android device and the android accessory are switched to the AOA accessory mode, the android device and the android accessory can perform data transmission on the hardware level based on the AOA channel. Specifically, the android device and the android accessory can transmit data based on the kernel file node. The kernel file node is a public channel for communication between the android device and the android accessory, and the multiple channels are multiplexed based on the channel to perform data transmission. In order to transmit large-data-volume multi-channel data between the android device and the android accessory, the embodiment of the application utilizes a cross-process shared memory technology to effectively solve the problem of low performance of cross-process message queue communication. As shown in fig. 4, in the embodiment of the present application, two shared memories, namely a shared write memory and a shared read memory, are created. The shared write memory is mainly used for writing data to the kernel file node, and the shared read content is mainly used for reading data from the kernel file node. In the embodiment of the application, the reading process and the writing process are separated, and data can be transmitted between the android device and the android accessory more efficiently.

As shown in fig. 4, after the android device and the android accessory successfully start the AOA accessory mode, both start the read thread and the write thread of the AOA. The processing flow of the read thread comprises the following steps: a read thread acquires a message data packet from a kernel node; analyzing the message data packet to obtain received data and a queue identification; and putting the received data carrying the queue identification into a shared read memory so that the upper layer application can obtain the received data from the shared read memory.

As shown in fig. 4, the processing flow of the write thread includes: the write thread acquires data to be sent from the shared write memory, packages the data to be sent and the queue identifier, and sends a message packet to be sent to the kernel file node, so that the message packet to be sent is sent to the receiving device (for example, to the second device) through the kernel file node.

The read thread and the write thread shown in fig. 4 may be understood as a process of transferring data between the application framework layer and the kernel layer. Its ultimate goal is to provide a multi-channel application interface to the upper application layer. Therefore, in the embodiment of the present application, a multi-channel management service is set at the application framework layer. The multi-channel management service may provide a multi-channel application interface to the application layer. The method specifically comprises the following steps: creating, deleting and inquiring an interface of the queue; and interfaces to send messages, receive messages, etc.

As shown in fig. 5, when at least one application in the application program layer needs to send data, a sending queue may be created through a create queue interface in the multi-channel management service, and it is understood that creating a sending queue based on a create queue interface may be creating a real data queue. In this embodiment of the present application, creating the sending queue may also be allocating a queue identifier to data to be sent. And a plurality of sending queues are formed among the data carrying different queue identifications. The step of creating the queue is not really performed inside the system. When at least one application in the application program layer needs to receive data, a receiving queue and a receiving thread can be created through a queue creating interface in the multi-channel management service, and the receiving queue is configured to be a receiving queue distribution queue identification according to the queue identification. When the service sending and the service receiving are finished, the corresponding queue can be deleted through the queue deleting interface so as to release the queue resource. Further, the queue information which is already created can be queried through a query queue interface.

Before sending a message based on a message sending interface, a queue identifier is firstly distributed to data to be sent by creating a queue interface. Namely, the queue identifier is distributed to the data to be sent of the application program layer. And then, the data to be sent carrying the queue identification can be further put into the shared write memory through a message sending interface. And then, sending the data to be sent in the shared write memory to the kernel file node through the write thread shown in fig. 4. During the process of putting the data to be sent of the application program layer into the shared write memory, an independent thread does not need to be created, and a message sending interface can be directly called when the data needs to be sent.

For a received message, before receiving the message based on the received message interface, a receive queue is first created by creating a queue interface and a queue identification is assigned to the receive queue. For a receive message service, a read thread shown in fig. 4 may be used to cyclically receive message packets from a kernel file node and place the message packets into a shared read memory. In an application layer, the multichannel management service needs to create an independent receiving thread for a current receiving service, so as to send receiving data carrying a queue identifier in a shared read memory to a corresponding application through the receiving thread.

Based on the settings of fig. 4 and 5, after the android device and the android accessory are switched to the accessory mode, bidirectional multi-channel data transmission can be realized between the android device and the android accessory. During data transmission, the following methods can be used according to the data flow direction: the method comprises the steps that the android device sends data to the android accessory, the android device receives the data sent by the android accessory, the android accessory sends data to the android device, and the android accessory receives the data sent by the android device. The flow of sending data to the android accessory by the android device is the same as the flow of sending data to the android device by the android accessory, and in the embodiment of the application, the flow of sending data to the android accessory by the android device is only taken as an example for explanation. Similarly, the flow of the android device receiving the data sent by the android accessory is the same as the flow of the android accessory receiving the data sent by the android device, and in the embodiment of the application, the description is given only by taking the flow of the android device receiving the data sent by the android accessory as an example.

As shown in fig. 6, the processing flow of sending data to the android accessory by the android device includes:

and 201, allocating a queue identification to data to be sent. And the android device allocates a queue identifier for the data to be sent in the application program layer.

When at least one application in the application program layer of the android device needs to send data to the android accessory, the multichannel management service in the application framework layer can be called. And the multichannel management service calls a queue interface and distributes queue identification for the data to be sent according to a queue identification distribution scheme in the queue identification configuration. The multichannel management service can respectively create sending queues for each application needing to send data. The queue identifications of the data to be sent of different applications are different. Further, when the multichannel management service allocates a queue identifier to data to be sent of one of the applications, the multichannel management service may allocate at least one queue identifier to the application. For example, in an actual scene, when a mobile phone needs to project a navigation interface to a car device, a navigation application in the mobile phone needs to send navigation interface data and navigation audio data to the car device. At this time, the navigation application can pull up the multichannel management service, and the multichannel management service allocates queue identifiers for the navigation interface data and the navigation audio data to be sent by the navigation application. The multichannel management service can allocate a queue identifier to data to be sent in the navigation application. Optionally, the multichannel management service may also allocate a plurality of queue identifiers to the data to be sent according to the data type. For example, the multichannel management service may allocate a queue identifier (e.g., Channel ID 01) to navigation interface data, allocate a queue identifier (Channel ID 02) to navigation audio data, and form different data channels in the transmission process for data carrying different queue identifiers.

Specifically, the multichannel management service may allocate a queue identifier to each transmission queue according to the already-obtained queue identifier allocation scheme. The queue identification allocation scheme can be obtained in the process of android accessory interaction to switch to an accessory mode. Queue identifications available to the respective applications may be included in the queue identification allocation scheme. The queue identification allocation scheme may be stored as a queue identification configuration file.

202, the android device puts the data to be sent carrying the queue identification into the shared write memory.

In order to realize multichannel data multiplexing based on the AOA protocol, the multichannel management service puts data to be sent carrying queue identification into a shared write memory. For example, in a scenario where the navigation application needs to send the navigation interface data and the navigation audio data to the car-mounted device, the navigation interface data carrying Channel ID 01 and the navigation audio data carrying Channel ID 02 may be put into the shared write memory. The data stored in the shared write memory carries respective queue identifiers. The shared write memory can be used for storing data to be sent, which carry different queue identifications.

And 203, encapsulating the data to be sent and the queue identification carried by the data to be sent by the write thread. And a write thread in the android device acquires the data to be sent carrying the queue identification from the shared write memory, and encapsulates the data to be sent and the queue identification carried by the data to be sent into a message packet to be sent.

In the embodiment of the application, after the android device is switched to the AOA accessory mode, a write thread in the system is started. After the write thread detects data to be sent in the shared write memory, the write thread acquires the data to be sent with the queue identifier from the shared write memory, and encapsulates the data to be sent and the queue identifier carried by the data to be sent into a message packet to be sent.

And 204, the write thread sends the message packet to be sent to the kernel file node, so that the message packet to be sent is sent to an android accessory through the kernel file node.

In the embodiment of the application, the distribution scheme of the queue identification can be shared between the android device and the android accessory. For example, an android device and an android accessory can assign an available queue identification to each application during an interaction process that switches to an accessory mode. Based on this, when the android device creates the sending queue, the queue identifier is allocated to the created sending queue according to the allocation scheme of the queue identifier. The android accessory serves as a receiving party, and when data sent by the android device are received, queue identification can be distributed for the receiving queue according to a queue identification distribution scheme. If the queue identifier carried in the data sent by the android device is 0A, the queue identifier of the receiving queue created by the android accessory and used for receiving the data may also be 0A, or another identifier having a mapping relationship with 0A.

As shown in fig. 7, the processing flow of the android device receiving the data sent by the android accessory includes:

205, the android device creates a receive queue and a receive thread, and assigns a queue identification to the created receive queue.

When at least one application in an application program layer of the android device needs to receive data, the application creates a receiving queue and a receiving thread through a multi-channel management service. For example, after the navigation application of the android device sends navigation interface data and navigation audio data to the android accessory, the navigation application needs to receive vehicle position data fed back by the android accessory. At this time, the navigation application can create a receiving queue and a receiving thread through the multi-channel management service, and allocate a queue identifier for the receiving queue.

The multi-channel management service may create a receive queue for at least one application in the application layer, where queue identifications of the receive queues of different applications are different. For the same application, the multi-channel management service can create at least one receiving queue for the same application, and the queue identifications of the receiving queues of the same application are different.

Specifically, the multichannel management service may allocate a queue identifier to each receive queue according to the already-obtained queue identifier allocation scheme. The queue identification allocation scheme can be obtained in the process of android accessory interaction to switch to an accessory mode. Queue identifications available to the respective applications may be included in the queue identification allocation scheme. The queue identification allocation scheme may be stored as a queue identification configuration file.

206, the read thread receives a message data packet sent by the android accessory from the kernel file node, wherein the message data packet is encapsulated with a queue identifier.

In the embodiment of the application, after the android device is switched to the AOA accessory mode, a reading thread in the system is started. And when the read thread detects that the message data packet to be received in the kernel file node, the read thread acquires the message data packet from the kernel file node.

And 207, the reading thread analyzes the message data packet to obtain a queue identifier and received data, and the received data carrying the queue identifier is put into the shared reading memory.

And the reading thread analyzes the message data packet acquired from the kernel file node to obtain the received data and the corresponding queue identification. And the read thread puts the received data carrying the queue identification into a shared read memory.

And 208, the receiving thread provides the received data in the shared read memory to the corresponding application.

And all the message data packets received in the kernel file nodes carry queue identifications. And the read thread analyzes the message data packet acquired from the kernel file node and acquires the queue identification of the message data packet. And the read thread puts the received data carrying the queue identification into the shared read memory according to the queue identification of the message data packet. The receiving thread created by the multi-channel management service can place the received data into a corresponding receiving queue according to a queue identifier carried by the data in the shared read memory, and the receiving thread can further provide the received data in the receiving queue to a corresponding application of an application program layer to achieve data receiving.

In the embodiment of the application, when a certain application needs to receive data, the multichannel management service creates a receiving thread for the data receiving service of the application. The receiving thread monitors the shared read memory, and when receiving data is put into the shared read memory, the receiving thread acquires the receiving data from the shared read memory and puts the receiving data into a corresponding receiving queue.

In the embodiment of the application, the multichannel management service can also set priority for data transmission and reception in the application program layer. Specifically, the multichannel management service sets a priority for a queue identifier of data to be sent. Then, when the write thread sends the data to be sent to the kernel file node, the sequence of sending the data to be sent in the shared write memory to the kernel file node may be determined according to the priority of the queue identifier of the data to be sent.

Further, the multi-channel management service may also set priorities for the created receive queues. Then, when the read thread puts the message data packets of the kernel file node into the shared read memory, the read thread may determine the order of putting the message data packets into the shared read memory according to the priority of the receive queue. In addition, the receiving thread can also determine the sequence of putting the received data in the shared read memory into the receiving queue according to the priority of the receiving queue. Further, the receiving thread can also determine the sequence of providing the received data in the receiving queue to the corresponding application according to the priority of the receiving queue.

The implementation of the application can be applied to a bidirectional audio and video data transmission scene, for example, a scene that the android device sends a navigation map and navigation voice to the car machine device, and the android device plays music and video on the car machine device; the vehicle-mounted device sends audio and video data shot by the automobile camera, automobile driving data and other scenes to the android device.

The data transmission method of the embodiment of the application is expanded on the basis of the existing AOA protocol, and multi-channel data transmission is realized on the basis of not increasing and changing system hardware and not changing top-level services and drivers of the system. And kept simultaneously under the AOA mode, tall and erect the accessory of ann and give tall and erect the advantage that equipment charges for ann. In addition, the scheme has small change to the system, so the modification cost for realizing the scheme is low.

The embodiment of the application adopts a shared memory technology, solves the problem of low transmission performance of large data volume in a multi-channel data transmission scheme, and can effectively support the transmission of multi-channel audio and video data.

The data transmission method of the embodiment of the application is separated from a hardware transmission channel at the bottom layer, namely, the multi-channel technology realized based on the AOA protocol is still applicable to the scheme if the method is based on other transmission media subsequently.

It will be appreciated that the electronic device, in order to implement the above-described functions, comprises corresponding hardware and/or software modules for performing the respective functions. The present application can be implemented in hardware or a combination of hardware and computer software in conjunction with the steps of the various examples described in connection with the embodiments disclosed herein. Whether a function is performed as hardware or computer software drives hardware depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application with the embodiment.

In this embodiment, the electronic device may be divided into functional modules according to the above method example, for example, each functional module may be divided corresponding to each function, or two or more functions may be integrated into one processing module. The integrated module may be implemented in the form of hardware. It should be noted that the division of the modules in this embodiment is schematic, and is only a logic function division, and there may be another division manner in actual implementation.

In the case of dividing each functional module by corresponding functions, fig. 8 shows a schematic structural diagram of the electronic device involved in the above-described embodiment. As shown in fig. 8, the electronic apparatus includes:

a queue creating unit 301, configured to allocate a queue identifier for data to be sent in an application layer;

a message sending unit 302, configured to put data to be sent carrying a queue identifier into a shared write memory; acquiring data to be sent carrying a queue identifier from the shared write memory through a write thread, and packaging the data to be sent and the queue identifier carried by the data to be sent into a message packet to be sent; and sending the message packet to be sent to a kernel file node through a write thread, so that the message packet to be sent is sent to second equipment through the kernel file node.

A queue creating unit 301, configured to create a receiving queue and a receiving thread, and allocate a queue identifier to the receiving queue;

the device further comprises a message receiving unit 303, configured to receive, from the kernel file node through a read thread, a message data packet sent by the second device, where the message data packet is encapsulated with a queue identifier; analyzing the message data packet through a reading thread, and putting the received data carrying the queue identification into a shared reading memory; and putting the received data carrying the queue identification into a corresponding receiving queue through the receiving thread, and providing the corresponding received data for the application of the application program layer from the receiving queue.

The queue creating unit 301, the message sending unit 302, and the message receiving unit 303 in this embodiment may also implement corresponding functions executed by the first device in this embodiment, which is not described herein again.

It should be understood that the electronic device herein is embodied in the form of a functional unit. The term "unit" herein may be implemented in software and/or hardware, and is not particularly limited thereto. For example, a "unit" may be a software program, a hardware circuit, or a combination of both that implement the above-described functions. The hardware circuitry may include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (e.g., a shared processor, a dedicated processor, or a group of processors) and memory that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that support the described functionality.

The present application also provides an electronic device, where the device includes a storage medium and a central processing unit, the storage medium may be a non-volatile storage medium, a computer executable program is stored in the storage medium, and the central processing unit is connected to the non-volatile storage medium and executes the computer executable program to implement the data transmission method shown in fig. 3 to 7.

The present application further provides a chip, where the chip includes a processor and a data interface, and the processor reads instructions stored in a memory through the data interface to execute the data transmission method shown in fig. 3 to 7.

Optionally, as an implementation manner, the chip may further include a memory, where the memory stores instructions, and the processor is configured to execute the instructions stored on the memory, and when the instructions are executed, the processor is configured to execute the data transmission method in each of the above embodiments.

In a sixth aspect, the present technical solution provides a computer-readable storage medium storing program code for device execution, where the program code includes instructions for executing the method in possible implementation manners of the data transmission method.

The memory may be a read-only memory (ROM), other types of static storage devices that may store static information and instructions, a Random Access Memory (RAM), or other types of dynamic storage devices that may store information and instructions, an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compact disc, laser disc, optical disc, digital versatile disc, blu-ray disc, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer, etc.

In the embodiments of the present application, "at least one" means one or more, "a plurality" means two or more. "and/or" describes the association relationship of the associated objects, and means that there may be three relationships, for example, a and/or B, and may mean that a exists alone, a and B exist simultaneously, and B exists alone. Wherein A and B can be singular or plural. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship. "at least one of the following" and similar expressions refer to any combination of these items, including any combination of singular or plural items. For example, at least one of a, b, and c may represent: a, b, c, a-b, a-c, b-c, or a-b-c, wherein a, b, c may be single or multiple.

Those of ordinary skill in the art will appreciate that the various elements and algorithm steps described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or combinations of electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the several embodiments provided in the present application, any function, if implemented in the form of a software functional unit and sold or used as a separate product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application or portions thereof that substantially contribute to the prior art may be embodied in the form of a software product stored in a storage medium and including instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a read-only memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.

The above description is only for the specific embodiments of the present application, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present disclosure, and all the changes or substitutions should be covered by the protection scope of the present application. The protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A data transmission method applied to a scenario in which a first device and a second device establish a USB communication connection and switch to an accessory mode, the method comprising:

the method comprises the steps that a first device distributes a queue identification for data to be sent in an application program layer;

the first equipment puts the data to be sent carrying the queue identification into a shared write memory;

a write thread in the first device acquires data to be sent carrying a queue identifier from the shared write memory, and encapsulates the data to be sent and the queue identifier carried by the data to be sent into a message packet to be sent;

and the writing thread sends the message packet to be sent to a kernel file node so as to send the message packet to be sent to second equipment through the kernel file node.

2. The method of claim 1, further comprising:

the method comprises the steps that a first device creates a receiving queue and a receiving thread and distributes a queue identification to the receiving queue;

a read thread in first equipment receives a message data packet sent by second equipment from a kernel file node, wherein a queue identifier is encapsulated in the message data packet;

the read thread analyzes the message data packet to obtain a queue identification and received data, and the read thread puts the received data carrying the queue identification into a shared read memory;

and the receiving thread puts the received data into a corresponding receiving queue according to the queue identification of the received data and provides the corresponding received data for the application of the application program layer from the receiving queue.

3. The method of claim 2, wherein the first device creating a receive queue comprises:

the first device creates a receive queue for at least one application in the application layer that is to receive data, wherein queue identifications of the receive queues of different applications are different.

4. The method of claim 1, wherein the first device assigns a queue identification for data to be sent in the application layer, comprising:

the first device allocates a queue identifier for data to be sent of at least one application in the application program layer, wherein the queue identifiers of the data to be sent of different applications are different.

5. The method of claim 4, wherein the first device assigns a queue identification for data to be sent for at least one application in the application layer, comprising:

the first device allocates a plurality of queue identifications to the same application according to the data type of the data to be sent.

6. The method of claim 1 or 2, wherein the first device assigns a queue identification, comprising:

the first device allocates a queue identifier for the data to be transmitted according to the queue identifier allocation scheme and/or the first device allocates a queue identifier for the receiving queue according to the queue identifier allocation scheme.

7. The method according to claim 1 or 2, characterized in that the method further comprises: the first equipment sets priority for the queue identification of the data to be sent; correspondingly, the write thread in the first device determines the sequence of sending the data to be sent in the shared write memory to the kernel file node according to the priority of the queue identifier of the data to be sent;

8. An electronic device, comprising:

a display screen; one or more processors; a memory; and one or more computer programs, wherein the one or more computer programs are stored in the memory, the one or more computer programs comprising instructions which, when executed by the device, cause the device to perform the following steps in a scenario in which a USB communication connection is established with a second device and switched to accessory mode:

distributing a queue identifier for data to be sent in an application program layer;

putting data to be sent carrying a queue identification into a shared write memory;

the write thread acquires data to be sent carrying queue identification from the shared write memory, and encapsulates the data to be sent and the queue identification carried by the data to be sent into a message packet to be sent;

9. The apparatus of claim 8, wherein the instructions, when executed by the apparatus, cause the apparatus to further perform the steps of:

creating a receiving queue and a receiving thread, and distributing a queue identification for the receiving queue;

a read thread receives a message data packet sent by second equipment from a kernel file node, wherein a queue identifier is encapsulated in the message data packet;

the reading thread analyzes the message data packet to obtain a queue identification and received data, and the received data carrying the queue identification is placed into a shared reading memory by the receiving thread;

10. The apparatus of claim 9, wherein the instructions, when executed by the apparatus, cause the apparatus to perform the steps of:

a receive queue is created for at least one application in the application layer that is to receive data, wherein queue identifications of receive queues of different applications are different.

11. The apparatus of claim 8, wherein the instructions, when executed by the apparatus, cause the apparatus to perform the steps of:

and allocating a queue identifier for data to be sent of at least one application in the application program layer, wherein the queue identifiers of the data to be sent of different applications are different.

12. The apparatus of claim 11, wherein the instructions, when executed by the apparatus, cause the apparatus to perform the steps of:

and distributing a plurality of queue identifications for the same application according to the data type of the data to be sent.

13. The apparatus of claim 8 or 9, wherein the instructions, when executed by the apparatus, cause the apparatus to perform the steps of:

and allocating a queue identifier for the data to be transmitted according to the queue identifier allocation scheme and/or allocating a queue identifier for the receiving queue according to the queue identifier allocation scheme.

14. The apparatus of claim 8 or 9, wherein the instructions, when executed by the apparatus, cause the apparatus to perform the steps of:

setting a priority for a receive queue; correspondingly, the reading thread determines the sequence of putting the message data packets into the shared read memory according to the priority of the receiving queue, and/or the receiving thread determines the sequence of putting the receiving data into the corresponding receiving queue according to the priority of the receiving queue, and/or the receiving thread determines the sequence of providing the receiving data in the receiving queue to the application program layer according to the priority of the receiving queue.

15. A computer storage medium comprising computer instructions which, when run on an electronic device, cause the electronic device to perform the data transmission method of any one of claims 1 to 7.