JP4038574B2 - Data transmission / reception processing program - Google Patents

Description

The present invention includes a first data processing unit, a buffer unit, and a second data processing unit. When data is received, data flows in the order of the first data processing unit, the buffer unit, and the second data processing unit. The present invention relates to a data transmission / reception processing program suitably used in a real-time communication apparatus configured to flow data in the order of a first data processing unit, a buffer unit, and a second data processing unit during data transmission.

  A communication method used on the Internet is called a connection type, and data is exchanged after establishing a communication session when performing communication. Such connection-type communication is a synchronous type in which communication is performed after waiting for a response from a communication partner, and is referred to as non-real-time communication. In non-real-time communication, it is difficult to predict the communication time.

  On the other hand, there is what is called real-time communication. In this communication method, communication processing is performed immediately, and data communication is completed within a requested time limit.

Thus, there is a real-time communication and non-real-time communication, if an attempt is made to real-time communication using an Ethernet ^TM which is used in an existing network environment Internet, has the following problems.

  FIG. 6 is a conceptual diagram illustrating a configuration of a communication apparatus according to the related art. The buffer unit 100 is configured by a FIFO buffer (first-in first-out buffer). If no data stays in the buffer unit 100, real-time data (data processed by real-time communication) is processed without delay, so that data communication can be completed within the requested time limit. However, the following problems occur when real-time communication and non-real-time communication are performed at the same timing.

  First, the operation during data reception will be described with reference to FIG. The first data processing unit 101 receives real-time data (data processed by real-time communication) and non-real-time data (data processed by non-real-time communication) in a mixed state. Real time data is indicated by “a” and “b”, and non-real time data is indicated by “1” and “2”. These data are once stored in the buffer unit 100 and then output to the upper level by the second data processing unit 102. In this case, since real-time data has non-real-time data that precedes the real-time data, processing of the real-time data is delayed.

  Next, the operation at the time of data reception will be described with reference to FIG. Real time data is indicated by “c” and “d”, and non-real time data is indicated by “3” and “4”. Although the data flow is the reverse of the case of FIG. 6 (a), the real time data is output to the communication line late because of the preceding non-real time data, as in the case of data transmission. It is.

The present invention has been made in view of the above circumstances, and its problem is to prevent delay in data communication by real-time communication in an environment where both non-real-time communication and real-time communication can be performed. The present invention is to provide a data transmission / reception processing program suitably used for a real-time communication apparatus capable of performing the above.

<Real-time communication device>
In order to solve the above problems, a real-time communication device according to the present invention provides:
It has a first data processing unit, a buffer unit, and a second data processing unit. When data is received, data flows in the order of the first data processing unit, the buffer unit, and the second data processing unit. Is a real-time communication device configured such that data flows in the order of the second data processing unit, the buffer unit, and the first data processing unit,
The buffer part
A first buffer that accepts real-time data for real-time communication;
A second buffer for accepting non-real time data for non-real time communication;
The first data processor and the second data processor are
Means for detecting whether the data is real-time data or non-real-time data;
Means for distributing data to either the first buffer or the second buffer according to the type of data detected;
And means for performing processing for sending the real-time data with priority over the non-real-time data when sending the data received from the buffer unit.

  The operation and effect of the real-time communication apparatus with this configuration is as follows. This communication apparatus includes a first buffer and a second buffer as buffer units, the first buffer can accept real-time data for real-time communication, and the second buffer is non-real-time for non-real-time communication. Can accept data. The first data processing unit and the second data processing unit perform the following processing according to the data type.

  First, when receiving data, the first data processing unit detects whether the data to be received is real-time data or non-real-time data. If it is real-time data, it is put in the first buffer, and if it is non-real-time data, it is put in the second buffer. The second data processing unit performs processing for preferentially sending real-time data over non-real-time data. As a result, the real-time data is sent out first. At the time of data transmission, it is the reverse of the above, and the second data processing unit detects whether the received data is real-time data or non-real-time data, and based on this detection result, the data is stored in the first buffer or the second data. Put it in the buffer. The first data processing unit performs processing for preferentially transmitting real-time data over non-real-time data. As a result, the real-time data is sent out first. That is, real-time data processing can be performed so that real-time data processing is not delayed by preceding non-real-time data. As a result, it is possible to provide a real-time communication apparatus that can prevent delay in data communication by real-time communication in an environment where both non-real-time communication and real-time communication can be performed.

  It is preferable that a field representing the data type is provided in the frame of data for real-time communication according to the present invention.

  The first data processing unit and the second data processing unit can detect whether the data is real-time data or non-real-time data based on the type of the data.

