A communication method and system based on the graphics card debugging serial port

Abstract

This invention provides a communication method and system based on a graphics card's debug serial port. First, it utilizes the internal MCU commonly found within the graphics card to control the debug serial port. Second, it allocates a largely inaccessible memory region within the graphics card's memory areas, further subdividing this region into different function registers. These registers are updated by reading and writing memory to control the MCU. Finally, the graphics card driver is modified to make this memory region accessible to the host computer's CPU, thus enabling the host computer to control the MCU via the graphics card driver, thereby allowing the MCU to perform serial communication. This invention requires no additional hardware modules; its registers are completely customized by the developer through memory partitioning and MCU programming, thus possessing wide applicability and extremely high scalability.

Description

Technical Field

[0001] This invention relates to the fields of graphics card drivers and low-speed communication, and more specifically, to a communication method and system based on a graphics card debugging serial port. Background Technology

[0002] In practical applications, many hardware systems require low-speed serial communication buses to enable communication and control between modules within the system. This often necessitates the use of a communication chip with built-in communication capabilities or a dedicated communication chip. While these solutions can meet system design requirements, adding a separate communication chip and corresponding software driver in the design of some small systems can consume already limited hardware resources and incur significant software overhead.

[0003] During the development of graphics card chips, a set of serial port pins is usually reserved to meet debugging needs, allowing developers to quickly and directly adjust the graphics card's status. In practical applications, this graphics card serial port, intended as a debugging interface, is often not used, resulting in a waste of hardware resources.

[0004] On the other hand, to achieve power consumption control, graphics card chips typically have a built-in independent MCU for real-time monitoring and adjustment of chip power consumption. However, power consumption control doesn't consume much performance. Therefore, in practical applications, there is a waste of MCU performance in graphics card chips. Summary of the Invention

[0005] To avoid wasting graphics card chips, this invention provides a communication method and system based on the graphics card's debug serial port. By utilizing the graphics card's debug serial port and built-in MCU, the graphics card gains communication capabilities. This reduces the need for additional communication modules in practical applications, thereby lowering system costs and enhancing graphics card functionality.

[0006] According to a first aspect of the present invention, a communication method based on a graphics card debugging serial port is provided, applied to a communication system based on a graphics card debugging serial port. The communication system includes a host computer, a graphics card device, and a slave computer. The host computer includes an application program and a graphics card driver. The graphics card device includes a video memory area, an MCU, and a debugging serial port. The slave computer includes a serial port. The communication method includes:

[0007] Step S1: The host computer interacts with the graphics card driver through system calls to specify the serial port operation to be performed.

[0008] In step S2, the graphics card driver configures the serial port function register according to the pre-set video memory area, informing the MCU to start the operation, and the graphics card driver starts waiting for feedback from the MCU.

[0009] In step S3, the MCU, according to the register configuration, performs sending or receiving operations with the lower-level device through the debug serial port and waits for the lower-level device's reply.

[0010] In step S4, the MCU updates the status register based on the response from the lower-level device, informing the graphics card driver of the result of this operation.

[0011] In step S5, the graphics card driver processes the result of this operation based on the update of the status register and sends an event notification to the application.

[0012] In step S6, the application receives an event notification from the graphics card driver and proceeds to the next step based on the event notification.

[0013] According to a second aspect of the present invention, a communication system based on a graphics card debugging serial port is provided. The communication system based on a graphics card debugging serial port includes a host computer, a graphics card device, and a slave computer. The host computer includes an application program and a graphics card driver. The graphics card device includes a video memory area, an MCU, and a debugging serial port. The slave computer includes a serial port.

[0014] The host computer interacts with the graphics card driver through system calls to specify the serial port operation to be performed.

[0015] The graphics card driver configures the serial port function registers according to the pre-set video memory area, informs the MCU to start executing the operation, and then waits for feedback from the MCU.

[0016] According to the register configuration, the MCU sends or receives data from the lower-level device via the debug serial port and waits for a response from the lower-level device.

[0017] Based on the response from the lower-level device, the MCU updates the status register to inform the graphics card driver of the result of this operation;

[0018] The graphics card driver processes the result of this operation based on the update of the status register and sends an event notification to the application.

[0019] The application receives an event notification from the graphics card driver and proceeds to the next step based on the event notification.

[0020] This invention provides a communication method and system based on a graphics card debug serial port. By utilizing the graphics card debug serial port and the built-in MCU, the graphics card gains communication capabilities. This reduces the need for additional communication modules in practical applications, thereby lowering system costs and enhancing graphics card functionality. Attached Figure Description

[0021] Figure 1 A flowchart of a communication method based on a graphics card debugging serial port provided by the present invention;

[0022] Figure 2This is a block diagram of a communication system based on a debug serial port.

[0023] Figure 3 A flowchart of the communication method for sending mode;

[0024] Figure 4 This is a flowchart of the communication method in receive mode. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. In addition, the technical features of the various embodiments or individual embodiments provided by the present invention can be arbitrarily combined with each other to form feasible technical solutions. Such combinations are not constrained by the order of steps and / or structural composition patterns, but must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed by the present invention.

[0026] To facilitate understanding of this invention, the relevant terms and concepts are explained below.

[0027] Debug serial port: It is usually a half-duplex communication data bus using the UART protocol. It is widely used in chips and electronic devices to output device operation logs or enable external devices to operate directly.

[0028] The graphics card's built-in MCU is essentially a microcontroller connected to the chip's internal bus. It starts up after the graphics card is powered on and remains resident, able to access certain memory areas and hardware registers within the graphics card. It is typically used to monitor and adjust parameters such as the graphics card chip's operating status, power consumption, and temperature. Its ability to access the graphics card's memory and registers makes it possible to implement communication via the graphics card's memory and debug serial port.

[0029] Graphics card memory (VRAM): Also known as video memory, it is divided into different types based on its purpose and hardware design. Some types of VRAM can enable the CPU to access data in main memory through memory mapping technology, which provides the basis for computer operating systems to use VRAM to implement the data buffer function of serial communication.

[0030] See Figure 1This invention provides a communication method based on a graphics card debugging serial port, which is applied to a communication system based on a graphics card debugging serial port. A structural diagram of the communication based on the graphics card debugging serial port can be found here. Figure 2 Communication based on the graphics card debugging serial port includes a host computer, a graphics card device, and a slave computer. The host computer includes an application program and a graphics card driver. The graphics card device includes a video memory area, an MCU, and a debugging serial port. The slave computer includes a serial port.

[0031] The communication method based on the graphics card debugging serial port mainly includes the following steps:

[0032] In step S1, the host computer interacts with the graphics card driver through system calls to specify the serial port operation to be performed.

[0033] In one possible embodiment of the present invention, step S1 involves the host computer interacting with the graphics card driver via a system call to specify the serial port operation to be performed, including:

[0034] Based on the input path, the host computer uses system calls to open the device file provided by the graphics card driver for serial communication. It then interacts with the graphics card driver using different system call functions, supporting both synchronous and asynchronous I / O operations. Specifically, it uses system calls and character device operations provided by the operating system, with both synchronous and asynchronous read / write modes. The host computer opens the device file and enables either send or receive mode serial port operation, allowing the serial communication system to operate in either mode.

[0035] In step S2, the graphics card driver configures the serial port function register according to the pre-set video memory area, informing the MCU to start the operation, and the graphics card driver starts waiting for feedback from the MCU.

[0036] Specifically, a block of memory that cannot be accessed by other processes but is visible to the host CPU is allocated in the graphics card device. After this block is divided as needed, different registers are assigned to each segment of memory to enable the MCU to control the register group, thus providing a certain degree of scalability.

[0037] In step S3, the MCU, according to the register configuration, performs sending or receiving operations with the lower-level machine through the debug serial port and waits for the lower-level machine's reply.

[0038] Understandably, the MCU communicates with the lower-level machine via the debug serial port according to the different function registers configured, and realizes the sending and receiving operations with the lower-level machine. The sending operation mainly refers to sending the data to be transmitted to the lower-level machine, and the receiving operation mainly refers to receiving the reply from the lower-level machine.

[0039] In step S4, the MCU updates the status register based on the response from the lower-level device, informing the graphics card driver of the result of this operation.

[0040] Understandably, the MCU updates the status register in memory based on the response from the lower-level device. The status register indicates whether the operation was successful or not, and the result of the operation is communicated to the graphics card driver through the status register.

[0041] In step S5, the graphics card driver processes the result of this operation based on the update of the status register and sends an event notification to the application.

