CN107168710B - Embedded Linux serial port driver development method based on blocking receiving mechanism - Google Patents
Embedded Linux serial port driver development method based on blocking receiving mechanism Download PDFInfo
- Publication number
- CN107168710B CN107168710B CN201710342129.4A CN201710342129A CN107168710B CN 107168710 B CN107168710 B CN 107168710B CN 201710342129 A CN201710342129 A CN 201710342129A CN 107168710 B CN107168710 B CN 107168710B
- Authority
- CN
- China
- Prior art keywords
- data
- fifo
- serial port
- buffer
- read
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/20—Software design
- G06F8/22—Procedural
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Communication Control (AREA)
Abstract
The invention relates to the technical field of Linux serial port driver development, in particular to an embedded Linux serial port driver development method based on a blocking receiving mechanism. The invention adopts a character type equipment framework to design a Linux serial port driver, a receiving data cache region, a read function blocking reading mechanism and a data packet real-time processing mechanism, effectively improves the real-time processing data performance of the Linux serial port driver, has high stability and strong real-time performance, and solves the problem of communication frame loss in the development technology of the Linux serial port driver. The invention is suitable for serial port communication of embedded Linux equipment.
Description
Technical Field
The invention relates to the technical field of Linux serial port driver development, in particular to an embedded Linux serial port driver development method based on a blocking receiving mechanism.
Background
In recent years, with the rapid development of embedded systems, embedded Linux systems occupy an important position in the field of embedded development due to the characteristics of their source code openness and their system uniqueness. Although the Linux system has a lot of general device driver supports, a user needs to add a program (such as mechanism association, protocol analysis addition, and the like) for specific development and application, and the general device driver is not suitable for the application. Currently, a general technical method for real-time acquisition and processing of serial data in most embedded devices is a development method for completing acquisition of data packets in a driver layer and processing the data packets in an application layer, and a specific development mode and existing problems are as follows:
(1) the method for completing the collection of the serial port data packet in the universal driving layer comprises the following steps: in order to reduce the occupation rate of the CPU, the drive layer adopts mechanisms such as serial port interruption, dormancy, awakening and the like to realize data reception, and the general flow is as follows: the read serial port reading function of the drive layer enters dormancy firstly, then receives data and interrupts to wake up a read process when an interrupt comes, and uploads single byte data/data packets to an application layer. This mechanism can lead to the following conflicts: because the data or data packets received before the read of the drive layer are uploaded to the application layer are all in a dormant state, the read process is awakened only under the condition of interrupting the data receiving, when the read function is awakened and is ready to read the data from the cache region, the interruption receives new data again, and the new data is stored in the cache region read by the read function, so that the time sequence of writing and reading the cache region conflicts and is covered by the new data, and the read reading is lost. Under the condition of high serial port communication rate, the problem of communication frame loss caused by collision is more serious;
(2) the application layer reads the serial port data by calling a read function of the drive layer, generally adopting a non-blocking reading method (such as timing query and real-time query) or a blocking reading method (a receiving queue is suspended until data or a data packet is received completely), wherein the non-blocking timing query can solve the mechanism conflict problem in the step (1), and the real-time property of receiving the data can be reduced; the non-blocking real-time query and blocking reading method requires the corresponding mechanism cooperation of the driving layer, which also causes the problem in (1);
(3) the development method for processing the serial data packet (such as detecting a data frame header and a frame tail, checking data length and check bits and the like) is generally developed in an application layer, and the serial data needs to be transmitted through a Linux kernel layer, so that the real-time performance of the data is reduced, especially when the data of the application layer is processed in an error condition, the serial port still needs to be received and transmitted again, the application layer calls the Linux kernel layer again to drive, and the real-time performance of the data is inevitably reduced again.
Therefore, the embedded Linux serial port driver development method with high stability and strong real-time performance is needed to solve the problem of communication frame loss in the Linux serial port driver and improve the real-time performance of serial port data acquisition and processing.
Disclosure of Invention
In order to overcome the defects in the prior art, the invention provides the embedded Linux serial port driver development method based on the blocking receiving mechanism, the method is high in stability and real-time performance, the problem of communication frame loss in the Linux serial port driver is solved, and the real-time performance of serial port data acquisition and processing is improved.
In order to solve the technical problems, the technical scheme adopted by the invention is as follows:
an embedded Linux serial port drive development method based on a blocking receiving mechanism is carried out according to the following steps: step one, designing a Linux serial port driver by adopting a character type equipment framework; designing a receiving data cache region; designing a read function blocking reading mechanism; and step four, designing a real-time processing mechanism of the data packet.
The first step is specifically as follows:
1) defining a structure file _ operationmyuart _ fos, and adding open, read, write, close and ioctl functions to the structure;
2) defining a device name and registering the device with a kernel;
3) defining a serial port register, mapping a virtual address, and configuring the register and pins;
4) declaring a serial port sleep waiting queue, initializing in an open function, applying for a serial port to receive an interrupt number in the open function, initializing serial port configuration, and initializing the sleep waiting queue to enable the sleep waiting queue to receive interrupt;
5) writing a write function: judging whether the current sending buffer area is empty, writing data to be sent into the sending buffer area, and sending the data; and the steps are circulated until the specified transmission data length TX _ count is transmitted.
The second step is specifically as follows:
1) defining a buffer structure body Rx _ fifo, wherein the buffer structure body Rx _ fifo comprises the following components: buffer length fifo _ size, buffer start offset address fifo _ in, buffer end offset address fifo _ out; fifo _ out-fifo _ in is Rx _ count which is the length of data currently received by the serial port driver;
2) designing a receiving buffer area annular storage mode:
when (fifo _ size-fifo _ out) is greater than or equal to app _ Rx _ count, it is indicated that the remaining buffer space can buffer the data of the app _ Rx _ count length, fifo _ out is initialized to fifo _ in, the serial port interrupt is always in a receiving state, once there is data, the data is put into the buffer, and the next judgment is performed;
when (fifo _ size-fifo _ out) < app _ Rx _ count or fifo _ size equals fifo _ out, indicating that the receiving buffer is not enough to buffer data of the length of app _ Rx _ count or the receiving buffer is full, fifo _ in is 0 and fifo _ out is fifo _ in, the buffer returns to the starting state, thus forming a buffer loop-back storage mechanism.
The third step is specifically as follows:
1) the Linux serial port driver receives data in real time by adopting an interrupt + dormancy/awakening mechanism, and the driver layer read function adopts a blocking reading mechanism to match with the real-time calling of non-blocking real-time inquiry read reading of an application layer;
2) after the annular cache region is set, the drive layer interrupt function is put into the Rx _ fifo cache region after receiving one byte of data; the driver layer read function adopts the following blocking mechanism and data packet real-time processing mechanism:
①, firstly, judging whether Rx _ count is larger than or equal to app _ Rx _ count, namely, the length of data currently received by the serial port is larger than or equal to the length of data to be read by the application layer, and directly reading the data in the cache region, thereby effectively avoiding the time sequence conflict that the drive layer read function can read the uploaded data and interrupt the received data only after being interrupted and awakened after being dormant;
②, when Rx _ count is less than app _ Rx _ count, that is, the data length currently received by the serial port is less than the data length that needs to be read by the application layer, the read process will be put to sleep, at this time, the read function has no data to be read and uploaded, and the step ① is executed only when Rx _ count is greater than or equal to app _ Rx _ count.
The fourth step is specifically as follows: and after reading the data received by the cache region, the drive layer read analyzes the data packet, if the data is correct, the analyzed data is transmitted to an application layer read function through a copy _ to _ user function, if the data is incorrect, the drive layer write function is called to send the previous command information again, the read function analyzes the received data again through the read function, and if the data is still incorrect, the read function sends the receiving error information to the application layer.
Compared with the prior art, the invention has the beneficial effects that:
firstly, compared with the existing blocked serial port drive development technology, the invention solves the problem of data frame loss caused by time sequence conflict between the called process and interruption of the read function of the drive layer by adopting an annular cache mechanism and a read blocking reading judgment mechanism; secondly, compared with the existing non-blocking serial port drive development technology, the invention calls a read reading function in real time through an application program, and a drive layer receives serial port data in real time by adopting a read blocking reading judgment mechanism and an interrupt dormancy mechanism, thereby solving the problems of poor real-time performance caused by the application layer timing reading function adopted in the non-blocking serial port drive development technology or high CPU occupancy rate caused by the application layer receiving data in real time; thirdly, compared with the traditional mechanism of analyzing the data packet by the application layer, the invention adopts the read function of the driver layer to analyze the data twice, thereby improving the data communication accuracy and the real-time data processing performance.
In conclusion, the embedded Linux serial port driver development method based on the blocking receiving mechanism is optimized and improved based on the original interrupt + sleep/wake-up method, effectively solves the problems of frame loss in the blocking serial port driver development technology, poor real-time performance in the non-blocking serial port driver development technology and the like, and improves the stability and real-time performance of serial port communication.
Drawings
FIG. 1 is a flow chart of a Linux serial port driver blocking mechanism;
FIG. 2 is a flow chart of Linux serial driver interrupt reception.
In the figure:
app _ Rx _ count is the data length received by the application layer read function reading serial port;
rx _ count is the length of data currently received by the serial port driver;
fifo _ in is the starting offset address before the ring buffer receives data;
fif0_ out is the ending offset address of the ring buffer receiving a certain data length;
fifo _ size is the ring buffer size;
ev _ press is an interrupt flag bit;
rx _ queue is the receive wait queue.
Detailed Description
The present invention will be described in further detail below with reference to the accompanying drawings so that the aspects of the present invention described herein can be more readily understood.
As shown in fig. 1-2, the present invention discloses an embedded Linux serial driver development method based on a blocking receiving mechanism, which is implemented by the following steps.
Step one, a Linux serial port driver adopts a character type equipment framework design, namely:
1) defining a structure file _ operationmyuart _ fos, and adding open, read, write, close and ioctl functions to the structure;
2) defining a device name and registering the device with a kernel;
3) defining a serial port register, mapping a virtual address, and configuring the register and pins;
4) declaring a serial port sleep waiting queue, initializing in an open function, applying for a serial port receiving interrupt number in the open function, initializing serial port configuration, initializing the sleep waiting queue and enabling to receive interrupt;
5) writing a write function: judging whether the current sending buffer area is empty, writing data to be sent into the sending buffer area, and sending the data; and the steps are circulated until the specified transmission data length TX _ count is transmitted.
Step two, designing a receiving data buffer area as shown in fig. 1, namely:
1) defining a buffer structure body Rx _ fifo, wherein the buffer structure body Rx _ fifo comprises the following components: buffer length fifo _ size, buffer start offset address fifo _ in, buffer end offset address fifo _ out.
2) Designing a receiving buffer area annular storage mode:
when (fifo _ size-fifo _ out) is greater than or equal to app _ Rx _ count, it is indicated that the remaining buffer space can buffer the data of the app _ Rx _ count length, fifo _ out is initialized to fifo _ in, the serial port interrupt is always in a receiving state, once there is data, the data is put into the buffer, and the next judgment is performed;
when (fifo _ size-fifo _ out) < app _ Rx _ count or fifo _ size equals fifo _ out, indicating that the receiving buffer is not enough to buffer data of the length of app _ Rx _ count or the receiving buffer is full, fifo _ in is 0 and fifo _ out is fifo _ in, the buffer returns to the starting state, thus forming a buffer loop-back storage mechanism.
By designing the annular storage area, the read function cache of the drive layer is convenient to read and interrupt the received data of the function, and the annular storage mechanism ensures the repeated utilization of the storage space and the non-loss of the stored data.
Step three, designing a read function blocking reading mechanism as shown in fig. 1, namely:
1) the Linux serial driver receives data in real time by adopting an interrupt + sleep/wake-up mechanism, as shown in fig. 2, so as to reduce the occupancy rate of the CPU. The driver layer read function adopts a blocking reading mechanism to match with the non-blocking real-time inquiry read real-time calling of the application layer so as to improve the real-time performance of serial port receiving.
2) After the ring buffer is set, the drive layer interrupt function puts each byte of data received into the Rx _ fifo buffer. Because the application layer read function calls the driver layer read function in real time all the time, the driver layer read function adopts the following blocking mechanism and data packet real-time processing mechanism:
①, firstly, it is determined that when Rx _ count is greater than or equal to app _ Rx _ count, that is, the length of the data currently received by the serial port is greater than or equal to the length of the data to be read by the application layer, the data in the buffer area is directly read, thus effectively avoiding the time sequence conflict that the drive layer read function is interrupted and awakened only after being dormant to read the uploaded data and interrupt the received data.
② when Rx _ count < app _ Rx _ count, that is, the data length currently received by the serial port is smaller than the data length to be read by the application layer, the read process will be dormant, which greatly reduces the utilization rate of the CPU.
Step four, designing a real-time processing mechanism of the data packet, as shown in fig. 1, namely:
the invention analyzes the data packet and places the data packet in the driver layer but not in the application layer, and mainly aims to improve the real-time property of the application layer for calling data to the kernel. After reading the data received by the cache region, the drive layer read analyzes the data packet (such as judging a frame head, a frame tail, verification and the like), if the data is correct, the analyzed data is transmitted to the application layer read function through a copy _ to _ user function, if the data is incorrect, the drive layer write function is called to send the previous command information again, the read function analyzes the received data again, and if the data is still incorrect, the read function sends the receiving error information to the application layer. The data is analyzed twice by the driving layer, so that the communication accuracy of the data is improved, the phenomenon that an application layer read function calls a kernel layer read function for many times is avoided, and the real-time performance of data communication is improved.
Claims (1)
1. An embedded Linux serial port driver development method based on a blocking receiving mechanism is characterized by comprising the following steps:
step one, designing a Linux serial port driver by adopting a character type equipment framework;
the first step is specifically as follows:
1) defining a structure file _ operations my _ fos, and adding open, read, write, close and ioctl functions to the structure;
2) defining a device name and registering the device with a kernel;
3) defining a serial port register, mapping a virtual address, and configuring the register and pins;
4) declaring a serial port sleep waiting queue, initializing in an open function, applying for a serial port to receive an interrupt number in the open function, initializing serial port configuration, and initializing the sleep waiting queue to enable the sleep waiting queue to receive interrupt;
5) writing a write function: judging whether the current sending buffer area is empty, writing data to be sent into the sending buffer area, and sending the data; the steps are circulated until the specified sending data length TX _ count is sent;
designing a receiving data cache region;
the second step is specifically as follows:
1) defining a buffer structure body Rx _ fifo, wherein the buffer structure body Rx _ fifo comprises the following components: buffer length fifo _ size, buffer start offset address fifo _ in, buffer end offset address fifo _ out; fifo _ out-fifo _ in is Rx _ count which is the length of data currently received by the serial port driver;
2) designing a receiving buffer area annular storage mode:
when (fifo _ size-fifo _ out) is greater than or equal to app _ Rx _ count, it is indicated that the remaining buffer space can buffer the data of the app _ Rx _ count length, fifo _ out is initialized to fifo _ in, the serial port interrupt is always in a receiving state, once there is data, the data is put into the buffer, and the next judgment is performed;
when (fifo _ size-fifo _ out) < app _ Rx _ count or fifo _ size equals fifo _ out, indicating that the receiving buffer is not enough to buffer the data of the length of app _ Rx _ count or the receiving buffer is full, making fifo _ in equal to 0 and fifo _ out equal to fifo _ in, the buffer returns to the starting state, thus forming a buffer loop-back storage mechanism;
designing a read function blocking reading mechanism;
the third step is specifically as follows:
1) the Linux serial port driver receives data in real time by adopting an interrupt + dormancy/awakening mechanism, and the driver layer read function adopts a blocking reading mechanism to match with the real-time calling of non-blocking real-time inquiry read reading of an application layer;
2) after the annular cache region is set, the drive layer interrupt function is put into the Rx _ fifo cache region after receiving one byte of data; the driver layer read function adopts the following blocking mechanism and data packet real-time processing mechanism:
①, firstly, judging whether Rx _ count is larger than or equal to app _ Rx _ count, namely, the length of data currently received by the serial port is larger than or equal to the length of data to be read by the application layer, and directly reading the data in the cache region, thereby effectively avoiding the time sequence conflict that the drive layer read function can read the uploaded data and interrupt the received data only after being interrupted and awakened after being dormant;
②, when Rx _ count is less than app _ Rx _ count, that is, the data length currently received by the serial port is less than the data length to be read by the application layer, the read process is allowed to sleep, at this time, the read function has no data reading and uploading, and the step ① is executed only when Rx _ count is more than or equal to app _ Rx _ count;
designing a real-time processing mechanism of the data packet;
the fourth step is specifically as follows: and after reading the data received by the cache region, the drive layer read analyzes the data packet, if the data is correct, the analyzed data is transmitted to an application layer read function through a copy _ to _ user function, if the data is incorrect, the drive layer write function is called to repeat the second step and the third step again, the data is analyzed and received again through the read function, and if the data is still incorrect, the read function sends receiving error information to the application layer.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710342129.4A CN107168710B (en) | 2017-05-16 | 2017-05-16 | Embedded Linux serial port driver development method based on blocking receiving mechanism |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710342129.4A CN107168710B (en) | 2017-05-16 | 2017-05-16 | Embedded Linux serial port driver development method based on blocking receiving mechanism |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107168710A CN107168710A (en) | 2017-09-15 |
| CN107168710B true CN107168710B (en) | 2020-06-26 |
Family
ID=59815113
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710342129.4A Active CN107168710B (en) | 2017-05-16 | 2017-05-16 | Embedded Linux serial port driver development method based on blocking receiving mechanism |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107168710B (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112231265B (en) * | 2020-10-14 | 2022-09-13 | 天津津航计算技术研究所 | High-speed data transmission method for serial device under embedded operating system |
| CN114860640B (en) * | 2022-04-07 | 2023-06-06 | 湖南艾科诺维科技有限公司 | FlexSPI interface driving method and system for FPGA and ARM communication |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7376435B2 (en) * | 2002-04-01 | 2008-05-20 | Intel Corporation | Transferring multiple data units over a wireless communication link |
| CN103455460B (en) * | 2012-06-01 | 2017-11-14 | 广东新岸线计算机系统芯片有限公司 | A kind of device for verifying Advanced Microcontroller Bus interface |
| CN104754257B (en) * | 2015-04-14 | 2017-08-25 | 吉林大学 | Character adder and stacking method for video tracking |
-
2017
- 2017-05-16 CN CN201710342129.4A patent/CN107168710B/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN107168710A (en) | 2017-09-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11176068B2 (en) | Methods and apparatus for synchronizing uplink and downlink transactions on an inter-device communication link | |
| JP4554863B2 (en) | Network adapter and communication method with reduced hardware | |
| CN106155960B (en) | It is shaken hands the UART serial port communication method with EDMA based on GPIO | |
| US20160103743A1 (en) | Methods and apparatus for recovering errors with an inter-processor communication link between independently operable processors | |
| US5721955A (en) | System for transferring portion of data to host from buffer if size of packet is greater than first threshold value but less than second threshold value | |
| CN107168710B (en) | Embedded Linux serial port driver development method based on blocking receiving mechanism | |
| CN113518044B (en) | EPA equipment | |
| CN113419780B (en) | DPDK driving system based on FPGA acceleration card | |
| CN106533621B (en) | The means of communication of permanent magnet synchronous motor real time monitoring based on simplified MODBUS agreement | |
| US7610415B2 (en) | System and method for processing data streams | |
| CN103838694B (en) | FPGA high-speed USB interface data reading method | |
| CN115904259B (en) | Processing method and related device of nonvolatile memory standard NVMe instruction | |
| CN117472815A (en) | Storage module conversion interface under AXI protocol and conversion method thereof | |
| CN116414767A (en) | Reordering method and system for AXI protocol-based out-of-order response | |
| CN107846328B (en) | Network rate real-time statistical method based on concurrent lock-free ring queue | |
| CN116301627A (en) | NVMe controller and initialization and data read-write method thereof | |
| CN116074406A (en) | Instruction sending method and device | |
| CN115955441A (en) | Management scheduling method and device based on TSN queue | |
| US11334402B2 (en) | SDIO chip-to-chip interconnect protocol extension for slow devices and power savings | |
| US20210109887A1 (en) | I3c pending read with retransmission | |
| CN114610467A (en) | Multitask timeout management method and system | |
| US7500239B2 (en) | Packet processing system | |
| US11507491B2 (en) | System for controlling data flow between multiple processors | |
| WO2024001332A1 (en) | Multi-port memory, and reading and writing method and apparatus for multi-port memory | |
| CN117609134A (en) | SWIM protocol analysis method and system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| CB02 | Change of applicant information | ||
| CB02 | Change of applicant information |
Address after: 030032 No.1 rainbow Street, industrial park, Tanghuai Park, Taiyuan comprehensive reform demonstration zone, Taiyuan City, Shanxi Province Applicant after: CETC Pengyue Electronic Technology Co., Ltd Applicant after: TAIYUAN TRACK TRAFFIC DEVELOPMENT Co.,Ltd. Address before: 030012 No. 1, rainbow Street, industrial park, Taiyuan Economic Development Zone, Shanxi, China Applicant before: TAIYUAN PENGYUE ELECTRONIC TECHNOLOGY Co.,Ltd. Applicant before: TAIYUAN TRACK TRAFFIC DEVELOPMENT Co.,Ltd. |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant |