[go: up one dir, main page]

CN109508310B - Virtual UART - Google Patents

Virtual UART Download PDF

Info

Publication number
CN109508310B
CN109508310B CN201710826989.5A CN201710826989A CN109508310B CN 109508310 B CN109508310 B CN 109508310B CN 201710826989 A CN201710826989 A CN 201710826989A CN 109508310 B CN109508310 B CN 109508310B
Authority
CN
China
Prior art keywords
electronic device
uart module
module
uart
port
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201710826989.5A
Other languages
Chinese (zh)
Other versions
CN109508310A (en
Inventor
古进
陈亮
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Starblaze Technology Co ltd
Original Assignee
Beijing Starblaze Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Starblaze Technology Co ltd filed Critical Beijing Starblaze Technology Co ltd
Priority to CN201710826989.5A priority Critical patent/CN109508310B/en
Publication of CN109508310A publication Critical patent/CN109508310A/en
Application granted granted Critical
Publication of CN109508310B publication Critical patent/CN109508310B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38Information transfer, e.g. on bus
    • G06F13/40Bus structure
    • G06F13/4063Device-to-bus coupling
    • G06F13/4068Electrical coupling
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38Information transfer, e.g. on bus
    • G06F13/40Bus structure
    • G06F13/4063Device-to-bus coupling
    • G06F13/4068Electrical coupling
    • G06F13/4072Drivers or receivers

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

A virtual UART device in an electronic device is provided. The disclosed electronic device has a first function provided through a first link, and further includes a first UART module and a second UART module, wherein a transmitting port of the first UAR T module is coupled to a receiving port of the second UART module, and a receiving port of the first UART module is coupled to a transmitting port of the second UART module; the first UART module is coupled to a first link to provide a second function of the electronic device, wherein, through the first link, a first link of a transmitting port and a receiving port of the first UART module is accessed; the electronic device obtains the request from the receiving port of the second UART module and provides a response to the transmitting port of the second UART module to implement the second function of the electronic device.

Description

Virtual UART
Technical Field
The present application relates to integrated circuit technology, and more particularly, to providing a virtual UART in an integrated circuit and communicating via the virtual UART.
Background
A Universal Asynchronous Receiver/Transmitter (Universal Asynchronous Receiver/Transmitter), commonly referred to as U ART, is a commonly used communication component in electronic devices.
JTAG is short for the prefix letter of the Joint Test Action Group, JTAG is also an international standard Test protocol (IEEE 1149.1 compatible), and is mainly used for chip internal Test.
The PCIe protocol defines an inter-device communication mechanism. NVMe protocol (see also "NVM Express review 1.2" (hereinafter NVMe protocol) chapter 3, 11/3/2014) defines a mechanism for accessing non-volatile storage. PCIe devices provide Memory Space (Memory Space). A host coupled to the PCIe device may access the memory space of the PCIe device.
Fig. 1 shows a block diagram of a background art electronic device. The host (host) is coupled to the electronic device through the PCIe PHY module 110. The electronic device includes a PCIe PHY module 110, a data link layer module 120, a transport layer module 130, a memory 140, and a CPU subsystem 160. The PCIe PHY module 110 is used to handle PCIe underlying protocols (e.g., the physical layer). Both transport layer module 130 and CPU subsystem 160 may access memory 140. The data link layer module 120 is configured to handle PCIe data link layer protocols and the transport layer module 130 is configured to handle PCIe transport layer protocols. The transport Layer module 130 also accesses the memory 140 according to a TLP (transport Layer Packet) of the memory space. And optionally, the transport layer module 130 writes the TLP into the memory 140, and the CPU subsystem 160 extracts and processes the TLP from the memory 140, and the transport layer module 130 acquires the TLP from the memory 140 and sends the TLP to the host through the link layer module 120. Still alternatively, the transport layer module 130 sends the TLP to the CPU subsystem 160, and the TLP is processed by the CPU subsystem 160.
The electronic device also includes a UART 170, a UART 180 coupled to the host. Communication between UART 170 and UART 180 occurs according to a specified protocol. The UART provides a communication link for the host and the device other than a PCIe link for debugging, for example, a PCIe system of the device, running programs in the CPU, and the like. Debugging software and UAR T driver are operated in the host. The UART driver manages the UART 180 in the host. The debugging software accesses the UART 180 through the UART driver to communicate with the device through the UART 170.
The UART 170 and the UART 180 are coupled by physical leads, which occupy the interface pins of the device and the host and also occupy the pins of the chip in the device, increasing the cost. And, the site where the device is deployed on a large scale may be located in an area far from the personnel workplace, thereby making it impossible to access the device through UART 170 due to spatial/physical difficulties in contact.
Disclosure of Invention
The purpose of the present application includes reducing the device interface pins occupied by the UART and providing a convenient mechanism for a user to access a device through the UART.
According to a first aspect of the present application, there is provided a first electronic device according to the first aspect of the present application, having a first function provided through a first link, the electronic device further comprising a first UART module and a second UART module, a transmitting port of the first UART module being coupled to a receiving port of the second UART module, a receiving port of the first UART module being coupled to a transmitting port of the second UART module; the first UART module is coupled to a first link to provide a second function of the electronic device, wherein, through the first link, a first link of a transmitting port and a receiving port of the first UART module is accessed; the electronic device obtains the request from the receiving port of the second UART module and provides a response to the transmitting port of the second UART module to implement the second function of the electronic device.
According to a first electronic device of the first aspect of the present application, there is provided a second electronic device of the first aspect of the present application, wherein the first link is a link provided by a PCIe bus.
According to the first or second electronic device of the first aspect of the present application, there is provided the third electronic device of the first aspect of the present application, wherein the first UART module provides the written data to the receiving port of the second UART module in response to the data being written to its transmitting port.
According to one of the first to third electronic devices of the first aspect of the present application, there is provided the fourth electronic device of the first aspect of the present application, wherein the CPU of the electronic device, in response to occurrence of data at the receiving port of the second UART module, reads data from the receiving port of the second UART module, acquires a request from the read data, collects data according to an indication of the request, generates a response to the request, and writes the response to the transmitting port of the second UART module.
According to a fourth electronic device of the first aspect of the present application, there is provided the fifth electronic device of the first aspect of the present application, wherein the request is a debug command to a CPU of the electronic device, and the reply is a response to the debug command.
According to a fourth or fifth electronic device of the first aspect of the present application, there is provided the sixth electronic device of the first aspect of the present application, wherein the CPU of the electronic device further suspends the operation of the CPU in response to the request.
According to one of the first to sixth electronic devices of the first aspect of the present application, there is provided the seventh electronic device of the first aspect of the present application, wherein the second UART module provides the written data to the receiving port of the first UART in response to the transmitting port thereof being written with the data.
According to a seventh electronic device of the first aspect of the present application, there is provided the eighth electronic device of the first aspect of the present application, wherein the transmitting port and the receiving port of the first UART module are mapped to an address space of the first link, and the CPU of the other electronic device coupled to the first link can access the address space of the first link.
According to a seventh electronic device of the first aspect of the present application, there is provided the ninth electronic device of the first aspect of the present application, wherein the transmitting port of the first UART module is mapped to an address space of the first link, and the CPU of the other electronic device coupled to the first link can access the address space of the first link; the first UART module provides the written data to the memory of the other electronic device in response to the receiving port thereof being written with data.
According to a ninth electronic device of the first aspect of the present application, there is provided the tenth electronic device of the first aspect of the present application, wherein the CPU of the other electronic device obtains the data written to the receiving port of the first UART module from its memory.
According to one of the first to tenth electronic devices of the first aspect of the present application, there is provided the eleventh electronic device of the first aspect of the present application, wherein the first UART module indicates to another electronic device coupled to the first link that the receiving port of the first UART is written with data, in response to the receiving port thereof being written with data.
According to an eleventh electronic device of the first aspect of the present application, there is provided the twelfth electronic device of the first aspect of the present application, wherein the another electronic device acquires data written to the receiving port of the first UART module to acquire the response provided by the CPU of the electronic device.
According to one of the first to twelfth electronic devices of the first aspect of the present application, there is provided the thirteenth electronic device of the first aspect of the present application, wherein the CPU of the electronic device supplies the data written at the transmission port of the first UART module to the reception port of the second UART module in response to the transmission port of the first UART module being written with the data.
According to one of the first to thirteenth electronic devices of the first aspect of the present application, there is provided the fourteenth electronic device of the first aspect of the present application, wherein the first function is a storage function and the second function is a debugging function.
According to a fourteenth electronic device of the first aspect of the present application, there is provided the fifteenth electronic device of the first aspect of the present application, wherein the electronic device is coupled to another electronic device through the first link, and a logical address space of the electronic device is accessed by a first application of the another electronic device through the first link to provide the first function; the first UART module of the electronic device is accessed by a second application of the other electronic device through the first link to provide a second function.
According to a fourteenth or fifteenth electronic device of the first aspect of the present application, there is provided the sixteenth electronic device of the first aspect of the present application, wherein the CPU of the electronic device runs the debug server, collects debug information in response to the debug command acquired from the receiving port of the second UART module, and provides a response to the debug command to the transmitting port of the second UART module.
According to one of the fourteenth to sixteenth electronic devices of the first aspect of the present application, there is provided the seventeenth electronic device of the first aspect of the present application, wherein the CPU of the electronic device runs the storage service software, collects data in response to a command by the other electronic device to use the storage function of the electronic device, and provides a response to the other electronic device.
According to one of the first to seventeenth electronic devices of the first aspect of the present application, there is provided the eighteenth electronic device of the first aspect of the present application, wherein the first link is a link of a wireless network or a wired network.
According to one of the first to eighteenth electronic devices of the first aspect of the present application, there is provided the nineteenth electronic device of the first aspect of the present application, wherein the first UART and the second UART each further include a port indicating a status, each of which is used to indicate whether a transmitting port of each of the first UART and the second UART can be written with data, and whether a receiving port of each of the first UART and the second UART has data to be acquired.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art that other drawings can be obtained according to these drawings without creative efforts.
FIG. 1 shows a block diagram of a background art electronic device;
FIG. 2A is a block diagram of an electronic device according to an embodiment of the application;
FIG. 2B is a block diagram of a host according to an embodiment of the present application;
FIG. 3A is a flowchart illustrating a host sending data to an electronic device via a virtual UART according to an embodiment of the present disclosure;
FIG. 3B is a flowchart of a host receiving data provided by an electronic device from a virtual UART according to an embodiment of the present disclosure;
FIG. 4 shows a flowchart for debugging a control component of an electronic device according to an embodiment of the application;
FIG. 5 is a block diagram of an electronic device according to yet another embodiment of the present application; and
FIG. 6 is a block diagram of an electronic device according to another embodiment of the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some, but not all, embodiments of the present application. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
Fig. 2A is a block diagram of an electronic device according to an embodiment of the application. The host (host) is coupled to the electronic device through the PCIe PHY module 110. The electronic device includes a PCIe PHY module 110, a data link layer module 120, a transport layer module 230, a memory 140, and a CPU subsystem 260. The PCIe PHY module 110 is used to handle PCIe underlying protocols (e.g., the physical layer). Both the transport layer module 230 and the CPU subsystem 260 may access the memory 140. The data link layer module 120 is configured to handle PCIe data link layer protocols and the transport layer module 230 is configured to handle PCIe transport layer protocols. The transport Layer module 230 also accesses the memory 140 according to a memory space accessed by a TLP (transport Layer Packet). And optionally, the transport layer module 130 writes the TLP into the memory 140, and the CPU subsystem 260 extracts and processes the TLP from the memory 140, and the transport layer module 230 retrieves the TLP from the memory 140 and sends the TLP to the host through the link layer module 120. Still alternatively, the transport layer module 130 sends the TLP to the CPU subsystem 160, and the TLP is processed by the CPU subsystem 160.
The virtual UART module 210 is coupled to the transport layer module 230 for a UART for access by a host. The virtual UAR T module 210 and the virtual UART module 220 provide the functions of a standard UART device. The virtual UART module 210 is coupled to the virtual UART module 220. The virtual UART module 210 and the virtual UART module 220 each include a transmitting port, a receiving port, and a port for indicating status. Optionally, each of the virtual UART module 210 and the virtual UART module 220 further comprises an interrupt generation component to indicate an interrupt to the host/CPU subsystem 260. The transmitting port of the virtual UART module 210 is coupled to the receiving port of the virtual UART module 220. The transmitting port of the virtual UART module 220 is coupled to the receiving port of the virtual UART module 210. The transmitting port and the receiving port of the virtual UART module 210 are accessible to the host. The transmit and receive ports of the virtual UART module 220 may be accessible by the CPU subsystem 260. The host provides data to the transmitting port of the virtual UART module 210, the virtual UART module 210 transmits the data provided by the host to the transmitting port thereof to the receiving port of the virtual UART module 220, and the CPU subsystem 260 acquires the data from the receiving port of the virtual UART module 220. The CPU subsystem 260 provides data to the transmitting port of the virtual UART module 220, the virtual UART module 220 transmits the data provided to its transmitting port by the host to the receiving port of the virtual UART module 210, and the host acquires the data from the receiving port of the virtual UART module 210. The respective ports of the virtual UART module 210 and the virtual UART module 220 indicating status indicate whether the transmitting/receiving ports of the virtual UART module 210/the virtual UART module 220 can be accessed (e.g., the transmitting interface can be written with data and/or the receiving interface has data to be read). When the port indicating the status indicates that the corresponding port is not accessible, even if data is written to the transmitting port of the virtual UART module, the written data is not processed or discarded.
As an example, the transmitting port, the receiving port, and the port indicating the status of the virtual UART module 210 are mapped to a memory Space of the PCIe device, or an Extended Configuration Space (Extended Configuration Space), and the host accesses the memory Space/the Extended Configuration Space of the PCIe device to access the transmitting port, the receiving port, and the port indicating the status of the virtual UART module 210. Optionally, the virtual UART module 210 provides, for example, an MSI-X interrupt to the host when the transmit/receive port is accessible. As yet another example, the Virtual UART module 210 is presented to the host as a PCIe device or PCIe Virtual Function (VF).
Still by way of example, the transmit port, receive port, and status indicating port of the virtual UART module 220 are mapped to a space accessible to the CPU subsystem 260. The CPU subsystem 260 accesses the transmitting port, the receiving port of the virtual UART module 220 and indicates a status to operate the UART device provided by the UART module 220. Optionally, the virtual UART module 220 provides an interrupt to the CPU subsystem 260 when the transmit/receive port is accessible.
According to the embodiment of the present application, the transmission layer module 230 further maps the memory space accessed by the TLP to the virtual UART module 210, and provides the data carried by the TLP written in the memory space to the sending port of the UART module 210; or for a TLP reading memory space, data is retrieved from the receive port of the UART module 210 as a response to the TLP. In a similar manner, the host accesses the status-indicating port of the virtual UART module 210 through the TLP, and the transport layer module 230 accesses the status-indicating port of the virtual UART module 210 according to the TLP.
Optionally, the electronic device includes a plurality of paired virtual UART modules, one of which is accessible by the host and the other of which is accessible by the CPU subsystem 260 of the electronic device, thereby enabling communication between the host and the electronic device via the UART mechanism.
Fig. 2B is a block diagram of a host according to an embodiment of the application. The host includes a PCIe controller as a primary device compliant with the PCIe protocol, a PCIe PHY module coupled to the electronic device for communicating with the electronic device. The host also runs, for example, debug software, a UART driver, and/or a PCIe driver. The PCIe driver is used to manage the PCIe controller and the UART driver is used to manage the virtual UART module 210 (see also fig. 2A) provided on the PCIe device. The UART driver is, for example, a standard UART driver, and a transmitting port, a receiving port, and a port indicating a status of the standard UART device accessed by the UART driver are mapped to a transmitting port, a receiving port, and a port indicating a status of the virtual UART module 210 in a memory Space, or an Extended Configuration Space (Extended Configuration Space) of the PCIe device, provided by the PCIe driver. The debugging software is general debugging software for debugging the electronic device through a UART managed by UART driver software, for example. Alternatively, in the prior art, various software accessing the UART may access the virtual UART module 210 through standard UART driver software. The virtual UART module 210 appears to software accessing the UART to be the host's UART, or the PCIe master device's UART located at the host, and is coupled to the UART (provided by the virtual UART module 220) on the electronic device that is the PCIe slave device.
Fig. 3A is a flowchart of communication through a virtual UART according to an embodiment of the present application. In fig. 3A, a process of a host sending a message to an electronic device through a virtual UART is shown. An application program (e.g., debugging software of fig. 2B) in the host accesses the virtual UART module 210 (see fig. 2A) in the electronic device as the PCIe device through the PCIe bus using the UART driver (see also fig. 2B), and writes data to the transmission port of the virtual UART module 210 through the PCIe driver (310). For example, the transmitting port of the virtual UART module 210 is mapped to a designated address of the memory space of the PCIe device, and the application writes data to the designated address of the memory space of the PCIe device through the UART driver and the PCIe driver to write data to the transmitting port of the virtual UART module 210. The virtual UART module 210 provides the written data received by its transmit port to the receive port of the virtual UART module 220 on the PCIe device (320). The CPU of the PCIe device (e.g., CPU subsystem 260 of fig. 2A) obtains data from the receiving port of the virtual UART module 220 in response to the data appearing at the receiving port of the virtual UART module 220 (330). Alternatively, in response to the reception port presence data of the virtual UART module 220, the virtual UART module 220 sets the port of its indication state to indicate the reception port presence data. The CPU of the PCIe device learns that data is present at the receiving port of the virtual UART module 220 from the port of the virtual UART module 220 indicating the status, and acquires the data from the receiving port of the virtual UART module 220. Still alternatively, in response to the reception port presence data of the virtual UART module 220, the virtual UART module 220 issues an interrupt request to the CPU to instruct the CPU to receive port presence data of the virtual UART module 220.
FIG. 3B is a flow diagram of communication through a virtual UART according to yet another embodiment of the present application. In fig. 3B, a process of the host obtaining a message from the electronic device through the virtual UART is shown. The CPU of the PCIe device (e.g., CPU subsystem 260 of fig. 2A) writes data to the transmit port of the virtual UART module 220 of the PCIe device (340). The virtual UART module 220 provides the written data received by its transmit port to the receive port of the virtual UART module 210 on the PCIe device (350). The virtual UART module 210 also updates its status indicating port to indicate that data is present on its receiving port to be read in response to the receiving port receiving the data. The UART driver software in the host recognizes through the PCIe bus that data to be read is present at the receiving port of the virtual UART module 210 on the PCIe device (360). For example, the virtual UART module 210 generates an interrupt to the host in response to its receiving port being written with data. The UART driver software in the host retrieves data from the receiving port of the virtual UART module 210 in response to interrupts from the PCIe device (370) and provides it to the application in the host. As yet another example, an application or UART driver in the host polls the status-indicating port of the virtual UART module 210 located on the PCIe memory space and retrieves data from the receiving port when the status-indicating port indicates that the receiving port has data to read.
Fig. 4 shows a flowchart for debugging a control component of an electronic device according to an embodiment of the present application. In response to a user's debugging operations, debugging software running on the host receives debugging commands from the user (410). The debugging command is, for example, suspending CPU operation, setting program breakpoints, acquiring memory variable values, acquiring software stack information, resuming CPU operation, and the like. The debug software encodes the debug command and sends the encoded debug command through the UART driver to the send port of the virtual UART module 210 (see FIG. 2A) on the PCIe device (420). According to embodiments of the present application, an electronic device coupled to a PCIe bus of a host provides two PCIe devices, one being a virtual UART device and the other being a device that provides target functionality of the electronic device, e.g., an NVMe storage device. The virtual UART module 210 provides the debug command received by its transmit port to the receive port of the virtual UART module 220 on the PCIe bus (430). The CPU of the PCIe device (e.g., CPU subsystem 260 of fig. 2A) obtains a debug command from the receive port of the virtual UART module 220 in response to the debug command appearing at the receive port of the virtual UART module 220 (440). Alternatively, the debug command is composed of a plurality of UART data frames, and the CPU of the PCIe device acquires data from the receiving port of the virtual UART module 220 a plurality of times, and composes the data acquired a plurality of times into the debug command. Optionally, in response to the receiving port of the virtual UART module 220 receiving the debug command, the virtual UART module 220 generates an interrupt to the CPU, and the CPU, as a response to the interrupt, stores the running field of the current program and acquires data from the receiving port of the virtual UART module 220, optionally, the CPU acquires data from the receiving port of the virtual UART module 220 multiple times, and composes the debug command from the data acquired multiple times.
The CPU of the PCIe device collects data to be provided to the host running debug software according to the debug command (450). For example, the debug command is a command for suspending the operation of the CPU, and in response, the CPU acquires the address of the currently operating program, suspends the operation of the current program, generates information indicating that the CPU has stopped operating, and writes the information indicating that the CPU has stopped operating into the transmission port of the virtual UART module 220 (460). And optionally, the CPU also monitors the receive port of the virtual UART module 220 for further debug commands. As another example, the debug command is used to obtain the memory variable value, and in response, the CPU obtains the corresponding value according to the memory address or the variable name specified by the debug command, generates information indicating the memory variable and its value, and writes the information into the transmitting port of the virtual UART module 220 (460).
The virtual UART module 220 provides the written data received by its transmit port to the receive port of the virtual UART module 210 on the PCIe device (470). The virtual UART module 210 also updates its status indicating port to indicate that data is present on its receiving port to be read in response to the receiving port receiving the data. The UART driver in the host recognizes the presence of data to be read by the receiving port of the virtual UART module 210 on the PCIe device over the PCIe bus (480). The debug software retrieves data from the receiving port of the virtual UART module 210 on the PCIe device and displays it to the user (490).
In an alternative embodiment, the transmit port of the virtual UART module 210 managed by the UART driver is mapped to the memory space of the PCIe device, while the receive port of the virtual module 210 is mapped to a specified memory space of the host. The virtual UART module 210 generates an interrupt to the transport layer module 230 or the CPU of the PCIe device in response to its receive port being written with data. In response to the interrupt, the transport layer module 230 or the CPU of the PCIe device transmits data of the receiving port of the virtual UART module 210 to a designated memory space of the host, and transmits an interrupt request to the host. At the host side, in response to the interrupt, the debug software retrieves data from the receive port of the virtual UART module 210 from the host's designated memory space and presents it to the user. Still alternatively, the debugging software accesses the receiving port of the virtual UART module 210 multiple times, combines the obtained data, and presents it to the user.
FIG. 5 is a block diagram of an electronic device according to yet another embodiment of the present application. The host (host) is coupled to the electronic device through the PCIe PHY module 110. The electronic device includes a PCIe PHY module 110, a data link layer module 120, a transport layer module 530, a memory 540, and a CPU subsystem 560. Both the transport layer module 530 and the CPU subsystem 560 subsystem may access the memory 540. The transport layer module 250 is used to handle PCIe transport layer protocols. The transport Layer module 530 also accesses the memory 540 according to the memory space accessed by a TLP (transport Layer Packet). And optionally, the transport layer module 530 writes the TLP into the memory 540, and the TLP is extracted from the memory 540 and processed by the CPU subsystem 560, and the transport layer module 530 retrieves the TLP from the memory 540 and sends the TLP to the host through the link layer module 120.
In the embodiment according to FIG. 5, the transmit port, receive port, and status indicating port of the virtual UART module 510 are mapped to a designated memory space of the PCIe device. The transport layer module 530 identifies the memory space accessed by the TLP. For a TLP written in a designated memory space corresponding to the transmit port of the virtual UART module 510, the data to be written is stored in the memory 540 and an interrupt is sent to the CPU subsystem 560. In response, the CPU subsystem 560 obtains data written to the transmit port of the virtual UART module 510 from the memory 540 and writes the data to the receive port of the virtual UART module 520 in the memory 540. And another interrupt to the CPU subsystem 560 (or other CPU). In response, the CPU subsystem 560 obtains data written to the receive port of the virtual UART module 520 from the memory 540 and identifies a debug command from the data.
The CPU subsystem 560 collects data to be provided to the host according to the debug command, and writes to the transmission port of the virtual UART module 520 in the memory 540. And send interrupts to the CPU subsystem 560. In response, the CPU subsystem 560 obtains data written to the transmit port of the virtual UART module 520 from the memory 540 and writes the data to the receive port of the virtual UART module 510. And another interrupt to the CPU subsystem 560 (or other CPU). In response again, the CPU subsystem 560 (or other CPU) sends an interrupt to the host to indicate to the receive port of the virtual UART module 510 that data is present.
Optionally, the CPU subsystem polls the ports of the virtual UART module 510 and/or the virtual UART module 520 in the memory 540 for status indications to obtain data present in their respective ports.
FIG. 6 is a block diagram of an electronic device according to another embodiment of the present application. The host (host) is coupled to the electronic device through an ethernet network. The electronic device includes an ethernet PHY module 610, a TCP/IP module 620, and a CPU subsystem 660. The CPU subsystem 660 simulates the virtual UART module 630 and the virtual UART module 640. Ethernet PHY block 610 is used to handle ethernet underlying protocols (e.g., physical layer). The TCP/IP module 620 processes the TCP/IP protocol. Optionally, TCP/IP block 620 also handles other network protocols such as UDP. By way of example, CPU subsystem 660 obtains data from a TCP connection. The host's debug software communicates with the electronic device CPU subsystem 660 in an application layer protocol by which the host's debug software specifies the virtual UART module 630 to be accessed and its specified ports. For example, the debugging software of the host writes data to the transmit port of the virtual UART module 630 to indicate a debug command. The CPU subsystem 660 recognizes that the transmitting port of the virtual UART module 630 is written with data through an application layer protocol, and writes the data written into the transmitting port of the virtual UART module 630 into the receiving port of the virtual UART module 640. CPU subsystem 660 (e.g., another program) retrieves data from the receiving port of virtual UART module 640, recognizes the data as a debug command, collects debug information from the debug command, and writes a debug protocol to the transmitting port of virtual UART module 640. The CPU subsystem 660 writes data to the receive port of the virtual UART module 630 in response to the transmit port of the virtual UART module 640 being written with data. And the CPU subsystem 660 further sends the data of the receiving port of the virtual UART module 630 to the debugging software of the host through the TCP/IP module 620, and the debugging software run by the host displays the debugging information.
Providing virtual UART module 630 and/or virtual UART module 640 facilitates re-use of existing debug tools. For example, a GDB Server (GDB Server) is run by the CPU subsystem 660, and communicates with a UART device in a host through the UART device in the electronic device. Due to the provision of the virtual UART module 640, the GDB server accesses UART devices emulated by the virtual UART module 640 in a known manner without corresponding modification. Similarly, the debugging tool running in the host also accesses the UART device emulated by the virtual UART module 630 in a known manner, without the need for corresponding modifications. Therefore, the electronic equipment according to the embodiment of the application can be debugged by using various existing debugging tools. As well as a variety of existing tools that use UART devices to communicate, may also be used in conjunction with an electronic device according to embodiments of the present application.
As another embodiment, the virtual UART module 630 is provided in the electronic device instead of the virtual UART module 640. For example, the debugging software of the host writes data to the transmit port of the virtual UART module 630 to indicate a debug command. The CPU subsystem 660 recognizes that data is written to the transmission port of the virtual UART module 630 through an application layer protocol, recognizes data acquired from the virtual UART module 630 as a debug command, collects debug information according to the debug command, and writes a debug protocol to the reception port of the virtual UART module 630. And the CPU subsystem 660 further sends the data of the receiving port of the virtual UART module 630 to the debugging software of the host through the TCP/IP module 620, and the debugging software run by the host displays the debugging information.
Although the electronic device with the virtual UART according to the embodiment of the present application is described above by taking the PCIe bus and the ethernet as an example, those skilled in the art can understand that a plurality of communication links such as JTAG, bluetooth, WIFI, USB, etc. can be used instead of the PCIe bus or the ethernet according to the embodiment of the present application. Protocols such as Bluetooth and WIFI provide descriptions of a physical layer and a data link layer, a plurality of protocols such as TCP/IP are supported on the protocols, and the virtual UART according to the embodiment of the application is borne through the TCP. The USB protocol provides an interface for each device. The virtual UART according to the embodiment of the present application operates as a USB device, and maps ports of the virtual UART to endpoints of the USB device by accessing the endpoints of the USB device.
According to the embodiment of the application, the electronic equipment does not need to provide a physical UART port, so that the cost is saved. And the host coupled with the electronic equipment can be remotely accessed without the field debugging electronic equipment deployed by the electronic equipment, and the internal state and the running field of the electronic equipment are collected and debugged through the virtual UART of the electronic equipment by the debugging software running on the host. The electronic device may be, for example, a solid state drive, an in-vehicle electronic device, a graphics card, a keyboard, a smart terminal.
The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims (10)

1. An electronic device having a first function provided through a first link, the electronic device further comprising a first UART module and a second UART module, a transmitting port of the first UART module being coupled to a receiving port of the second UART module, the receiving port of the first UART module being coupled to a transmitting port of the second UART module, wherein the first UART module and the second UART module provide a function of a standard UART device;
the first UART module is coupled to the first link to provide a second function of the electronic device, wherein the transmitting port and the receiving port of the first UART module are accessed through the first link;
the electronic device obtains the request from the receiving port of the second UART module and provides a response to the transmitting port of the second UART module to implement the second function of the electronic device.
2. The electronic device of claim 1, wherein
The first UART module provides the written data to the receiving port of the second UART module in response to the transmitting port thereof being written with data.
3. An electronic device according to claim 1 or 2, wherein
The CPU of the electronic device responds to the data appearing at the receiving port of the second UART module, reads the data from the receiving port of the second UART module, acquires a request from the read data, collects the data according to the indication of the request, generates a response to the request, and writes the response into the sending port of the second UART module.
4. The electronic device of claim 3, wherein
The request is a debug command to a CPU of the electronic device and the reply is a response to the debug command.
5. The electronic device of claim 4, wherein
The CPU of the electronic device also suspends operation of the CPU in response to the request.
6. An electronic device according to claim 1 or 2, wherein
The second UART module provides the written data to the receiving port of the first UART in response to the transmitting port thereof being written with data.
7. The electronic device of claim 6, wherein
The transmitting port and the receiving port of the first UART module are mapped to an address space of the first link, which is accessible to a CPU of another electronic device coupled to the first link.
8. The electronic device of claim 6, wherein
A transmitting port of the first UART module is mapped to an address space of the first link, which is accessible to a CPU of another electronic device coupled to the first link; the first UART module provides the written data to the memory of the other electronic device in response to the receiving port thereof being written with data.
9. An electronic device according to claim 1 or 2, wherein
The electronic device is coupled to another electronic device through the first link, and a logical address space of the electronic device is accessed by a first application program of the other electronic device through the first link to provide a first function; the first UART module of the electronic device is accessed by a second application of the other electronic device through the first link to provide a second function.
10. The electronic device of claim 9, wherein
The CPU of the electronic device runs the debugging server, collects debugging information in response to the debugging command acquired from the receiving port of the second UART module, and provides the response to the debugging command to the transmitting port of the second UART module.
CN201710826989.5A 2017-09-14 2017-09-14 Virtual UART Active CN109508310B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201710826989.5A CN109508310B (en) 2017-09-14 2017-09-14 Virtual UART

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710826989.5A CN109508310B (en) 2017-09-14 2017-09-14 Virtual UART

Publications (2)

Publication Number Publication Date
CN109508310A CN109508310A (en) 2019-03-22
CN109508310B true CN109508310B (en) 2021-10-22

Family

ID=65744399

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710826989.5A Active CN109508310B (en) 2017-09-14 2017-09-14 Virtual UART

Country Status (1)

Country Link
CN (1) CN109508310B (en)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6230118B1 (en) * 1997-06-30 2001-05-08 Cirrus Logic, Inc. DOS based application supports for a controllerless modem
CN1862517A (en) * 2005-04-28 2006-11-15 惠普开发有限公司 Virtualizing uart interfaces
CN101621440A (en) * 2009-05-22 2010-01-06 浙江天正电气股份有限公司 Remote multi-path serial port communication mapping system
CN104021060A (en) * 2013-02-28 2014-09-03 鸿富锦精密工业(深圳)有限公司 BMC serial port debugging system and method
CN106569972A (en) * 2016-11-11 2017-04-19 西安电子科技大学 USB interface-based JTAG one-chip microcomputer wireless emulator and method

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090129370A1 (en) * 2007-11-16 2009-05-21 Arman Toorians Voice-Over-IP Capable Sideshow Device

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6230118B1 (en) * 1997-06-30 2001-05-08 Cirrus Logic, Inc. DOS based application supports for a controllerless modem
CN1862517A (en) * 2005-04-28 2006-11-15 惠普开发有限公司 Virtualizing uart interfaces
CN101621440A (en) * 2009-05-22 2010-01-06 浙江天正电气股份有限公司 Remote multi-path serial port communication mapping system
CN104021060A (en) * 2013-02-28 2014-09-03 鸿富锦精密工业(深圳)有限公司 BMC serial port debugging system and method
CN106569972A (en) * 2016-11-11 2017-04-19 西安电子科技大学 USB interface-based JTAG one-chip microcomputer wireless emulator and method

Also Published As

Publication number Publication date
CN109508310A (en) 2019-03-22

Similar Documents

Publication Publication Date Title
US7966441B2 (en) Interfacing apparatus and method using a single predetermined communication protocol for accessing remote peripheral devices that use different communication protocols
CN105868149B (en) Serial port information transmission method and device
US10515043B2 (en) Smart interface card control method and apparatus through a virtualized management interface
CN102323905B (en) Remote monitoring system for Godson main board
US20080005395A1 (en) Adapter to convert USB device into WUSB device
CN101291261B (en) Method and system for in-board device testing
US20150156089A1 (en) Data communication interface
CN104021060A (en) BMC serial port debugging system and method
CN104077203A (en) Method and device for diagnosing computer hardware through USB interface
CN113609045A (en) Intelligent network card BMC communication structure and method with strong universality
CN113364747B (en) Debugging method, device and system and data set generation method and device
US9639489B2 (en) I/O device sharing system and I/O device sharing method
CN112327724A (en) Instrument interface data monitoring device
CN106844133A (en) The monitoring method and device of a kind of on-chip system SOC
CN115454881A (en) Debugging system and debugging method of RISC-V architecture
CN109508310B (en) Virtual UART
CN107168917B (en) A kind of bus bridge for realizing programmable instrument communication using USBHost interface
US20150350014A1 (en) Networking implementation using a converged high speed input/output fabric technology
CN117834750A (en) Device, method, system, equipment, medium and server for acquiring protocol data
CN110750475A (en) Method and device for sharing one physical serial port by multiple CPUs, embedded equipment and medium
CN104268109A (en) Data interface communication method and device
CN103440218A (en) CAN (Control Area Network) bus monitoring method based on USB-HID (Universal Serial Bus-Human Input Device) protocol
KR100814436B1 (en) Web-based monitoring module, hardware system including the same, and web-based monitoring module monitoring method
CN106972989A (en) A kind of method and device of NTB bandwidth tests
CN102568118A (en) USB (Universal Serial Bus) data download interface based on embedded POS (Point of Sales) machine

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant