A method of generating serial port analog data

Abstract

The application provides a method for generating serial port simulation data, and the method checks saved user space transmitted data; in serial_start_tx, after the user space transmitted data is successfully checked, a return message is assembled, and for each byte in the return message, a tty_insert_flip_char method is called in sequence to save the data into a data buffer of a tty_buffer; a tty_flip_buffer_push method is called to add the tty_bufhead.work into a global work queue, and the return message data is returned to the user space; the application generates simulation data by using a serial port driver of Linux, does not need a third party tool, and does not need other real serial port devices, and greatly improves the generation efficiency of the serial port simulation data.

Description

Technical Field

[0001] This invention relates to the field of serial port data simulation calculation, and in particular to a method for generating serial port simulation data. Background Technology

[0002] The statements in this section are merely background information related to the present invention and do not necessarily constitute prior art.

[0003] When developing serial port-related projects, sometimes there are not enough serial port devices on hand or there are no relevant devices at all. In this case, it is necessary to use some method to simulate serial port data.

[0004] The inventors discovered that the currently common method for obtaining simulations is:

[0005] (1) A pair of virtual serial ports are created through a virtual serial port. One is used for the project program to obtain data, and the other is used for the data simulation software to generate simulated data. However, there are few virtual serial port tools under Linux and they are not very convenient to use.

[0006] (2) By using a USB to serial port device, multiple devices are connected from A to A and from B to B. One device is used for the project program, and the others are used to generate simulation data. This method requires multiple USB to serial port devices and is not suitable for test scenarios that require a large number of serial port devices. Summary of the Invention

[0007] To address the shortcomings of existing technologies, this invention provides a method for generating serial port simulation data. By utilizing the Linux serial port driver, simulation data is generated without the need for third-party tools or other real serial port devices, greatly improving the efficiency of serial port simulation data generation.

[0008] To achieve the above objectives, the present invention adopts the following technical solution:

[0009] The first aspect of this invention provides a method for generating serial port simulation data.

[0010] A method for generating serial port simulation data includes the following steps:

[0011] Register the serial port driver and add the serial port uart_port, where the ops of uart_port is of type uart_ops;

[0012] When the user space calls `write` to send data to the serial port driver through the device file, it calls the callback function set in `start_tx` of the `uart_ops` structure. The function set in `start_tx` of the callback function is `serial_start_tx`. The data sent by the user space is stored in `circ_buf`. If the data does not cross the end of the buffer, it is protected in the first form; otherwise, it is stored in the second form. The stored data sent by the user space is verified.

[0013] In serial_start_tx, after the data sent to user space is successfully verified, the return message is assembled. For each byte in the return message, the tty_insert_flip_char method is called in sequence to save the data into the data buffer of tty_buffer.

[0014] The tty_flip_buffer_push method is called to add tty_bufhead.work to the global work queue and return the message data to user space.

[0015] As an optional implementation, the callback function is: void(*start_tx)(struct uart_port*).

[0016] As an optional implementation method, serial port driver registration includes:

[0017] Use the `uart_register_driver` method to register the serial port driver `uart_driver` to the kernel.

[0018] Furthermore, uart_driver includes the device name, major version number, and minor version number, with the device name being the name displayed under / dev.

[0019] Furthermore, the serial port driver has a layered structure, including a core layer tty_core and a driver layer tty_driver. The tty_driver is encapsulated in the uart_driver structure, and the driver layer tty_driver includes the route planning.

[0020] As an optional implementation, use uart_add_one_port to add the serial port uart_port.

[0021] As an optional implementation, returning message data to user space includes:

[0022] When the user space reads serial port data through the device file, it calls the n_tty_read function of the serial port framework.

[0023] Data sent to user space is stored in the read_buf of n_tty_data. If there is data to read, the data is sent to user space; if there is no data to read, n_tty_read will sleep, waiting for the scheduling thread to retrieve the data from the global queue and call flush_to_ldisc to copy the data from tty_bufhead.tail.data to tty_struct.disc_data.read_buf.

[0024] As an optional implementation, the n_tty_read function includes:

[0025] static ssize_t n_tty_read(struct tty_struct*tty,struct file*file,unsigned char__user*buf,size_t nr).

[0026] As an optional implementation, the function for flush_to_ldisc is void flush_to_ldisc(struct work_struct*work), where the parameter work is the work in tty_bufhead.

[0027] As an optional implementation, the tty_insert_flip_char method is called sequentially to save data into the data buffer of tty_buffer. Specifically, the first two bytes of the returned message are written to the buffer, including the following process:

[0028] Write the first byte, where 1 is the value of the first byte, tty_insert_flip_char(tty,1,0);

[0029] Write the second byte, where 3 is the value of the second byte, tty_insert_flip_char(tty,3,0);

[0030] After the data is assembled, the tty_flip_buffer_push method is called to send the data out.

[0031] Compared with the prior art, the beneficial effects of the present invention are:

[0032] The method for generating serial port simulation data described in this invention utilizes the Linux serial port driver to generate simulation data. It does not require third-party tools or other real serial port devices, greatly improving the efficiency of generating serial port simulation data.

[0033] Advantages of additional aspects of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0034] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0035] Figure 1 This is a serial port driver structure provided in an embodiment of the present invention.

[0036] Figure 2 This is a schematic diagram of the hierarchical structure of the serial port driver provided in an embodiment of the present invention.

[0037] Figure 3 This is a schematic diagram of the serial port structure association provided in an embodiment of the present invention.

[0038] Figure 4 This is a schematic diagram of the circ_buf data structure provided in an embodiment of the present invention. Detailed Implementation

[0039] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0040] It should be noted that the following detailed descriptions are exemplary and intended to provide further illustration of the invention. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0041] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of exemplary embodiments according to the invention. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Furthermore, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0042] Where there is no conflict, the embodiments and features in the embodiments of the present invention can be combined with each other.

[0043] Example 1:

[0044] like Figure 1 As shown, Embodiment 1 of the present invention provides a method for generating serial port simulation data, comprising the following steps:

[0045] 1) Register the serial port driver

[0046] The serial port driver `uart_driver` is registered with the kernel using the `uart_register_driver` method. `uart_driver` contains the device name (i.e., the name displayed under ` / dev`), as well as the major and minor version numbers. See the `uart_driver` structure below. Figure 1 .

[0047] Serial port driver layered structure (see) Figure 2 It is divided into a core layer (tty_core) and a driver layer (tty_driver). The uart_driver structure encapsulates tty_driver, and the driver layer also contains line discipline.

[0048] 2) Add serial port

[0049] A serial port, `uart_port`, is added using `uart_add_one_port`. The `ops` property of `uart_port` is of type `uart_ops`, which defines callback functions for various serial port operations. `serial_start_tx` is the method called when sending data to the serial port driver, and it is the method that this invention focuses on.

[0050] 3) Receive data sent to the driver

[0051] This section covers various data structures and the relationships between them, see [link to relevant documentation]. Figure 3 .

[0052] When user space calls `write` to send data to the serial port driver via a device file (e.g., ` / dev / ttyS1`), it calls the callback function set in `start_tx` of the `uart_ops` structure. The prototype of this function is: `void(*start_tx)(struct uart_port*)`. We assume below that the function set by `start_tx` is `serial_start_tx`. Data sent from user space is stored in `circ_buf`, the structure of which can be found here. Figure 4 If the data does not cross the end of the buffer, the data is stored as follows: Figure 4 As shown in (1) above, otherwise it is Figure 4 As shown in (2) of the text.

[0053] Based on the above, the data sent by the user space can be obtained and the data can be verified.

[0054] 4) Return simulation data

[0055] In `serial_start_tx`, after successfully verifying the data sent from user space, a return message can be assembled. For each byte in the return message, the `tty_insert_flip_char` method is called sequentially; `tty_insert_flip_char` ultimately saves the data to... Figure 3 In the data buffer of tty_buffer.

[0056] Finally, the tty_flip_buffer_push method is called to... Figure 3 Add tty_bufhead.work to the global work queue.

[0057] The process of returning message data to user space is as follows:

[0058] When user space reads serial port data through a device file (e.g., / dev / ttyS1), the serial port framework's n_tty_read function is called. The prototype of this function is: static ssize_t n_tty_read(struct tty_struct*tty, struct file*file, unsigned char__user*buf, size_t nr);

[0059] Data sent to user space is stored in Figure 3 If there is data to read in the read_buf of n_tty_data, the data is sent to user space; if there is no data to read, n_tty_read will sleep, waiting for the scheduling thread to retrieve the data from the global queue mentioned above and call flush_to_ldisc to copy the data from tty_bufhead.tail.data to tty_struct.disc_data.read_buf.

[0060] The prototype of flush_to_ldisc is void flush_to_ldisc(struct work_struct*work), and the parameter work is the work in tty_bufhead.

[0061] 5) Driver installation

[0062] Write a Makefile script, type `make` to compile, and a .ko file will be generated after successful compilation;

[0063] Type `insmod name.ko` to install the driver. After successful installation, the corresponding driver file will be generated in the ` / dev` directory.

[0064] Specifically, the solution provides the following concrete examples:

[0065] S1: Register serial port driver

[0066] The serial port driver uart_driver is registered to the kernel using the uart_register_driver method. uart_driver contains the device name (i.e., the name displayed under / dev) and the major and minor version numbers.

[0067] S2: Add serial port

[0068] Use `uart_add_one_port` to add a serial port `uart_port`. The `ops` property of `uart_port` is of type `uart_ops`. This type defines callback functions for various serial port operations. Among them, `serial_start_tx` is the method called when sending data to the serial port, which is also the method that needs to be focused on in this invention.

[0069] S3: Receive data sent to the driver

[0070] The method for processing data sent to the serial port driver is serial_start_tx, and the parameter type of this method is uart_port;

[0071] uart_port->state->xmit stores the data sent to the serial port driver. All the data can be traversed through xmit->buf and xmit->tail.

[0072] The data can be saved to a local array for later use. Next, the received message can be verified.

[0073] S4: Return simulation data

[0074] uart_port->state->port is of type tty_port, and the message to be sent is written to the driver's buffer through tty_insert_flip_char.

[0075] The first two bytes of the returned message can be written to the buffer using the following method:

[0076] Write the first byte, where 1 is the value of the first byte;

[0077] tty_insert_flip_char(tty,1,0);

[0078] Write the second byte; 3 is the value of the second byte.

[0079] tty_insert_flip_char(tty,3,0);

[0080] After the data is assembled, the tty_flip_buffer_push method is called to send the data out.

[0081] S5: Simulates multiple devices connected to a single serial port.

[0082] Changing the 0th data in pkg_buf to the 0th data in snd_buf has the drawback that, in most cases, the returned data is the same.

[0083] Another approach is to define a global array, such as (using Modbus 03 function codes as an example):

[0084] char test[][7]={01,03,04,01,0x1D,01,0xFA,02,03,04,01,0x1E,01,0xFB,03,03,04,01,0x1C,01,0xFC};

[0085] Then, based on the slave address in S3, the corresponding array data is selected, and the CRC checksum is calculated and returned.

[0086] S6: Driver Installation

[0087] Write a Makefile script, type `make` to compile, and a .ko file will be generated after successful compilation;

[0088] Type `insmod name.ko` to install the driver. After successful installation, the corresponding driver file will be generated in the ` / dev` directory.

[0089] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for generating serial port simulation data, characterized in that: Includes the following processes: Register the serial port driver and add the serial port uart_port, where the ops of uart_port is of type uart_ops; When the user space calls `write` to send data to the serial port driver through the device file, it calls the callback function set in `start_tx` of the `uart_ops` structure. The function set in `start_tx` of the callback function is `serial_start_tx`. The data sent by the user space is saved. If the data does not cross the end of the buffer, it is saved in the first form; otherwise, it is saved in the second form. The saved data sent by the user space is then verified. Receive data sent to the driver, save the data to a local array. When simulating multiple devices on a single serial port, define a global array, select the corresponding array data according to the slave address, calculate the CRC check code and return the data. In serial_start_tx, after the data sent to user space is successfully verified, the return message is assembled. For each byte in the return message, the tty_insert_flip_char method is called in sequence to save the data into the data buffer of tty_buffer. The tty_flip_buffer_push method is called to add tty_bufhead.work to the global work queue and return the message data to user space.

2. The method for generating serial port simulation data as described in claim 1, characterized in that: The callback function is: void (*start_tx)(struct uart_port*).

3. The method for generating serial port simulation data as described in claim 1, characterized in that: Serial port driver registration includes: Use the `uart_register_driver` method to register the serial port driver `uart_driver` to the kernel.

4. The method for generating serial port simulation data as described in claim 3, characterized in that: uart_driver includes the device name, major version number, and minor version number. The device name is the name displayed under / dev.

5. The method for generating serial port simulation data as described in claim 3, characterized in that: The serial port driver has a layered structure, including a core layer tty_core and a driver layer tty_driver. The tty_driver is encapsulated in the uart_driver structure, and the driver layer tty_driver includes the route planning.

6. The method for generating serial port simulation data as described in claim 1, characterized in that: Use uart_add_one_port to add a serial port uart_port.

7. The method for generating serial port simulation data as described in claim 1, characterized in that: The returned message data to user space includes: When the user space reads serial port data through the device file, it calls the n_tty_read function of the serial port framework. Data sent to user space is stored in the read_buf of n_tty_data. If there is data to read, the data is sent to user space; if there is no data to read, n_tty_read will sleep, waiting for the scheduling thread to retrieve the data from the global queue and call flush_to_ldisc to copy the data from tty_bufhead.tail.data to tty_struct.disc_data.read_buf.

8. The method for generating serial port simulation data as described in claim 1, characterized in that: The n_tty_read function includes: static ssize_t n_tty_read(struct tty_struct *tty, struct file *file, unsigned char __user *buf, size_t nr).

9. The method for generating serial port simulation data as described in claim 1, characterized in that: The function for flush_to_ldisc is void flush_to_ldisc(struct work_struct *work), where the parameter work is the work in tty_bufhead.

10. The method for generating serial port simulation data as described in claim 1, characterized in that: The `tty_insert_flip_char` method is called sequentially to save data into the `tty_buffer`'s data buffer. Specifically, the first two bytes of the returned message are written to the buffer, including the following steps: Write the first byte, where 1 is the value of the first byte, tty_insert_flip_char(tty, 1, 0); Write the second byte, where 3 is the value of the second byte, tty_insert_flip_char(tty, 3, 0); After the data is assembled, the tty_flip_buffer_push method is called to send the data out.

Images