CN113950033B

CN113950033B - Data transmission method and equipment

Info

Publication number: CN113950033B
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: 2023-11-28
Anticipated expiration: 2040-07-17
Also published as: CN113950033A

Abstract

The present application relates to the field of near field communication technologies, and in particular, to a data transmission method and apparatus. 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 first device distributes queue identification for data to be transmitted in an application program layer; the first equipment puts the data to be sent carrying the queue identification into a shared write memory; the write thread in the first device acquires data to be transmitted carrying a queue identifier from the shared write memory, and encapsulates the data to be transmitted and the queue identifier carried by the data to be transmitted into a message packet to be transmitted; and the write 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. According to the embodiment of the application, multichannel data transmission between the android device and the USB accessory can be realized in the accessory mode.

Description

Data transmission method and equipment

Technical Field

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

Background

The android system is widely applied to mobile phones, tablet computers and other devices as an intelligent operating system based on open source Linux. Among the various interfaces provided by android devices, the universal serial bus (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 the android open Accessory (Android Open Accessory, AOA) protocol, USB communication of an android device can be classified into two modes, namely a Host Mode and an Accessory Mode (access Mode), according to the role that the android device plays in USB communication.

In host mode, the android device acts as a USB host and powers the USB peripheral devices connected to its bus. Some android devices on the market do not have the hardware required by the USB host, and the android devices generally have limited power to continuously power the USB peripheral devices. Therefore, the host mode, although expanding the connection capability of the android device, is difficult to apply to application 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 device becomes an android accessory. This mode provides the ability for a host-less android device to interact with a USB device.

In the accessory mode, data transmission can be performed between the android device and the USB accessory based on an AOA protocol. But in the data transmission process based on the AOA protocol, only one channel is called AOA channel. Based on the one 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 multichannel data transmission between android equipment and USB accessories in an accessory mode.

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

the first device allocates queue identification for data to be sent in the application layer. And the first equipment puts the data to be sent carrying the queue identification into the shared write memory. The data to be sent in the shared write memory may be read by a write thread in the first device. The write thread acquires the data to be transmitted carrying the queue identifier from the shared memory, and encapsulates the data to be transmitted and the queue identifier carried by the data to be transmitted into a message packet to be transmitted. 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 the embodiment of the application, when the first device and the second device transmit data in the accessory mode, queue identification can be allocated for the data to be transmitted in the application layer. When the queues allocated for the data to be transmitted are identified as a plurality, it can be considered that a plurality of data transmission channels are corresponded. In order to distinguish the data to be transmitted of each application, the data to be transmitted carries a column identification. Further, the first device puts the data to be sent carrying the queue identifier into the shared write memory. And the data to be sent in the shared write memory is sent to the kernel file node through the write thread, namely the data to be sent in the shared write memory is sent 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 distributing the queue identifier for 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 identification for 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 data transmission manner of the second device is the same as that of the first device, and the transmitted message data packet also carries a corresponding queue identifier, for example, a 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 first put into the kernel file node through the AOA channel. 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 identifier into the 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 identifier carried by the received data. Further, the receiving thread provides the corresponding received data from the receiving queue to the application of the application layer, thereby realizing the receiving of the application layer data.

In the embodiment of the application, the data to be transmitted of the application program layer is put into the shared write memory, the received data is put into the shared read memory, and based on the mode, bidirectional multichannel data transmission can be realized between the first equipment and the second equipment in an accessory mode, for example, the first equipment transmits map data and voice data to the second equipment; the second device transmits the position data, the image data, and the like to the first device.

With reference to the first aspect, in certain implementations of the first aspect, the first device creates a receive queue, including: the first device creates a receive queue for at least one application of data to be received in the application layer, 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 the message, a receiving queue can be created for each application to receive the data, wherein the queue identifications of the receiving queues of different applications are different. Based on this, the first device may implement reception of the multi-application data through a plurality of reception channels.

With reference to the first aspect, in certain implementations of the first aspect, the first device creates a receive queue, including: the first device creates at least one receiving queue for the same application, and the queue identifications of the receiving queues corresponding to the same application are different. In this manner, data of the same application may be received through a plurality of data channels.

With reference to the first aspect, in certain implementation manners of the first aspect, the method further includes: the first device allocates a queue identification for the receive queue according to a queue identification allocation scheme. The queue identifier allocation scheme may be stored in the first device and the second device in advance. Optionally, the first device negotiates to determine a queue identity assignment scheme during a handoff with the second device to the accessory mode through interaction.

In the embodiment of the application, the first device and the second device can determine a queue identification allocation scheme in the interaction process of switching to the accessory mode, and the first device and the second device can determine the available queue identification of each application according to the queue identification allocation scheme. Based on this, when the first device creates the reception queue, the queue identifier of the created reception queue may be determined according to the acquired queue identifier of each application.

With reference to the first aspect, in certain implementation manners of the first aspect, the allocating, by the first device, a queue identifier for data to be sent in the application layer includes: the first device distributes queue identifications for data to be transmitted of at least one application in the application program layer, wherein the queue identifications of the data to be transmitted of different applications are different.

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

With reference to the first aspect, in certain implementation manners of the first aspect, the method further includes: the first equipment sets priority for a queue identifier of 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 device sets a priority for the receiving queue; correspondingly, the read thread in the first device determines the sequence of placing the message data packet into the shared read memory according to the priority of the receive queue, and/or the receive thread determines the sequence of placing the received data into the corresponding receive queue according to the priority of the receive queue, and/or the receive thread determines the sequence of providing the received data in the receive queue to the application program layer application according to the priority of the receive 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 that, when executed by the device, cause the device to perform the following steps in the context of establishing a USB communication connection with a second device and switching to accessory mode: distributing queue identification for data to be transmitted in an application program layer; the data to be sent carrying the queue identification is put into a shared write memory; the write thread acquires data to be transmitted carrying a queue identifier from the shared write memory, and encapsulates the data to be transmitted and the queue identifier carried by the data to be transmitted into a message packet to be transmitted; and the write 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; the read thread receives a message data packet sent by the second device from the kernel file node, wherein a queue identifier is encapsulated in the message data packet; the read thread analyzes the message data packet and puts the received data carrying the queue identifier into a shared read memory according to the analysis result; the receiving thread puts the received data into a corresponding receiving queue according to the queue identifier carried by the received data; the receive thread further provides received data from the receive queue to an application of 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 of data to be received in the application layer, wherein the queue identifications of the 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 queue identifications for data to be transmitted of at least one application in the application program layer, wherein the queue identifications of the data to be transmitted 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 plurality of queue identifications for the same application according to the data type of the data to be transmitted.

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 queue identifiers for data to be transmitted according to the queue identifier allocation scheme and/or allocating queue identifiers for the receiving queues 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 queue identification of data to be transmitted; 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 identification of the data to be sent;

setting priority for the receiving queue; correspondingly, the read thread determines the sequence of placing the message data packet into the shared read memory according to the priority of the receive queue, and/or the receive thread determines the sequence of placing the received data into the corresponding receive queue according to the priority of the receive queue, and/or the receive thread determines the sequence of providing the received data in the receive queue to the application program layer application according to the priority of the receive 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, where a computer executable program is stored in the storage medium, and where 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, the chip including a processor and a data interface, the processor reading instructions stored on a memory through the data interface, and executing the method in any possible implementation manner of the first aspect.

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, where the instructions, when executed, are configured to perform 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 comprising instructions for performing the method in any one of the possible implementations of the first aspect.

Drawings

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

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

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

FIG. 4 is a flow chart of the execution of a read thread and a write thread in an embodiment of the application;

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

FIG. 6 is a flow chart of an android device sending data to an android accessory in an embodiment of the application;

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

fig. 8 is a schematic diagram of another structure of an electronic device according to an embodiment of the present application.

Detailed Description

The technical scheme of the 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 based on the AOA protocol. The method supports multi-channel multiplexing in an application program layer, 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 the 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 the kernel file node so as to send the data to be sent to the second device through an AOA channel. Therefore, the embodiment of the application can realize multiplexing of multiple data channels at an application layer by allocating the queue identification for the data to be transmitted.

Further, the first device, upon receiving the data, creates a receive queue and a receive thread, and assigns a queue identification for the receive queue. The message data packet sent by the second device is first transmitted to the kernel file node of the first device through the AOA channel. A read thread in a first device obtains a message packet from a kernel-file node. The read thread puts the message data packet obtained 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. It can be seen that the embodiment of the present application can implement the reception of multi-queue data by creating a receive queue and allocating a queue identifier to the receive queue.

Similarly, the manner in which the second device sends data to the first device refers to the manner in which the first device sends data; the manner in which the second device receives the data sent by the first device refers to the manner in which the first device receives the data. Therefore, in the embodiment of the application, data can be transmitted in a two-way multi-channel mode between the first device and the second device. The data transmission mode is further expanded on the basis of the AOA protocol, and the multi-channel multiplexing of the application program layer is realized on the basis of data transmission based on the AOA channel.

The first device may 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 (augmented reality, AR)/Virtual Reality (VR) device, or the like. The embodiment of the application does not limit the specific type of the electronic equipment.

Fig. 1 is a schematic diagram illustrating a structure of an electronic device 100 according to 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 (universal serial bus, USB) interface 130, a charge 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, keys 190, a motor 191, an indicator 192, a camera 193, a display 194, a user identification module (subscriber identification module, SIM) card interface 195, and the like. The sensor module 180 may include a pressure sensor 180A, a gyro sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity 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 should be understood that the illustrated structure of the embodiment of the present application does not constitute a specific limitation on the electronic device 100. In other embodiments of the application, electronic device 100 may include more or fewer components than shown, or certain components may be combined, or certain components may be split, or different arrangements of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

The processor 110 may include one or more processing units, such as: the processor 110 may include an application processor (application processor, AP), a modem processor, a graphics processor (graphics processing unit, GPU), an image signal processor (image signal processor, ISP), a controller, a video codec, a digital signal processor (digital signal processor, DSP), a baseband processor, and/or a neural network processor (neural-network processing unit, NPU), etc. Wherein the different processing units may be separate devices or may be integrated in one or more processors.

The controller can generate operation control signals according to the instruction operation codes and the time sequence signals to finish the control of instruction fetching and instruction execution.

A memory may also be provided in the 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 the processor 110 has just used or recycled. If the processor 110 needs to reuse the instruction or data, it can be called directly from the memory. Repeated accesses are avoided and the latency of the processor 110 is reduced, thereby improving the efficiency of the system.

In some embodiments, the processor 110 may include one or more interfaces. The interfaces may include an integrated circuit (inter-integrated circuit, I2C) interface, an integrated circuit built-in audio (inter-integrated circuit sound, I2S) interface, a pulse code modulation (pulse code modulation, PCM) interface, a universal asynchronous receiver transmitter (universal asynchronous receiver/transmitter, UART) interface, a mobile industry processor interface (mobile industry processor interface, MIPI), a general-purpose input/output (GPIO) interface, a subscriber identity module (subscriber identity module, SIM) interface, and/or a universal serial bus (universal serial bus, USB) interface, among others.

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 transfer data between the electronic device 100 and a peripheral device. And can also be used for connecting with a headset, and playing audio through the headset. The interface may also be used to connect other electronic devices, such as AR devices, vehicle devices, etc.

It should be understood that the interfacing relationship between the modules illustrated in the embodiments of the present application is only illustrative, and is not meant to limit the structure of the electronic device 100. In other embodiments of the present application, the electronic device 100 may also employ different interfacing manners in the above embodiments, or a combination of multiple interfacing manners.

The wireless communication module 160 may provide solutions for wireless communication including wireless local area network (wireless local area networks, WLAN) (e.g., wireless fidelity (wireless fidelity, wi-Fi) network), bluetooth (BT), global navigation satellite system (global navigation satellite system, GNSS), frequency modulation (frequency modulation, FM), near field wireless communication technology (near field communication, NFC), infrared technology (IR), etc., as applied to the electronic device 100. The wireless communication module 160 may be one or more devices that integrate at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, modulates the electromagnetic wave signals, filters the 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, frequency modulate it, amplify it, and convert it to electromagnetic waves for radiation via the antenna 2.

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

The display screen 194 is used to display images, videos, and the like. The display 194 includes a display panel. The display panel may employ a liquid crystal display (liquid crystal display, LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED) or an active-matrix organic light-emitting diode (matrix organic light emitting diode), a flexible light-emitting diode (flex), a mini, a Micro led, a Micro-OLED, a quantum dot light-emitting diode (quantum dot light emitting diodes, QLED), or the like. In some embodiments, the electronic device 100 may include 1 or N display screens 194, N being a positive integer greater than 1.

The electronic device 100 may implement photographing functions through an ISP, a camera 193, a video codec, a GPU, a display screen 194, an application processor, and the like.

The ISP is used to process data fed back by the camera 193. For example, when photographing, the shutter is opened, light is transmitted to the camera photosensitive element through the lens, the optical signal is converted into an electric signal, and the camera photosensitive element transmits the electric signal to the ISP for processing and is converted into an image visible to naked eyes. ISP can also optimize 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 the 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 onto the photosensitive element. The photosensitive element may be a charge coupled device (charge coupled device, CCD) or a Complementary Metal Oxide Semiconductor (CMOS) phototransistor. The photosensitive element converts the optical signal into an electrical signal, which is then transferred to the ISP to be converted into a digital image signal. The ISP outputs the digital image signal to the DSP for processing. The DSP converts the digital image signal into an image signal in a standard RGB, YUV, or the like format. In some embodiments, 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 other digital signals besides digital image signals. For example, when the electronic device 100 selects a frequency bin, the digital signal processor is used to fourier transform the frequency bin energy, or the like.

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: dynamic picture experts group (moving picture experts group, MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

The NPU is a neural-network (NN) computing processor, and can rapidly process input information by referencing a biological neural network structure, for example, referencing a transmission mode between human brain neurons, and can also continuously perform self-learning. Applications such as intelligent awareness of the electronic device 100 may be implemented through the NPU, for example: image recognition, face recognition, speech recognition, text understanding, etc.

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

The internal memory 121 may be used to store computer executable program code including instructions. The internal memory 121 may include a storage program area and a storage data area. The storage program area may store an application program (such as a sound playing function, an image playing function, etc.) required for at least one function of the operating system, etc. The storage data area may store data created during use of the electronic device 100 (e.g., audio data, phonebook, etc.), and so on. 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 (universal flash storage, UFS), and the like. The processor 110 performs 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 through an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, an application processor, and the like. 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, or the like. The embodiment of the application does not limit the specific type of the electronic equipment. By way of example, 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 particular implementations, the processor may include primarily a controller, an operator, and registers. 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 performing fixed-point or floating-point arithmetic operations, shift operations, logic operations, and the like, and may also perform address operations and conversions. 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 circuit (Application Specific Integrated Circuits, ASIC) architecture, MIPS architecture, ARM architecture, NP architecture, or the like.

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 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, for example windows, android. 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 application, the software systems of the first device and the second device can adopt a layered architecture, an event-driven architecture, a microkernel architecture, a microservice architecture or a cloud architecture. In the embodiment of the application, the Android system with a layered architecture is taken as an example, and the software structures of the first device and the second device are illustrated. Fig. 2 is a software structural block diagram of an electronic device according to an embodiment of the present application. The layered architecture divides the software into several layers, each with distinct roles and branches. The layers communicate with each other through a software interface. In some embodiments, the Android system is divided into four layers, from top to bottom, an application layer, an application framework layer, an Zhuoyun row (Android run) and system libraries, and a kernel layer, respectively.

The application layer may include a series of application packages. As shown in fig. 2, the application package may include: talk, map, navigation, WLAN, bluetooth, music, video, etc.

The application framework layer provides an application programming interface (application programming interface, API) and programming framework for application programs 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 provided for implementing the data transmission method according to an embodiment of the present application. The multi-channel management service can allocate the queue identification for the data to be transmitted when the application program layer needs to transmit the data, and put the data to be transmitted carrying the queue identification into the shared write memory. The multi-channel management service may also create a receive queue and a receive thread when the application layer needs to receive data, allocate a queue identifier to the receive queue, and provide the receive data carrying the queue identifier from the shared read memory to a corresponding application of the application layer.

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

The window manager is used for managing window programs. The window manager can acquire 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 such data accessible to applications. The data may include video, images, audio, calls made and received, browsing history and bookmarks, phonebooks, etc. For example, data to be transmitted and received of the multichannel 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 displaying text may be included, and a view displaying a picture.

The telephony manager is for providing communication functions of the electronic device. Such as the management of call status (including on, hung-up, etc.). The resource manager provides various resources for the application program, such as localization strings, icons, pictures, layout files, video files, and the like.

Android run time includes a core library and virtual machines. Android run time is responsible for scheduling and management of the Android system.

The core library consists of 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. The virtual machine executes java files of the application program layer and the application program framework layer as binary files. The virtual machine is used for executing the functions of object life cycle management, stack management, thread management, security and exception management, garbage collection and the like.

The system library may include a plurality of functional modules. For example: surface manager (surface manager), media Libraries (Media Libraries), three-dimensional graphics processing Libraries (e.g., openGL ES), 2D graphics engines (e.g., SGL), etc.

The kernel layer is a layer between hardware and software. The inner core 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 equipment can realize the USB data transmission function through the USB drive. Further, the AOA protocol in the embodiment of the present application may be included in the kernel layer, and the AOA protocol may include the kernel file node in the embodiment of the present application.

The data transmission method according to the embodiment of the present application will be described below with reference to the above-described electronic device. In one example, the first device is a cell phone and the second device is a car phone device. Both the mobile phone and the vehicle equipment support the AOA protocol. Before the mobile phone and the vehicle device execute the data transmission method of the embodiment of the application, the USB communication connection is firstly established and the mobile phone and the vehicle device are switched to an AOA accessory mode.

Fig. 3 is a flowchart of switching between a mobile phone and a car phone device to an AOA accessory mode according to an embodiment of the present application. Based on this flow, the handset and the in-car device can switch to the AOA accessory mode, as shown in fig. 3. The mobile phone is called an android device, and the car equipment is called an android accessory. After the android device and the vehicle 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, a configuration descriptor and the like. At this time, the android device reports the information, which is usually a USB flash disk or an MTP device.

103, the android accessory initiates a first control transmission command to the android device. The first control transmission command may be used to query 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. And the 51 # instruction in the AOA protocol is a command for inquiring whether the android device supports the AOA protocol.

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

And 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 52-number command (access_send_string) to the android device based on the AOA protocol, with some authentication information attached. The authentication information may include manufacturer name, model name, description, version, etc. After the android device receives the authentication information, an application program corresponding to the accessory can be determined; 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 for starting audio support to the android device. Specifically, the android accessory can send a 58-number command (set_audio_mode) to the android device based on the AOA protocol to turn on 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-number command (ACCESSORY_START) to the android device based on the AOA protocol, informing the android device to switch to ACCESSORY mode.

108, after the android device receives the request for opening the accessory mode, switching the USB communication mode of the android device to the AOA mode. Specifically, after the android device receives a request for opening an accessory mode, the android device can automatically reset 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, wherein the new device information is USB information in accessory mode. And then the android accessory and the android device interact data in an 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 based on the AOA channel in a hardware level. Specifically, the android device and the android accessory can perform data transmission based on the kernel file node. The kernel file node is a common channel for communication between the android device and the android accessory, and the embodiment of the application multiplexes multiple channels based on the channel for data transmission. In order to perform data transmission of a large data volume and multiple channels 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, the embodiment of the present application creates two blocks of shared memory, namely a shared write memory and a shared read memory. 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. According to the embodiment of the application, the reading process and the writing process are separated, so that data can be more efficiently transmitted between the android device and the android accessory.

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

As shown in fig. 4, the processing flow of the write thread includes: the write thread acquires data to be transmitted from the shared write memory, encapsulates the data to be transmitted and the queue identifier, and transmits the message packet to be transmitted to the kernel file node so as to transmit the message packet to be transmitted to the receiving device (for example, to the second device) through the kernel file node.

The read and write threads shown in fig. 4 may be understood as the process of transferring data between the application framework layer and the kernel layer. Its final purpose is to provide a multi-channel application interface to the upper application layer. For this purpose, in the embodiment of the present application, a multi-channel management service is set in an 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 interfaces of the queues; and interfaces to send messages, receive messages, etc.

When at least one application in the application layer needs to send data, the send queue may be created through a create queue interface in the multi-channel management service, as shown in fig. 5, it is understood that creating the send queue based on the create queue interface may be creating a real data queue. In the embodiment of the application, creating the sending queue can also be allocating queue identification for the data to be sent. And forming a plurality of transmission queues among the data carrying different queue identifications. The step of creating a queue is not actually 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 creating queue interface in the multi-channel management service, and a queue identification is allocated to the receiving queue according to the queue identification. When the service is sent and received, the corresponding queue can be deleted through the queue deleting interface so as to release the queue resources. Further, the created queue information can be queried through the query queue interface.

Before the message is sent based on the message sending interface, firstly, a queue identifier is distributed for the data to be sent through the creation queue interface. And the identification of the data distribution queue to be transmitted of the application program layer is obtained. And then the data to be transmitted carrying the queue identification can be further placed into the shared write memory through the transmission message interface. The data to be sent in the shared write memory is then sent to the kernel file node by the write thread shown in fig. 4. In the process of putting the data to be transmitted of the application program layer into the shared write memory, an independent thread is not required to be created, and a message transmitting interface can be directly called when the data needs to be transmitted.

For a received message, a receive queue is first created through a create queue interface and a queue identification is assigned to the receive queue before receiving the message based on the receive message interface. For receiving message traffic, the read thread shown in FIG. 4 may be utilized to cyclically receive message packets from the kernel file node and place them into shared read memory. At the application level, the multichannel management service needs to create an independent receiving thread for the current receiving service, so that the receiving thread can send the receiving data with the queue identifier in the shared read memory to the corresponding application.

Based on the settings of fig. 4 and 5, bi-directional multi-channel data transmission between the android device and the android accessory can be achieved after the android device and the android accessory are switched to the accessory mode. In the process of data transmission, the data can be divided into: and the android device sends data to the android accessory, the android device receives data sent by the android accessory, the android accessory sends data to the android device, and the android accessory receives 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 accessory by the android device, and in the embodiment of the application, only the flow of sending data to the android accessory by the android device is taken as an example for explanation. Similarly, the flow of receiving data sent by the android accessory by the android device is the same as the flow of receiving data sent by the android accessory by the android device, and in the embodiment of the application, only the flow of receiving data sent by the android accessory by the android device is taken as an example for explanation.

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

a queue identification is assigned 201 for the data to be transmitted. The android device distributes queue identification for data to be sent in the application layer.

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

Specifically, the multichannel management service may allocate a queue identifier for each transmit queue according to the already acquired queue identifier allocation scheme. The queue identifier allocation scheme may be obtained during the process of the android accessory interacting to switch to the accessory mode. Queue identification available to each application may be included in the queue identification allocation scheme. The queue identification allocation scheme may be stored as a queue identification profile.

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

In order to realize multi-channel data multiplexing based on the AOA protocol, the multi-channel management service puts the data to be sent carrying the queue identification into the 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 vehicle device, the navigation interface data carrying the Channel ID 01 and the navigation audio data carrying the Channel ID 02 may be put into the shared write memory. The data put into the shared write memory all carry the respective queue identification. The shared write memory can be put with data to be sent carrying different queue identifications.

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

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

204, the write 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 android accessory through the kernel file node.

In the embodiment of the application, the allocation scheme of the queue identifier can be shared between the android device and the android accessory. For example, the android device and the android accessory can allocate available queue identifications for applications during interactions that switch to accessory mode. Based on the above, when the android device creates the transmission queue, the android device distributes the queue identifier for the created transmission queue according to the distribution scheme of the queue identifier. And when the android accessory is used as a receiver and data sent by the android device are received, a queue identifier can be distributed for a receiving queue according to a queue identifier 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 receiving the data may also be 0A, or other identifiers having a mapping relationship with 0A.

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

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

Wherein, when at least one application in the android device application program layer needs to receive data, the application creates a receiving queue and a receiving thread through the multi-channel management service. For example, after the navigation application of the android device sends the navigation interface data and the navigation audio data to the android accessory, the navigation application needs to receive the vehicle position data fed back by the android accessory. The navigation application may then create a receive queue and receive thread through the multi-channel management service and assign a queue identification to the receive queue.

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

Specifically, the multichannel management service may allocate a queue identifier for each receive queue according to the already acquired queue identifier allocation scheme. The queue identifier allocation scheme may be obtained during the process of the android accessory interacting to switch to the accessory mode. Queue identification available to each application may be included in the queue identification allocation scheme. The queue identification allocation scheme may be stored as a queue identification profile.

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

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

And 207, the read 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 read 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 the shared read memory.

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

Message data packets received in the kernel file node all carry queue identifications. The read thread analyzes the message data packet obtained from the kernel file node and obtains the queue identification of the message data packet. And the reading thread puts the received data carrying the queue identification into the shared reading memory according to the queue identification of the message data packet. The receiving thread created by the multi-channel management service can put the received data into a corresponding receiving queue according to the 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 for the corresponding application of the application program layer so as to realize the receiving of the data.

In the embodiment of the application, when an application needs to receive data, the multichannel management service creates a receiving thread for the received data service of the application. The receiving thread monitors the shared read memory, and when the receiving data is put in the shared read memory, the receiving thread acquires the receiving data from the shared read memory and puts the receiving data in 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 the queue identification of the data to be transmitted. 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 can be determined according to the priority of the queue identification of the data to be sent.

Further, the multichannel management service may also set a priority for the created receive queue. When the read thread puts the message data packets of the kernel file node into the shared read memory, the read thread can determine the sequence of 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 placing the received data in the shared read memory into the receiving queue according to the priority of the receiving queue. Further, the receiving thread may determine, according to the priority of the receiving queue, a sequence in which the received data in the receiving queue is provided to the corresponding application.

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 vehicle-mounted device and plays music and video on the vehicle-mounted device; and the car machine equipment sends scenes such as audio and video data shot by the car cameras, car driving data and the like to the android equipment.

The data transmission method of the embodiment of the application expands on the basis of the existing AOA protocol, and realizes multichannel data transmission on the basis of not increasing and changing system hardware and not changing top-layer service and driving of the system. Meanwhile, the advantage that the android accessory charges the android device in the AOA mode is reserved. In addition, the scheme has lower modification cost because of smaller modification to the system.

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

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

It will be appreciated that the electronic device, in order to achieve the above-described functions, includes corresponding hardware and/or software modules that perform the respective functions. The steps of the examples described in connection with the embodiments disclosed herein may be embodied in hardware or a combination of hardware and computer software. Whether a function is implemented as hardware or computer software driven hardware depends upon the particular application and design constraints imposed on the solution. Those skilled in the art can implement the described functionality using different approaches for each particular application in conjunction with the embodiments.

The present embodiment may divide the functional modules of the electronic device 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 modules described above may be implemented in hardware. It should be noted that, in this embodiment, the division of the modules is schematic, only one logic function is divided, and another division manner may be implemented in actual implementation.

Fig. 8 shows a schematic structural diagram of the electronic device involved in the above-described embodiment in the case where respective functional blocks are divided with corresponding respective functions. As shown in fig. 8, the electronic device includes:

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

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

The queue creating unit 301 is further configured to create a receive queue and a receive thread, and allocate a queue identifier to the receive 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 a queue identifier is encapsulated in the message data packet; analyzing the message data packet through a read thread, and putting the received data carrying the queue identifier into a shared read 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 the embodiment of the present application may further implement corresponding functions executed by the first device in the embodiment of the present application, which are not described herein again.

It should be understood that the electronic device herein is embodied in the form of functional units. The term "unit" herein may be implemented in software and/or hardware, without specific limitation. For example, a "unit" may be a software program, a hardware circuit or a combination of both that implements the functions described above. The hardware circuitry may include application specific integrated circuits (application specific integrated circuit, ASICs), electronic circuits, processors (e.g., shared, proprietary, or group processors, etc.) and memory for executing one or more software or firmware programs, merged logic circuits, and/or other suitable components that support the described functions.

The present application also provides an electronic apparatus including a storage medium, which may be a nonvolatile storage medium, in which a computer-executable program is stored, and a central processor connected to the nonvolatile storage medium and executing the computer-executable program to implement the data transmission method shown in fig. 3 to 7 described above.

The application also provides a chip, which comprises a processor and a data interface, wherein the processor reads instructions stored on a memory through the data interface, and executes the data transmission method shown in the figures 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 perform the data transmission method in the foregoing embodiments.

In a sixth aspect, the present technical solution provides a computer readable storage medium storing program code for execution by a device, the program code comprising instructions for performing the method in a possible implementation of the above-mentioned data transmission method.

The memory may be read-only memory (ROM), other types of static storage devices that can store static information and instructions, random access memory (random access memory, RAM) or other types of dynamic storage devices that can store information and instructions, electrically erasable programmable read-only memory (electrically erasable programmable read-only memory, EEPROM), compact disc read-only memory (compact disc read-only memory) or other optical disk storage, optical disk storage (including compact disc, laser disc, optical disc, digital versatile disc, blu-ray disc, etc.), magnetic disk storage media, or any other magnetic storage device 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, and "a plurality" means two or more. "and/or", describes an association relation of association objects, and indicates that there may be three kinds of relations, for example, a and/or B, and may indicate that a alone exists, a and B together, and B alone exists. Wherein A, B may be singular or plural. The character "/" generally indicates that the context-dependent object is an "or" relationship. "at least one of the following" and the like means any combination of these items, including any combination of single 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 plural.

Those of ordinary skill in the art will appreciate that the various elements and algorithm steps described in the embodiments disclosed herein can be implemented as a combination of electronic hardware, computer software, and electronic hardware. Whether such functionality is implemented as hardware or software 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, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

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

In several embodiments provided by the present application, any of the functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art or in a part of the technical solution, in the form of a software product stored in a storage medium, comprising several instructions for causing a computer device (which may be a personal computer, a server, a network device, etc.) to perform all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a read-only memory (ROM), a random access memory (random access memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

The foregoing is merely exemplary embodiments of the present application, and any person skilled in the art may easily conceive of changes or substitutions within the technical scope of the present application, which should be covered by 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, the method being 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 first device distributes queue identification for data to be transmitted in an application program layer;

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

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

and the write 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 according to claim 1, wherein the method further comprises:

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

a read thread in a first device receives a message data packet sent by a second device 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 identifier and receiving data, and the reading thread puts the receiving data carrying the queue identifier 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 the receive queue comprises:

the first device creates a receive queue for at least one application of data to be received in the application layer, 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 transmitted in the application layer, comprising:

the first device distributes queue identifications for data to be transmitted of at least one application in the application program layer, wherein the queue identifications of the data to be transmitted of different applications are different.

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

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

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

the first device allocates queue identifications for data to be transmitted according to the queue identification allocation scheme and/or allocates queue identifications for the receiving queues according to the queue identification allocation scheme.

7. The method according to claim 2, wherein the method further comprises: the first equipment sets priority for a queue identifier of 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 that, when executed by the device, cause the device to perform the following steps in the context of establishing a USB communication connection with a second device and switching to accessory mode:

distributing queue identification for data to be transmitted in an application program layer;

the data to be sent carrying the queue identification is put into a shared write memory;

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

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;

The read thread receives a message data packet sent by the second device from the 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 identifier and receiving data, and the receiving thread puts the receiving data carrying the queue identifier into a shared reading memory;

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 of data to be received in the application layer, wherein the queue identifications of the 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 queue identifications for data to be transmitted of at least one application in the application program layer, wherein the queue identifications of the data to be transmitted 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 allocating a plurality of queue identifications for the same application according to the data type of the data to be transmitted.

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

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

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

setting priority for the receiving queue; correspondingly, the read thread determines the sequence of placing the message data packet into the shared read memory according to the priority of the receive queue, and/or the receive thread determines the sequence of placing the received data into the corresponding receive queue according to the priority of the receive queue, and/or the receive thread determines the sequence of providing the received data in the receive queue for application program layer application according to the priority of the receive 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.