<Data transmission / reception processing program>
The data transmission / reception processing program according to the present invention is suitable for the real-time communication apparatus according to the present invention,
When the application calls the kernel with a send system call,
The called kernel calls the interrupt handler,
This interrupt handler takes out the frame from the buffer part,
After this processing, the computer causes the computer to execute processing for calling a transmission routine.

  In the data transmission / reception processing according to the prior art, at the time of data transmission, the application calls the kernel with a transmission system call, and the kernel calls the transmission routine of the device driver. Then, when trying to put data into the buffer, if the buffer is full, an interrupt handler is called to perform processing so as to take out the data frame from the buffer. However, in such a processing procedure, there is a problem that the execution cycle of the application program becomes long when the call of the transmission system call by the application is shorter than the execution cycle of the interrupt handler.

  In other words, when an interrupt handler is called, data cannot be stored in the buffer until the interrupt handler is executed. Therefore, there is a problem that data transmission is delayed accordingly.

  On the other hand, in the data transmission / reception processing according to the present invention, the kernel is called by the transmission system call, and the kernel calls the interrupt handler. The interrupt handler takes out the frame from the buffer unit. After fetching this frame, the kernel calls the send routine. At this time, since the frame has already been extracted from the buffer unit, the buffer unit is not full. Therefore, the data can be reliably put into the buffer unit by the transmission routine. As a result, data transmission is not delayed.

The data transmission / reception processing program according to the present invention is suitable for the real-time communication apparatus according to the present invention,
When the application calls the kernel in the kernel with a receive system call,
The called kernel calls the interrupt handler,
This interrupt handler takes out the received frame from the buffer part,
After this process, the computer causes the computer to execute a process of calling the reception routine.

  In the data transmission / reception processing according to the prior art, at the time of data reception, an application calls the kernel with a reception system call, and the kernel calls a reception routine of the device driver. If the frame has not been received from the buffer, the interrupt handler is called to perform processing so as to extract the data frame from the buffer. However, in such a processing procedure, there is a problem that the execution cycle of the application program becomes long as in the previous data transmission.

  On the other hand, in the data transmission / reception processing according to the present invention, the kernel is called by the transmission system call, and the kernel calls the interrupt handler. The interrupt handler takes out the frame from the buffer unit. After fetching this frame, the kernel calls the receive routine. At this time, since the uppermost frame has already been extracted from the buffer unit, the buffer unit is not full. Therefore, the data can be reliably put into the buffer unit by the reception routine. As a result, data reception is not delayed.

  The data transmission / reception processing program according to the present invention is suitable for real-time communication, but can also be applied to non-real-time communication.

  A preferred embodiment of a real-time communication apparatus according to the present invention will be described with reference to the drawings. FIG. 1 is a conceptual diagram showing a configuration of a real-time communication apparatus.

<Real-time communication device (hardware configuration)>
The real-time communication apparatus according to the present invention is an apparatus that can be used not only for real-time communication but also for non-real-time communication. In particular, real-time communication is attempted using the Ethernet environment used on the Internet. As already described, since the Internet uses a connection-type communication format, communication cannot be completed within a desired time. In other words, communication in the Internet environment is non-real-time communication, and when real-time communication is attempted using this system, a mechanism for preventing a delay in communication processing time is required.

  In FIG. 1, (a) shows the operation at the time of data reception, and (b) shows the operation at the time of data transmission. As the buffer unit 1, a first FIFO (first-in first-out) buffer 11 and a second FIFO buffer 12 are provided. The first FIFO buffer 11 is a buffer in which real-time data (data when performing real-time communication) is taken in and out, and the second FIFO buffer 12 is provided with non-real-time data (data when performing non-real-time communication). It is a buffer. The real-time data frames are indicated by “a”, “b”, “c”, and “d”, and the non-real-time data frames are indicated by “1”, “2”, “3”, and “4”. FIG. 1 shows a state where real-time communication and non-real-time communication are performed at the same timing. Of course, the form of communication actually performed is not limited to this, and naturally there may be a state in which only real-time communication is performed and a state in which only non-real-time communication is performed.

  First, the operation at the time of data reception will be described with reference to FIG. The first data processing unit 2 has a function (means) for detecting whether data to be received is real-time data or non-real-time data. A data frame configuration for this purpose is shown in FIG.

  FIG. 2 shows each field configuration in the frame. The field is composed of “preamble”, “start frame delimiter”, “destination address”, “source address”, “type”, “data area”, and “frame check”. Note that this field configuration shows an example, and the present invention is not limited to this. Based on the field named “type” among the above, it is possible to determine whether the data is real-time data or non-real-time data. If the data type is real-time data, the first data processing unit 2 puts this in the first buffer 11. If the data type is non-real time data, it is put into the second buffer 12. Thus, based on the function of the 1st data processing part 2, data can be distributed to either.

  The second data processing unit 3 has a function (means) for preferentially raising the real-time data among the data received from the buffer unit 1 to the higher rank (application). That is, in the example of FIG. 1A, the real time data and the non-real time data frames are input in the order of “1”, “b”, “2”, and “a”, but the data is output to the upper level. When sent, they are sent in the order of “b” “a” “1” “2”. As a result, the communication time of real-time communication is not delayed by affecting the processing time of non-real time data.

  Next, the operation during data transmission will be described with reference to FIG. The second data processing unit 3 has a function (means) for detecting whether data to be transmitted is real-time data or non-real-time data when a data transmission request is issued from the upper level. .

  Similarly to the above, if the data type is real-time data, the second data processing unit 3 puts this in the first buffer 11. If the data type is non-real time data, it is put into the second buffer 12. Thus, based on the function of the 2nd data processing part 3, data can be distributed to either.

  The first data processing unit 2 has a function (means) for preferentially outputting real time data to the communication line among the data received from the buffer unit 1. That is, in the example of FIG. 1B, the real time data and the non-real time data frames are input in the order of “4”, “3”, “c”, and “d”, but the data is transmitted to the communication line. When output, they are sent in the order of “c” “d” “4” “3”. As a result, the communication time of real-time communication is not delayed by affecting the processing time of non-real time data.

<Data transmission / reception processing program>
Next, software processing that can perform data transmission and reception quickly will be described. FIG. 4 is a flowchart showing a procedure of data transmission / reception processing according to the prior art. (A) shows a procedure at the time of data transmission, and (b) shows a procedure at the time of data reception.

<Processing procedure in the prior art>
First, a processing procedure at the time of transmission will be described. This example is a transmission procedure by Ethernet in ART-Linux. When trying to send data, the application program calls the kernel with a send system call (# 21). The system call refers to calling and using a function provided in an OS (operating system), and here, a system call for performing data transmission is performed. The kernel refers to the most basic part of the OS.

  Next, the called kernel calls the transmission routine of the Ethernet device driver (# 22). In order to transmit data, since it is necessary to temporarily store data (frames) in the FIFO buffer, it is determined whether or not the FIFO buffer is full (# 23). If the FIFO buffer is not full, a frame can be inserted, so that the process can proceed to step # 25. However, if it is full, an interrupt handler (a small program code executed when an interrupt occurs). ) Until the interruption process is completed (# 24). With this interrupt handler, the first frame is taken out from the FIFO buffer, and an empty space is generated in the FIFO buffer. As a result, the Ethernet device driver can put a frame into the FIFO buffer (# 25). Next, when a transmission command is issued to the Ethernet control device, the control device transmits the frame previously extracted from the FIFO buffer to the communication line (# 26).

  Next, a processing procedure at the time of data reception will be described. Similarly, the application program calls the kernel by the reception system call (# 31). The called kernel calls the reception routine of the device driver (# 32). If the frame has already been received (# 33), the process proceeds to step # 35. If not, the process waits for completion of the interrupt processing by the interrupt handler (# 34). That is, the frame is taken out from the FIFO buffer by the interrupt handler. This creates a space in the FIFO buffer. This frame is output to the upper application by the data processing unit (# 35).

  In the case of such a processing procedure, the following problem occurs. That is, in ART-Linux, an interrupt handler is executed periodically, but if the calling cycle of a transmission system call or a receiving system call by an application program is shorter than the execution cycle of the interrupt handler, the application program There arises a problem that the execution cycle becomes long.

  That is, at the time of data transmission, if a frame is not extracted from the FIFO buffer by the interrupt handler, the frame remains in the FIFO buffer, resulting in overflow. Accordingly, since a new data frame cannot be entered in the FIFO buffer, the execution of the application is suspended until the FIFO buffer becomes free. As a result, the execution cycle of the application program is extended to the execution cycle of the interrupt handler. As a result, the processing time required for data transmission is also delayed.

  On the other hand, at the time of data reception, if the frame is not taken out from the FIFO buffer by the interrupt handler, the frame is not sent to the upper level, and the data cannot be put into the FIFO buffer. Therefore, the subsequent processing is delayed, and the processing time required for data reception is also delayed.

<Processing procedure in the present invention>
Next, the processing procedure in the present invention will be described with reference to the flowchart of FIG. This example also shows a transmission / reception procedure by Ethernet in ART-Linux (Linux) as before. However, the present invention is not limited to this. (A) is a flowchart at the time of transmission, and (b) is a flowchart at the time of reception.

  First, a processing procedure at the time of transmission will be described. The application program calls the kernel with a transmission system call (# 1). This kernel calls the interrupt handler (# 2). By this interrupt handler, the frame is taken out from the FIFO buffer and returned. This creates a space in the FIFO buffer. Next, the kernel calls the transmission routine of the Ethernet device driver (# 3). Next, the device driver puts a new frame into the FIFO buffer (# 5).

  Incidentally, there is a process for determining whether or not the FIFO buffer is full in step # 4. However, since the interrupt handler has already been executed in step # 2 (frame extraction has been completed), the FIFO buffer is full. There is nothing (# 8). Therefore, a new frame is immediately inserted into the FIFO buffer. This is shown as a function of the second data processing unit 3 in FIG. Next, a transmission command is issued to the Ethernet control device, and a frame is transmitted to the serial communication line (# 6). FIG. 1B shows the function of the first data processing unit 2.

  Next, a processing procedure at the time of reception will be described. The application program calls the kernel by the receiving system call (# 11). This kernel calls the interrupt handler (# 12). The interrupt handler fetches the frame from the FIFO buffer and returns. This creates a space in the FIFO buffer. Next, the kernel calls the reception routine of the Ethernet device driver (# 13). Next, the received new frame is put into the FIFO buffer. This is shown as a function of the first data processing unit 2 in FIG. Next, the frame taken out from the FIFO buffer is sent to the upper level (# 15). This is shown as a function of the second data processing unit 3.

  By the way, it is the same as before that it is not judged No in step # 14. Therefore, the determination process for step # 4 and step # 14 can be omitted. However, since it is preferable not to change the source code in order to maintain the compatibility of the existing software, it is preferable to leave the determination processing for step # 4 and step # 14 as the configuration of the present invention.

<Timing chart>
FIG. 5 is a timing chart showing the relationship between the application execution cycle and the interrupt handler execution cycle. FIG. 5A shows the prior art and FIG. 5B shows the present invention. Note that the same manner is used at the time of transmission and at the time of reception. Application execution is indicated by A, and interrupt handler execution is indicated by I.

  In the prior art, the application execution cycle is 500 μs, and the interrupt handler execution cycle is 1 ms. In other words, the interrupt handler execution cycle is longer. In this case, it can be seen that there is a wasteful waiting time for executing the application in accordance with the execution cycle of the interrupt handler. In other words, an application execution cycle of 500 μs cannot be realized in practice. Therefore, the data processing time is also increased, and as a result, the time required for data transmission / reception is also increased.

  On the other hand, according to the present invention, both the interrupt handler execution cycle and the application execution cycle are set to 500 μs. Therefore, no unnecessary waiting time occurs as shown in FIG. An application execution cycle of 500 μs can be reliably realized.

  Note that execution of a program by an application includes, for example, various processes such as processing of received data and creation of data to be transmitted, in addition to processing for calling a kernel by a system call.

The conceptual diagram which shows the structure of the real-time communication apparatus which concerns on this invention Diagram showing field structure of data frame The flowchart which shows the procedure of the data transmission / reception process based on this invention The flowchart which shows the procedure of the data transmission / reception process based on a prior art Diagram showing program execution mode Conceptual diagram showing the configuration of a communication device according to the prior art

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Buffer part 2 1st data processing part 3 2nd data processing part 11 1st buffer 12 2nd buffer

Claims (3)

It has a first data processing unit, a buffer unit, and a second data processing unit. When data is received, data flows in the order of the first data processing unit, the buffer unit, and the second data processing unit. Is a real-time communication device configured such that data flows in the order of the second data processing unit, the buffer unit, and the first data processing unit,
The buffer part
A first buffer that accepts real-time data for real-time communication;
A second buffer for accepting non-real time data for non-real time communication;
The first data processor and the second data processor are
Means for detecting whether the data is real-time data or non-real-time data;
Means for distributing data to either the first buffer or the second buffer according to the type of data detected;
A data transmission / reception processing program executed using a real-time communication device having means for sending real-time data in preference to non-real-time data when sending data received from the buffer unit. And
When the application calls the kernel with a send system call,
The called kernel calls the interrupt handler,
This interrupt handler takes out the frame from the buffer part,
A data transmission / reception processing program for causing a computer to execute a process in which a kernel calls a transmission routine after this process. It has a first data processing unit, a buffer unit, and a second data processing unit. When data is received, data flows in the order of the first data processing unit, the buffer unit, and the second data processing unit. Is a real-time communication device configured such that data flows in the order of the second data processing unit, the buffer unit, and the first data processing unit,
The buffer part
A first buffer that accepts real-time data for real-time communication;
A second buffer for accepting non-real time data for non-real time communication;
The first data processor and the second data processor are
Means for detecting whether the data is real-time data or non-real-time data;
Means for distributing data to either the first buffer or the second buffer according to the type of data detected;
A data transmission / reception processing program executed using a real-time communication device having means for sending real-time data in preference to non-real-time data when sending data received from the buffer unit. And
When the application calls the kernel in the kernel with a receive system call,
The called kernel calls the interrupt handler,
This interrupt handler takes out the frame from the buffer part,
A data transmission / reception processing program for causing a computer to execute a process in which a kernel calls a reception routine after this process. When sending data,
When the application calls the kernel with a send system call,
The called kernel calls the interrupt handler,
This interrupt handler takes out the frame from the buffer part,
After this processing, the kernel calls the send routine,
When receiving data,
When the application calls the kernel in the kernel with a receive system call,
The called kernel calls the interrupt handler,
This interrupt handler takes out the frame from the buffer part,
A data transmission / reception processing program for causing a computer to execute a process in which a kernel calls a reception routine after this process.

Images