Communication method and communication system based on graphics card debugging serial port

Abstract

The invention provides a communication method and a communication system based on a graphics card debugging serial port, and the method comprises the steps: firstly, controlling the debugging serial port of the graphics card by using an internal MCU (Microprogrammed Control Unit) commonly existing in the graphics card; secondly, a memory area which is almost not operated is divided in a plurality of memory areas of the display card, the area is subdivided into different function registers, and the registers are updated in a memory reading and writing mode so as to control the MCU. And finally, a display card driver is modified, so that the memory can be accessed by the CPU of the upper computer, the MCU is controlled by the upper computer through the display card driver, and the MCU completes a serial port communication function. According to the method, a hardware module does not need to be newly added, and the register is completely self-defined by a developer through memory division and an MCU (Microprogrammed Control Unit) program, so that the method has wide applicability and extremely high expansibility.

Description

Technical Field

[0001] The present invention relates to the field of graphics card driving and low-speed communication, and more specifically, to a communication method and a communication system based on a graphics card debugging serial port. Background Art

[0002] In practical applications, many hardware systems require a low-speed serial communication bus to achieve communication and control of various modules within the system, which often requires the main control chip to have communication functions or to use a dedicated communication chip. Although these solutions can also meet the system design requirements, in the design of some small systems, adding a separate communication chip and corresponding software driver will occupy the already scarce hardware resources and software overhead.

[0003] During the development of graphics card chips, in order to meet debugging requirements, a set of serial port pins are usually reserved for developers to quickly and directly adjust the graphics card status. In actual application scenarios, as a debugging interface, the graphics card serial port is often not used, resulting in a waste of hardware resources.

[0004] On the other hand, in order to realize the power consumption control function, the graphics card chip usually has an independent MCU built in to monitor and adjust the chip power consumption in real time. However, the power consumption control function does not consume too much performance. Therefore, in actual application scenarios, there is a waste of MCU performance in the graphics card chip. Summary of the invention

[0005] In order to avoid the waste of graphics card chips, the present invention provides a communication method and a communication system based on the graphics card debugging serial port, which uses the graphics card debugging serial port and the built-in MCU to enable the graphics card to have a communication function. Therefore, in practical applications, the need for additional communication modules is reduced, which is conducive to reducing system costs and enhancing the functionality of the graphics card.

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

[0007] Step S1, the host computer interacts with the graphics card driver through a system call to specify the serial port operation to be performed;

[0008] Step S2, the graphics card driver configures the serial port function register according to the preset video memory area, notifies the MCU to start executing the operation, and the graphics card driver starts waiting for the MCU feedback;

[0009] Step S3, the MCU performs a sending operation or a receiving operation with the lower computer through the debugging serial port according to the register configuration, and waits for a reply from the lower computer;

[0010] Step S4, the MCU updates the status register according to the response from the lower computer and informs the graphics card driver of the result of this operation;

[0011] Step S5, the graphics card driver processes the result of this operation according to the update of the status register, and sends an event notification to the application;

[0012] Step S6: The application receives the event notification from the graphics card driver and performs the next step notification according to the event notification.

[0013] According to a second aspect of the present invention, there is provided a communication system based on a graphics card debugging serial port, the communication system based on a graphics card debugging serial port comprising a host computer, a graphics card device and a slave computer, the host computer comprising an application and a graphics card driver, the graphics card device comprising a video memory area, an MCU and a debugging serial port, and the slave computer comprising 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 driver configures the serial port function register according to the pre-set video memory area, notifies the MCU to start the operation, and starts waiting for the MCU feedback;

[0016] According to the register configuration, the MCU performs sending or receiving operations with the lower computer through the debugging serial port and waits for the lower computer's reply;

[0017] The MCU updates the status register according to the response from the lower computer and informs the graphics card driver of the result of this operation;

[0018] The graphics driver processes the result of this operation according to the update of the status register and sends an event notification to the application;

[0019] The application receives the event notification from the graphics card driver and makes the next notification according to the event notification.

[0020] The present invention provides a communication method and a communication system based on a graphics card debugging serial port, which utilizes the graphics card debugging serial port and a built-in MCU to enable the graphics card to have a communication function. Thus, in practical applications, the need for additional communication modules is reduced, which is beneficial to reducing system costs and enhancing the functionality of the graphics card. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0022] Figure 2It is a structural block diagram of the communication system based on the debugging serial port;

[0023] Figure 3 A flow chart of a communication method in a sending mode;

[0024] Figure 4 The flowchart of the communication method in the receiving mode is shown in FIG. DETAILED DESCRIPTION

[0025] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention. In addition, the technical features in the various embodiments or single embodiments provided by the present invention can be arbitrarily combined with each other to form a feasible technical solution. This combination is not subject to the constraints of the sequence of steps and / or the structural composition mode, but must be based on the ability of ordinary technicians in this field to achieve. When the combination of technical solutions is contradictory or cannot be achieved, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection required by the present invention.

[0026] In order to facilitate the understanding of the present invention, the relevant terms and concepts of the present invention are explained below.

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

[0028] MCU built into the graphics card: It is essentially a single-chip microcomputer connected to the bus inside the chip. It starts and keeps running after the graphics card is powered on. It can access some memory areas and hardware registers in the graphics card. It is usually used to monitor and adjust the working status, power consumption, temperature and other parameters of the graphics card chip. Because it can access the graphics card memory and registers, it makes it possible to achieve communication with the graphics card memory and debug serial port.

[0029] Graphics card memory: video memory, divided into different types according to usage and hardware design. Some types of video memory can enable the CPU to access data in memory through memory mapping technology, which provides the basis for the computer operating system to use video memory to implement the data buffer function of serial port communication.

[0030] See also Figure 1, provides a communication method based on a graphics card debugging serial port provided by the present invention, the communication method is applied to a communication system based on a graphics card debugging serial port, wherein the structure diagram of the communication based on the graphics card debugging serial port can be seen in Figure 2 The 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 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] Step S1, the host computer interacts with the graphics card driver through a system call to specify the serial port operation to be performed.

[0033] In a possible implementation of the present invention, in step S1, the host computer interacts with the graphics card driver through a system call to specify the serial port operation to be performed, including:

[0034] According to the input path, the host computer uses system calls to open the device file for serial communication provided by the graphics driver, and uses different system call functions to interact with the graphics driver, supporting synchronous and asynchronous I / O operations. Specifically, using the system calls and character device operations provided by the operating system, there are two reading and writing modes: synchronous and asynchronous. Among them, the host computer opens the device file to enable serial port operations in sending mode or receiving mode, so the serial communication system can work in two communication modes.

[0035] Step S2, the graphics card driver configures the serial port function register according to the preset video memory area, notifies the MCU to start executing the operation, and the graphics card driver starts waiting for the MCU feedback.

[0036] Among them, a piece of memory that cannot be accessed by other processes but is visible to the host computer CPU is divided in the graphics card device. After it is divided as needed, different register meanings are given to each segment of memory to realize the role of the MCU control register group, which has a certain degree of scalability.

[0037] Step S3, the MCU performs a sending operation or a receiving operation with the lower computer through the debugging serial port according to the register configuration, and waits for a reply from the lower computer.

[0038] It can be understood that the MCU implements sending and receiving operations with the slave computer through the debugging serial port according to the different function registers configured. The sending operation mainly refers to sending the data to be transmitted to the slave computer, and the receiving operation mainly refers to receiving the reply from the slave computer.

[0039] Step S4, the MCU updates the status register according to the response from the lower computer and informs the graphics card driver of the result of this operation.

[0040] It is understandable that the MCU updates the status register in the memory according to the response from the lower computer. The status register indicates whether the operation is successful or not, and the graphics card driver is informed of the result of the operation through the status register.

[0041] Step S5: The graphics card driver processes the result of this operation according to the update of the status register and sends an event notification to the application.

[0042] It is understandable that the graphics card driver can know the result of this operation based on the status register, and send a notification to the application based on the result of this operation.

[0043] Step S6, the application receives the event notification from the graphics card driver and performs the next step notification according to the event notification.

[0044] The communication system based on the graphics card debugging serial port provided by the present invention works in two working modes, namely, a sending mode and a receiving mode.

[0045] See also Figure 3 , when working in the sending mode, the steps of the communication method include:

[0046] Step S1', the application of the host computer divides the transmission data into blocks and transmits them to the graphics card driver through system calls;

[0047] Step S2', the graphics card driver writes the transmission data into the display memory area and the MCU configuration information display memory area, issues a serial port sending instruction to the MCU, and keeps checking the status register;

[0048] Step S3', the MCU checks the instruction register at all times, and when receiving a send instruction, obtains and parses the configuration information from the video memory area; according to the parsed configuration information, reads the transmission data from the video memory area, and drives the debug serial port;

[0049] Step S4', the MCU communicates with the lower computer through the debugging serial port, and writes the communication result to the status register address in the specified video memory area;

[0050] Step S5', after the graphics card driver of the host computer detects that the status register has been updated, it returns a return value to the application through a system call according to the result of this operation fed back by the MCU;

[0051] Step S6': the application performs the next step according to the returned value.

[0052] In a possible implementation of the present invention, the step S4′, step S4′, the MCU communicates with the lower computer through the debugging serial port, and writes the communication result to the status register address in the specified video memory area, includes:

[0053] Step S401', the MCU determines whether the lower machine needs to reply ACK according to the configuration information. If necessary, the MCU sends an additional "end" signal after the data is sent. The "end" signal contains the length of the transmitted data and the CRC check code, and automatically switches to the receiving mode and counts after the sending is completed; if the lower machine does not need to reply ACK, jump to S403';

[0054] Step S402', the lower computer receives data through the serial port driver and checks whether it contains an "end" signal. If there is no "end" signal, jump to step S404';

[0055] Step S403', the lower computer detects the "end" signal, analyzes the "end" signal, confirms the correctness of the transmitted data according to the data length and CRC check code, and replies an ACK or NACK signal to the MCU according to the confirmation result;

[0056] Step S404', the serial port of the lower computer continues to maintain the receiving state;

[0057] Step S405', if an ACK signal is required, the MCU maintains the receiving state until receiving a reply from the lower computer or waiting times out, and updates the status register according to the reply from the lower computer; if an ACK signal is not required, the status register is immediately updated according to the sending result.

[0058] In a possible implementation manner of the present invention, in step S6', the application performs the next step according to the return value, including:

[0059] Step S601', judging whether the sending operation is successful according to the system call return value, if successful, jump to step S603'; if failed, execute step S602';

[0060] Step S602', taking the data block that failed to be sent as the data to be sent, and jumping to step S604';

[0061] Step S603', taking the next block of data that has been segmented as data to be sent;

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

[0063] See also Figure 4 When the communication system based on the graphics card debugging serial port works in the receiving mode, the steps of the communication method include:

[0064] Step S1", the host computer application informs the graphics card driver to start or stop serial port reception through a system call; if serial port reception is to be stopped, jump to step S5";

[0065] Step S2", the graphics card driver transfers the configuration information to the designated graphics memory area, and sends a serial port receiving instruction to the MCU, and the driver waits for the MCU notification by polling or interruption;

[0066] Step S3", the MCU checks the instruction register at all times, and when receiving a receiving instruction, obtains and parses the configuration information from the specified video memory area; the MCU continuously receives serial port data, and determines whether to inform the graphics card driver to read data from the data buffer according to the data buffer situation, while the MCU keeps monitoring the instruction register. If the instruction register is updated to "stop", jump to step S6";

[0067] Step S4", after the graphics card driver receives the "read data" notification from the MCU, it reads data from the designated video memory area according to the status register information updated by 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] Step S5", after receiving the "stop" instruction, 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 is updated to “stop”, the serial port receiving state is stopped and the “idle” state is updated to the status register;

[0070] Step S7", the graphics card driver detects that the MCU has changed to the "idle" state, or times out without waiting for the MCU to change to the "idle" state, and returns a corresponding return value to the application through a system call.

[0071] In a possible implementation manner of the present invention, in S3″, the MCU continuously receives serial port data, and determines whether to inform the graphics card driver to read data from the data buffer according to the data buffer situation, including:

[0072] Step S301", the MCU continuously receives serial port data and preferentially writes the serial port data into the data buffer buff0. Meanwhile, the MCU constantly monitors whether the data buffer buff0 is full;

[0073] Step S302", when the data buffer buff0 is full, the MCU writes the next data into the data buffer buff1, and updates the status register at the same time, notifying the graphics card driver to read data from the data buffer buff0;

[0074] Step S303", when the data buffer buff1 is full, the MCU clears the data buffer buff0 and writes subsequent data into the data buffer buff0; at the same time, the status register is updated to inform the graphics card driver to fetch data from the data buffer buff1, and step S301" is repeated.

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

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

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

[0078] Use the system call 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] It is agreed in advance to allocate a 256-byte memory in the graphics card SRAM, which cannot be used by other functions except this function. This memory space can be shared by the host computer CPU and the graphics card MCU and is used to configure the function registers. In order to better explain the interaction between the driver and the MCU, it is necessary to explain the function registers of this part of the memory in more detail. Its function division is as shown in Table 1:

[0081] Table 1 Function register

[0082]

[0083] The graphics driver configures the registers except the LAUNCH register according to the above table 1, and finally writes 0xbb to the LAUNCH register to start the communication operation. After that, the graphics driver should keep checking the STATUS register (status register) and respond after its value is updated by the MCU.

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

[0085] The MCU reads the LAUNCH register in a loop. When it finds that its value changes to 0xbb, it updates the STATUS register to "running". At the same time, it reads the values ​​of other registers and sends data according to the requirements of the registers. After the data is sent, the MCU adds a verification message to send. The content is roughly as shown in Table 2:

[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 the serial port receiving state.

[0089] D. The lower computer receives the information and replies:

[0090] The lower computer keeps receiving and checks the received data. When the "###" terminator is found in the data, the check packet is parsed and the correctness of the data is confirmed based on the length and crc information. If the check passes, the pre-agreed ACK signal is returned; otherwise, the pre-agreed NACK signal is returned.

[0091] E. The upper computer processes the reply signal from the lower computer:

[0092] After receiving the ACK or NACK signal, the MCU updates the STATUS register according to the result, informing the graphics driver of the success or failure of this operation. After the graphics driver detects the change of the STATUS register, it feeds back to the application according to its value, and the application decides the next operation.

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

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

[0095] Use the system call provided by the Linux operating system to open the graphics card serial port driver device file. Use the regular file system call ioctl to tell the graphics card driver to start serial port reading. After that, the application waits for feedback from the graphics card driver.

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

[0097] The graphics driver tells the MCU to start receiving serial port information according to the register configuration described in Table 1. After that, the graphics driver keeps checking the update of the STATUS register.

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

[0099] After receiving the LAUNCH register update, the MCU switches to "receive mode" according to the description of the configuration register. In a data reading cycle, the MCU needs to complete the following tasks, see Table 3.

[0100] Table 3 MCU needs to complete the task

[0101]

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

[0103] When the STATUS register is updated, the data is fetched from the specified buff according to its value. After the data is fetched, the application is informed of the buff data received using asynchronous I / O, and the application uses the read system call to fetch the data from the driver device file.

[0104] See also Figure 2 The communication system based on the graphics card debugging serial port is used in the graphics card driver and the upper and lower computer applications, including the following modules:

[0105] Application 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 needed.

[0106] Graphics driver of the host computer: runs in the kernel layer and can be regarded as a special serial port driver. It is essentially a part of the graphics driver and is used to control the built-in MCU of the graphics chip. This module allocates a piece of video memory space that cannot be occupied by other processes, which is used to interact with the MCU to realize registers and store data.

[0107] Graphics card device serial port control module:

[0108] That is, the graphics card has built-in MCU and serial port registers. Since it is independent of other modules of the graphics card and has an independent process without interference, it can stably perform the sending and receiving of serial port data.

[0109] Driver module / application of the lower computer serial port:

[0110] It is not a necessary module. Since the debug serial port uses the universal UART protocol, all common serial communication devices can communicate with the graphics card debug serial port. In particular, when more stable communication is required, the lower computer needs to add a special serial port control module to verify data and return ACK.

[0111] The working principle of the communication system based on the graphics card debugging 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 driver configures the serial port function register according to the pre-set video memory area, notifies the MCU to start the operation, and starts waiting for the MCU feedback;

[0114] According to the register configuration, the MCU performs sending or receiving operations with the lower computer through the debugging serial port and waits for the lower computer's reply;

[0115] The MCU updates the status register according to the response from the lower computer and informs the graphics card driver of the result of this operation;

[0116] The graphics driver processes the result of this operation according to the update of the status register and sends an event notification to the application;

[0117] The application receives the event notification from the graphics card driver and makes the next notification according to the event notification.

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

[0119] The embodiments of the present invention provide a communication method and a communication system based on a debug serial port. Compared with the prior art, since the MCU and debug serial port modules that are common in graphics cards and have redundant performance are used, the system cost can be effectively reduced, hardware resources can be saved when control pins or board-level space are scarce, and the functionality and versatility of the graphics card can be significantly improved.

[0120] The present invention does not require additional hardware support, and can support this function by only bringing out the serial port pins of the graphics card chip. The software required by the present invention can be integrated into the graphics card driver, and there is no strict requirement for the software environment. Therefore, the present invention has considerable practicality and versatility, and is of great significance in a wide range of hardware systems that require both graphics cards and low-speed communication devices.

[0121] It should be noted that in the above embodiments, the description of each embodiment has its own emphasis, and for parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0122] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may take the form of a computer program product implemented 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] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded computer, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0124] These computer program instructions may also be stored in a computer readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0125] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process in the computer or other programmable device. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0126] Although the preferred embodiments of the present invention have been described, those skilled in the art may make other changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present invention.

[0127] Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended 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 and a graphics card driver, the graphics card device includes a video memory area, an MCU and a debugging serial port, and the slave computer includes a serial port; the communication method includes: Step S1, the host computer interacts with the graphics card driver through a system call to specify the serial port operation to be performed; Step S2, the graphics card driver configures the serial port function register according to the preset video memory area, notifies the MCU to start executing the operation, and the graphics card driver starts waiting for the MCU feedback; Step S3, the MCU performs a sending operation or a receiving operation with the lower computer through the debugging serial port according to the register configuration, and waits for a reply from the lower computer; Step S4, the MCU updates the status register according to the response from the lower computer and informs the graphics card driver of the result of this operation; Step S5, the graphics card driver processes the result of this operation according to the update of the status register, and sends an event notification to the application; Step S6, the application receives the event notification from the graphics card driver and performs the next step notification according to the event notification.

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 a system call to specify the serial port operation to be performed, including: According to the input path, the host computer uses system calls to open the device file for serial port communication provided by the graphics driver, interacts with the graphics driver based on different system call functions, and supports synchronous and asynchronous I / O operations; Among them, the host computer opens the device file to enable the serial port operation in the sending mode or the receiving mode.

3. The communication method based on the graphics card debugging serial port according to claim 1, characterized in that: When performing a serial port operation in a sending mode, the communication method includes: Step S1', the application of the host computer divides the transmission data into blocks and transmits them to the graphics card driver through system calls; Step S2', the graphics card driver writes the transmission data into the graphics memory area and the MCU configuration information into the graphics memory area, sends a serial port sending instruction to the MCU, and keeps checking the status register; Step S3', the MCU checks the instruction register at all times, and when receiving a send instruction, obtains and parses the configuration information from the video memory area; according to the parsed configuration information, reads the transmission data from the video memory area, and drives the debug serial port; Step S4', the MCU communicates with the lower computer through the debugging serial port, and writes the communication result to the status register address in the specified video memory area; Step S5', after the graphics card driver of the host computer detects that the status register has been updated, it returns a return value to the application through a system call according to the result of this operation fed back by the MCU; Step S6': the application performs the next step according to the returned value.

4. The communication method based on the graphics card debugging serial port according to claim 3, characterized in that: In step S4', the MCU communicates with the lower computer through the debugging serial port and writes the communication result to the status register address in the specified video memory area, including: Step S401', the MCU decides whether the lower machine needs to reply ACK according to the configuration information. If so, the MCU sends an additional "end" signal after the data is sent. The "end" signal contains the length of the transmitted data and the CRC check code, and automatically switches to the receiving mode and counts after the sending is completed; if the lower machine does not need to reply ACK, jump to S403'; Step S402', the lower computer receives data through the serial port driver and checks whether it contains an "end" signal. If there is no "end" signal, jump to step S404'; Step S403', the lower computer detects the "end" signal, parses the "end" signal, confirms the correctness of the transmitted data according to the data length and CRC check code, and replies ACK or NACK signal to the MCU according to the confirmation result; Step S404', the serial port of the lower computer continues to maintain the receiving state; Step S405', if an ACK signal is required, the MCU maintains the receiving state until receiving a reply from the lower computer or waiting times out, and updates the status register according to the reply from the lower computer; if an ACK signal is not required, the status register is immediately updated according to the sending result.

5. The communication method based on the graphics card debugging serial port according to claim 3, characterized in that: In step S6', the application performs the next step according to the returned value, including: Step S601', judging whether the sending operation is successful according to the system call return value, if successful, jump to step S603'; if failed, execute step S602'; Step S602', taking the data block that failed to be sent as the data to be sent, and jumping to step S604'; Step S603', taking the next block of data that has been segmented as data to be sent; Step S604', repeat step S1 to start a new round of data transmission.

6. The communication method based on the graphics card debugging serial port according to claim 2, characterized in that: When performing serial port operation in receiving mode, the communication method includes: Step S1", the host computer application informs the graphics card driver to start or stop serial port reception through a system call; if serial port reception is to be stopped, jump to step S5"; Step S2", the graphics card driver transfers the configuration information to the designated graphics memory area, and sends a serial port receiving instruction to the MCU, and the driver waits for the MCU notification by polling or interruption; Step S3", the MCU checks the instruction register at all times, and when receiving a receiving instruction, obtains and parses the configuration information from the specified video memory area; the MCU continuously receives serial port data, and determines whether to inform the graphics card driver to read data from the data buffer according to the data buffer situation, while the MCU keeps monitoring the instruction register. If the instruction register is updated to "stop", jump to step S6"; Step S4", after the graphics card driver receives the "read data" notification from the MCU, it reads data from the designated video memory area according to the status register information updated by 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; Step S5", after receiving the "stop" instruction, 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 is updated to "stop", the serial port receiving state is stopped and the "idle" state is updated to the status register; Step S7", the graphics card driver detects that the MCU has changed to the "idle" state, or times out without waiting for the MCU to change to the "idle" state, and returns a corresponding return value to the application through a system call.

7. The communication method based on the graphics card debugging serial port according to claim 6, characterized in that: In the above-mentioned S3", the MCU continuously receives serial port data and determines whether to inform the graphics card driver to read data from the data buffer according to the data buffer situation, including: Step S301", the MCU continuously receives serial port data and preferentially writes the serial port data into the data buffer buff0. Meanwhile, the MCU constantly monitors whether the data buffer buff0 is full; Step S302", when the data buffer buff0 is full, the MCU writes the next data into the data buffer buff1, and updates the status register at the same time, notifying the graphics card driver to read data from the data buffer buff0; Step S303", when the data buffer buff1 is full, the MCU clears the data buffer buff0 and writes subsequent data into the data buffer buff0; at the same time, the status register is updated to inform the graphics card driver to fetch data from the data buffer buff1, and step S301" is repeated.

8. 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, wherein the host computer includes an application and a graphics card driver, the graphics card device includes a video memory area, an MCU and a debugging serial port, and 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 driver configures the serial port function register according to the pre-set video memory area, notifies the MCU to start the operation, and starts waiting for the MCU feedback; According to the register configuration, the MCU performs sending or receiving operations with the lower computer through the debugging serial port and waits for the lower computer's reply; The MCU updates the status register according to the response from the lower computer and informs the graphics card driver of the result of this operation; The graphics driver processes the result of this operation according to the update of the status register and sends an event notification to the application; The application receives the event notification from the graphics card driver and makes the next notification according to the event notification.

Images