[0042] Understandably, the graphics card driver can determine the result of the operation based on the status register, and then send a notification to the application based on the result.

[0043] In step S6, the application receives an event notification from the graphics card driver and proceeds to the next step based on the event notification.

[0044] The communication system based on the graphics card debugging serial port provided by this invention operates in two modes: a sending mode and a receiving mode.

[0045] See Figure 3 When operating in transmit mode, the communication method includes the following steps:

[0046] In step S1', the host computer's application will divide the data into blocks and pass them to the graphics card driver via system calls;

[0047] In step S2', the graphics card driver writes the transmitted data to the video memory area and the MCU configuration information to the video memory area, sends a serial port transmission command to the MCU, and keeps checking the status register.

[0048] In step S3', the MCU constantly checks the instruction register. When it receives a send instruction, it retrieves and parses the configuration information from the video memory area. Based on the parsed configuration information, it reads the transmission data from the video memory area and drives the debug serial port.

[0049] In step S4', the MCU communicates with the lower-level machine through the debug serial port and writes the communication result to the status register address in the specified video memory area;

[0050] In step S5', after the host computer's graphics card driver detects that the status register has been updated, it returns a return value to the application through a system call based on the operation result fed back by the MCU.

[0051] In step S6', the application performs the next action based on the returned value.

[0052] In one possible embodiment of the present invention, step S4', in which the MCU communicates with the lower-level machine via a debug serial port and writes the communication result to the status register address in a specified video memory area, includes:

[0053] In step S401', the MCU determines whether the lower-level device needs to reply with an ACK based on the configuration information. If so, the MCU will send an "end" signal after the data transmission is completed. The "end" signal contains the length of the transmitted data and the CRC checksum. After the transmission is completed, the MCU will automatically switch to receiving mode and start timing. If the lower-level device does not need to reply with an ACK, the process will jump to S403'.

[0054] In step S402', the lower-level machine receives data through the serial port driver and checks whether it contains an "end" signal. If there is no "end" signal, it jumps to step S404'.

[0055] In step S403', the lower-level machine detects the "end" signal, parses the "end" signal, confirms the correctness of the transmitted data based on the data length and CRC checksum, and replies with an ACK or NACK signal to the MCU based on the confirmation result;

[0056] In step S404', the lower-level serial port continues to receive data;

[0057] In step S405', if an ACK signal is required, the MCU remains in the receiving state until it receives a reply from the lower-level machine or the timeout occurs, and updates the status register according to the reply from the lower-level machine; if an ACK signal is not required, the status register is updated immediately according to the sending result.

[0058] In one possible embodiment of the present invention, step S6', where the application performs a next action based on the return value, includes:

[0059] Step S601': Determine whether the sending operation was successful based on the system call return value. If successful, proceed to step S603'; if unsuccessful, proceed to step S602'.

[0060] Step S602': Treat the failed data block as data to be sent and proceed to step S604';

[0061] Step S603': Take the next segmented data block as the data to be sent;

[0062] Step S604': Repeat step S1 to start a new round of data transmission.

[0063] See Figure 4 When the communication system based on the graphics card debugging serial port is operating in receive mode, the communication method includes the following steps:

[0064] In step S1", the host computer application uses a system call to instruct the graphics card driver to start or stop serial port reception; if serial port reception is to be stopped, proceed to step S5.

[0065] In step S2", the graphics card driver transmits the configuration information to the specified video memory area and sends a serial port reception command to the MCU. The driver waits for the MCU to notify it through polling or interrupt.

[0066] Step S3”: The MCU constantly checks the instruction register. When it receives a receive instruction, it retrieves and parses the configuration information from the specified video memory area. The MCU continuously receives serial port data and determines whether to instruct the graphics card driver to read data from the data buffer based on the data buffer status. At the same time, the MCU keeps monitoring the instruction register. If the instruction register is updated to “stop”, it jumps to step S6”.

[0067] In step S4, after receiving the "read data" notification from the MCU, the graphics card driver reads data from the specified video memory area according to the updated status register information of the MCU, and transmits the read data to the application through a system call; the graphics card driver continues to wait for the next MCU notification to repeat this step; or receives the "stop" command from the application to close the MCU serial port reception;

[0068] In step S5", after receiving the "stop" command, the graphics card driver immediately updates the instruction register and waits for the status register to be updated;

[0069] Step S6”: When the MCU detects that the instruction register has been updated to “Stop”, it stops the serial port receiving state and updates the “Idle” state to the status register.

[0070] In step S7, if the graphics card driver detects that the MCU has switched to an "idle" state, or if it times out without waiting for the MCU to switch to an "idle" state, it returns the corresponding return value to the application through a system call.

[0071] In one possible embodiment of the present invention, in step S3", the MCU continuously receives serial port data and determines whether to instruct the graphics card driver to read data from the data buffer based on the data buffer status, including:

[0072] In step S301", the MCU continuously receives serial port data and prioritizes writing the serial port data into the data buffer buff0. At the same time, the MCU constantly monitors whether the data buffer buff0 is full.

[0073] In step S302, when data buffer buff0 is full, the MCU writes the next data into data buffer buff1 and updates the status register to inform the graphics card driver to read data from data buffer buff0.

[0074] In step S303, when data buffer buff1 is full, the MCU clears data buffer buff0 and writes subsequent data into data buffer buff0; at the same time, it updates the status register to inform the graphics card driver to retrieve data from data buffer buff1, and repeats step S301.

[0075] The following describes the two working modes of the serial communication system provided by the present invention through specific embodiments.

[0076] For serial port transmission mode, when serial communication is required, the host computer calls the graphics card driver to send data, including the following steps:

[0077] A. The application calls the graphics card driver:

[0078] Use the system calls provided by the Linux operating system to open the graphics card serial port driver device file, use the regular file write system call to write no more than 128 bytes of data to the device file, and wait for the return value of the write operation.

[0079] B. The graphics card driver calls the MCU to complete the serial port data transmission:

[0080] A 256-byte block of memory is pre-allocated in the graphics card's SRAM, and it is stipulated that this memory cannot be used by any other function besides this one. This memory space can be shared by the host computer CPU and the graphics card MCU, and is used to configure function registers. To better illustrate the interaction between the driver and the MCU, the function registers of this memory part need to be described in more detail. Their functional division is shown in Table 1 below:

[0081] Table 1 Function Registers

[0082]

[0083] As specified in Table 1 above, the graphics card driver first configures all registers except the LAUNCH register, and finally writes 0xbb to the LAUNCH register to initiate this communication operation. After this, the graphics card driver must continuously check the STATUS register and react as soon as its value is updated by the MCU.

[0084] C. The MCU sends serial port data and ACK confirmation:

[0085] The MCU continuously reads the LAUNCH register. When it detects that the LAUNCH value has changed to 0xbb, it updates the STATUS register to "Running" and simultaneously reads the values ​​of other registers, sending data according to the register requirements. After data transmission is complete, the MCU appends a verification message, the content of which is roughly as shown in Table 2 below:

[0086] Table 2 Verification Information

[0087]

[0088] After the additional verification information is sent, the MCU keeps the STATUS register unchanged and automatically switches to serial port receiving mode.

[0089] D. The lower-level machine receives the information and replies:

[0090] The lower-level device continuously maintains a receiving state and constantly checks the received data. When it detects the presence of the "###" terminator in the data, it parses the checksum packet and verifies the data's correctness based on its length and CRC information. If the check passes, it returns a pre-agreed ACK signal; otherwise, it returns a pre-agreed NACK signal.

[0091] E. The host computer processes the response signal from the slave computer:

[0092] After receiving an ACK or NACK signal, the MCU updates the STATUS register accordingly, informing the graphics card driver whether the operation was successful or failed. Upon detecting a change in the STATUS register, the graphics card driver sends its value back to the application, which then determines the next step.

[0093] For serial port receive mode, when serial communication is required, the host computer calls the graphics card driver to receive data, including the following steps:

[0094] A. The application calls the graphics card driver:

[0095] The application uses system calls provided by the Linux operating system to open the graphics card serial port driver device file. It then uses a regular file system call (ioctl) to notify the graphics card driver to begin serial port reading. After this, the application waits for feedback from the graphics card driver.

[0096] B. The graphics card driver calls the MCU to begin reading:

[0097] The graphics card driver, configured according to the registers described in Table 1, informs the MCU to begin receiving serial port information. Afterward, the graphics card driver continuously checks for updates to the STATUS register.

[0098] C. The MCU receives data and updates its status:

[0099] After receiving an update to the LAUNCH register, the MCU switches to "receive mode" according to the description of the configuration register. In a data read cycle, the MCU needs to perform the following tasks, as shown in Table 3.

[0100] Table 3: Items the MCU needs to complete

[0101]

[0102] D. The graphics card driver obtains data and transmits it to the application layer.

[0103] When an update to the STATUS register is detected, data is retrieved from the specified buffer based on its value. After retrieving the data, asynchronous I / O is used to notify the application that the buffer data has been received, and the application then uses the read system call to retrieve the data from the driver device file.

[0104] See also Figure 2 A communication system based on the graphics card debugging serial port is provided. This serial communication system is used in graphics card drivers and upper / lower computer applications, and includes the following modules:

[0105] The application program in the host computer: the initiator of serial communication, used to provide users with a convenient application layer interface when the graphics card serial communication function is required.

[0106] The host computer's graphics card driver runs at the kernel level and can be considered a special type of serial port driver. Essentially, it's part of the graphics card driver, used to control the graphics card chip's built-in MCU. This module allocates a block of video memory that cannot be occupied by other processes, used for register interaction and data storage with the MCU.

[0107] Control module for the serial port of the graphics card device:

[0108] This means the graphics card has a built-in MCU and serial port registers. Because it is independent of other modules on the graphics card, it has its own independent process that is not subject to interference, and can stably perform serial data transmission and reception.

[0109] Lower-level serial port driver module / application:

[0110] This is not a necessary module. Since the debug serial port uses the common UART protocol, most serial communication devices can communicate with the graphics card's debug serial port. In particular, when more stable communication is required, the lower-level device needs to add a dedicated serial port control module to verify data and return ACKs.

[0111] The working principle of a communication system based on a graphics card debug serial port includes:

[0112] The host computer interacts with the graphics card driver through system calls to specify the serial port operation to be performed.

[0113] The graphics card driver configures the serial port function registers according to the pre-set video memory area, informs the MCU to start executing the operation, and then waits for feedback from the MCU.

[0114] According to the register configuration, the MCU sends or receives data from the lower-level device via the debug serial port and waits for a response from the lower-level device.

[0115] Based on the response from the lower-level device, the MCU updates the status register to inform the graphics card driver of the result of this operation;

[0116] The graphics card driver processes the result of this operation based on the update of the status register and sends an event notification to the application.

[0117] The application receives an event notification from the graphics card driver and proceeds to the next step based on the event notification.

[0118] The specific technical features of the working principle of the serial communication system can be found in the aforementioned specific technical features of the communication method based on the debugging serial port, and will not be repeated here.

[0119] The present invention provides a communication method and system based on a debug serial port. Compared with the prior art, it can effectively reduce system costs by using MCU and debug serial port modules, which are common and have redundant performance in graphics cards. It can also save hardware resources when control pins or board space are scarce, and significantly improve the functionality and versatility of graphics cards.

[0120] This invention requires no additional hardware support; simply bringing out the serial port pins of the graphics card chip is sufficient to support this function. Furthermore, the software required for this invention can be integrated into the graphics card driver, and it has no stringent requirements for the software environment. Therefore, this invention possesses considerable practicality and versatility, and is of great significance in hardware systems that simultaneously require both graphics cards and low-speed communication devices.

[0121] It should be noted that the descriptions of each embodiment in the above embodiments have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0122] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0123] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0124] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0125] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0126] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0127] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A communication method based on a graphics card debugging serial port, applied to a communication system based on a graphics card debugging serial port, characterized in that, The communication system based on the graphics card debugging serial port includes a host computer, a graphics card device, and a slave computer. The host computer includes an application program and a graphics card driver. The graphics card device includes a video memory area, an MCU, and a debugging serial port. The slave computer includes a serial port. The communication method includes: Step S1: The host computer interacts with the graphics card driver through system calls to specify the serial port operation to be performed. In step S2, the graphics card driver configures the serial port function register according to the pre-set video memory area, informing the MCU to start the operation, and the graphics card driver starts waiting for feedback from the MCU. In step S3, the MCU, according to the register configuration, performs sending or receiving operations with the lower-level device through the debug serial port and waits for the lower-level device's reply. In step S4, the MCU updates the status register based on the response from the lower-level device, informing the graphics card driver of the result of this operation. In step S5, the graphics card driver processes the result of this operation based on the update of the status register and sends an event notification to the application. Step S6: The application receives an event notification from the graphics card driver and proceeds to the next step based on the event notification. When performing serial port operations in transmit mode, the communication method includes: In step S1', the host computer's application will divide the data into blocks and pass them to the graphics card driver via system calls; In step S2', the graphics card driver writes the transmission data to the video memory area and the MCU configuration information to the video memory area, sends a serial port transmission command to the MCU, and maintains the check of the status register. In step S3', the MCU constantly checks the instruction register. When it receives a send instruction, it retrieves and parses the configuration information from the video memory area. Based on the parsed configuration information, it reads the transmission data from the video memory area and drives the debug serial port. In step S4', the MCU communicates with the lower-level machine through the debug serial port and writes the communication result to the status register address in the specified video memory area; In step S5', after the host computer's graphics card driver detects that the status register has been updated, it returns a return value to the application through a system call based on the operation result fed back by the MCU. Step S6': Based on the return value, the application proceeds to the next action; When performing serial port operations in receive mode, the communication method includes: In step S1", the host computer application uses a system call to inform the graphics card driver to start or stop serial port reception; if serial port reception is to be stopped, proceed to step S5. In step S2", the graphics card driver transmits the configuration information to the specified video memory area and sends a serial port reception command to the MCU. The driver waits for the MCU to notify it through polling or interrupt. In step S3", the MCU constantly checks the instruction register. When it receives a receive instruction, it retrieves and parses the configuration information from the specified video memory area. The MCU continuously receives serial port data and determines whether to instruct the graphics card driver to read data from the data buffer based on the data buffer status. At the same time, the MCU keeps monitoring the instruction register. If the instruction register is updated to "stop", it jumps to step S6. In step S4, after receiving the "Read Data" notification from the MCU, the graphics card driver reads data from the specified video memory area according to the updated status register information of the MCU, and transmits the read data to the application through a system call; the graphics card driver continues to wait for the next MCU notification to repeat this step; or receives the "Stop" command from the application to close the MCU serial port reception; In step S5, after receiving the "stop" command, the graphics card driver immediately updates the instruction register and waits for the status register to be updated. Step S6”: When the MCU detects that the instruction register has been updated to “Stop”, it stops the serial port receiving state and updates the “Idle” state to the status register. In step S7, if the graphics card driver detects that the MCU has switched to the "idle" state, or if it times out without waiting for the MCU to switch to the "idle" state, it returns the corresponding return value to the application through a system call.

2. The communication method based on the graphics card debugging serial port according to claim 1, characterized in that, Step S1: The host computer interacts with the graphics card driver through system calls to specify the serial port operation to be performed, including: Based on the input path, the host computer uses system calls to open the device file provided by the graphics card driver for serial communication, and interacts with the graphics card driver based on different system call functions, supporting synchronous and asynchronous I / O operations. Among them, the host computer opens the device file to enable serial port operation in send or receive mode.

3. The communication method based on the graphics card debugging serial port according to claim 1, characterized in that, In step S4', the MCU communicates with the lower-level machine via the debug serial port and writes the communication result to the status register address in the specified video memory area, including: In step S401', the MCU determines whether the lower-level device needs to reply with an ACK based on the configuration information. If so, the MCU will send an "end" signal after the data transmission is completed. The "end" signal contains the length of the transmitted data and the CRC checksum. After the transmission is completed, the MCU will automatically switch to the receiving mode and start timing. If the lower-level device does not need to reply with an ACK, the process will jump to S403'. In step S402', the lower-level machine receives data through the serial port driver and checks whether it contains an "end" signal. If there is no "end" signal, it jumps to step S404'. In step S403', the lower-level machine detects the "end" signal, parses the "end" signal, confirms the correctness of the transmitted data based on the data length and CRC checksum, and replies with an ACK or NACK signal to the MCU based on the confirmation result; In step S404', the lower-level serial port continues to receive data; In step S405', if an ACK signal is required, the MCU remains in the receiving state until it receives a reply from the lower-level machine or the timeout occurs, and updates the status register according to the reply from the lower-level machine; if an ACK signal is not required, the status register is updated immediately according to the sending result.

4. The communication method based on the graphics card debugging serial port according to claim 1, characterized in that, In step S6', the application performs the next action based on the return value, including: Step S601': Determine whether the sending operation was successful based on the system call return value. If successful, proceed to step S603'; if unsuccessful, proceed to step S602'. Step S602': Treat the failed data block as data to be sent and proceed to step S604'; Step S603': Take the next segmented data block as the data to be sent; Step S604': Repeat step S1 to start a new round of data transmission.

5. The communication method based on the graphics card debugging serial port according to claim 1, characterized in that, In step S3", the MCU continuously receives serial port data and determines whether to instruct the graphics card driver to read data from the data buffer based on the data buffer status, including: In step S301", the MCU continuously receives serial port data and prioritizes writing the serial port data into the data buffer buff0. At the same time, the MCU constantly monitors whether the data buffer buff0 is full. In step S302, when data buffer buff0 is full, the MCU writes the next data into data buffer buff1 and updates the status register to inform the graphics card driver to read data from data buffer buff0. In step S303, when data buffer buff1 is full, the MCU clears data buffer buff0 and writes subsequent data into data buffer buff0; at the same time, it updates the status register to inform the graphics card driver to retrieve data from data buffer buff1, and repeats step S301.

6. A communication system based on a graphics card debugging serial port, characterized in that, The communication system based on the graphics card debugging serial port includes a host computer, a graphics card device, and a slave computer. The host computer includes an application program and a graphics card driver. The graphics card device includes a video memory area, an MCU, and a debugging serial port. The slave computer includes a serial port. The host computer interacts with the graphics card driver through system calls to specify the serial port operation to be performed. The graphics card driver configures the serial port function registers according to the pre-set video memory area, informs the MCU to start executing the operation, and then waits for feedback from the MCU. According to the register configuration, the MCU sends or receives data from the lower-level device via the debug serial port and waits for a response from the lower-level device. Based on the response from the lower-level device, the MCU updates the status register to inform the graphics card driver of the result of this operation; The graphics card driver processes the result of this operation based on the update of the status register and sends an event notification to the application. The application receives an event notification from the graphics card driver and proceeds to the next step based on the event notification. When performing serial port operations in transmit mode, the following steps are implemented using the communication system described above: In step S1', the host computer's application will divide the data into blocks and pass them to the graphics card driver via system calls; In step S2', the graphics card driver writes the transmission data to the video memory area and the MCU configuration information to the video memory area, sends a serial port transmission command to the MCU, and maintains the check of the status register. In step S3', the MCU constantly checks the instruction register. When it receives a send instruction, it retrieves and parses the configuration information from the video memory area. Based on the parsed configuration information, it reads the transmission data from the video memory area and drives the debug serial port. In step S4', the MCU communicates with the lower-level machine through the debug serial port and writes the communication result to the status register address in the specified video memory area; In step S5', after the host computer's graphics card driver detects that the status register has been updated, it returns a return value to the application through a system call based on the operation result fed back by the MCU. Step S6': Based on the return value, the application proceeds to the next action; When performing serial port operations in receive mode, the following steps are implemented using the communication system described above: In step S1", the host computer application uses a system call to inform the graphics card driver to start or stop serial port reception; if serial port reception is to be stopped, proceed to step S5. In step S2", the graphics card driver transmits the configuration information to the specified video memory area and sends a serial port reception command to the MCU. The driver waits for the MCU to notify it through polling or interrupt. In step S3", the MCU constantly checks the instruction register. When it receives a receive instruction, it retrieves and parses the configuration information from the specified video memory area. The MCU continuously receives serial port data and determines whether to instruct the graphics card driver to read data from the data buffer based on the data buffer status. At the same time, the MCU keeps monitoring the instruction register. If the instruction register is updated to "stop", it jumps to step S6. In step S4, after receiving the "Read Data" notification from the MCU, the graphics card driver reads data from the specified video memory area according to the updated status register information of the MCU, and transmits the read data to the application through a system call; the graphics card driver continues to wait for the next MCU notification to repeat this step; or receives the "Stop" command from the application to close the MCU serial port reception; In step S5, after receiving the "stop" command, the graphics card driver immediately updates the instruction register and waits for the status register to be updated. Step S6”: When the MCU detects that the instruction register has been updated to “Stop”, it stops the serial port receiving state and updates the “Idle” state to the status register. In step S7, if the graphics card driver detects that the MCU has switched to the "idle" state, or if it times out without waiting for the MCU to switch to the "idle" state, it returns the corresponding return value to the application through a system call.

Images