CN102780705B - Ethernet-(controller area network) CAN protocol converter - Google Patents

Abstract

The invention discloses an Ethernet-(controller area network) CAN protocol converter which is composed of a microcontroller (1), a peripheral circuit (2), a CAN module (3) and an Ethernet module (4). The microcontroller (1) is connected with the peripheral circuit (2), the CAN module (3) and the Ethernet module (4) respectively. The Ethernet-CAN protocol converter can achieve the conversion from CAN protocol data to Ethernet frames and from Ethernet frames to CAN protocol data. The Ethernet-CAN protocol converter solves the mutual conversion problem of two formats of data of CAN protocol data and Ethernet frames. Directed at problems that short frames waste bandwidth and is prone to cause network congestion and the like, the Ethernet-CAN protocol converter achieves Nagle algorithm in a transmission control protocol (TCP), reduces the number of short frames greatly, and saves the bandwidth.

Description

Ethernet-CAN Protocol Converter

technical field

The invention relates to the field of industrial control, in particular to a protocol converter for realizing mutual communication between industrial Ethernet and CAN bus based on TCP/IP technology.

Background technique

Ethernet technology entered the field of industrial control in the early 1990s, and has achieved considerable development due to its high openness, good compatibility, and flexible expansion. Fieldbus technology has strong real-time performance and high reliability, but it fails to realize cross-regional network connection. Therefore, the combination mode of Ethernet-Fieldbus has become the focus of industrial control development.

CAN bus is a typical representative of today's field bus.

TCP/IP technology has good practicability and development, and Ethernet based on TCP/IP technology has been widely used in industrial communication.

There are a large number of short-frame datagrams (1-4 bytes) in industrial sites, which makes the bandwidth utilization rate extremely low and the possibility of congestion also increases. As the standard of TCP congestion control, the Nagle algorithm can well solve the problem of short frame flooding, but when the Nagle algorithm of the lower computer interacts with the delayed acknowledgment policy (Delayed Ack) of the upper computer, it is easy to generate temporary "deadlock" ("deadlock"). ”) phenomenon, resulting in data not being transmitted in real time. For the temporary "deadlock" phenomenon, there are generally two solutions: one is to turn off the Nagle algorithm, but at the expense of bandwidth; the other is to use the improved Nagle algorithm, which is relatively complicated and difficult to implement And the versatility is not strong.

Contents of the invention

In order to solve the above-mentioned technical problems in the prior art, the present invention provides an Ethernet-CAN protocol converter with small size, simple and firm structure, low cost, high reliability, and can meet the real-time requirements of industrial control.

Described Ethernet-CAN protocol converter is made up of microcontroller, peripheral circuit, CAN module and Ethernet module, and described microcontroller is connected with peripheral circuit, CAN module and Ethernet module respectively, and described CAN module is composed of CAN transceiver and CAN interface, the Ethernet module is composed of an Ethernet PHY transceiver and an RJ45 socket with an integrated network isolation transformer, and the Ethernet-CAN protocol converter can realize the conversion from CAN protocol data to Ethernet frames, and from Ethernet frames to CAN Conversion of protocol data.

Further, the Ethernet-CAN protocol converter is embedded with a TCP/IP protocol stack to implement TCP, IP, ARP, and ICMP protocols.

Further, a custom protocol is used in its application layer, and the data format of the custom protocol includes: a Flag field representing data flow direction, a CAN_ID field representing a CAN node ID, and a CAN_DATA field representing data.

Further, the Nagle algorithm is used in the TCP protocol. The workflow is: the TCP sender receives the data generated by the application layer. If two conditions are met at this time: the confirmation of the last data packet is received or the TCP data length has reached the maximum message Segment length (MSS), send TCP data immediately; otherwise, block the data received by TCP until the above two conditions are triggered.

Further, according to different real-time requirements and data types of the data signals, the data signals are divided into three priorities: high, medium, and low.

Furthermore, a priority processing mechanism is adopted for application layer data, and the workflow is as follows: high priority data is processed by filling the buffer, that is, if TCP receives high priority data generated by the application layer, it immediately fills the data into the The maximum message segment length triggers the sending data condition of the Nagle algorithm, and the data is sent immediately without waiting for the confirmation; the middle priority data is processed by increasing the sampling frequency, that is, the sampling frequency of this type of data is increased so that it is within 200ms A message equal to MSS is generated to break the "deadlock" mechanism; for low-priority data signals, that is, signals that can tolerate 200ms transmission delay, no processing is performed.

Further, the conversion process from CAN protocol data to Ethernet frame is:

① Start the CAN module to receive data;

②If the data is received, save it to the application layer buffer; if the data is not received, return to step ①;

③A priority mechanism is used to process the data in the application layer buffer;

④If the data sending condition of Nagle algorithm is met at this time, perform TCP/IP packet on the application layer buffer data and send it immediately, return to step ①; if the sending data condition of Nagle algorithm is not satisfied at this time, return to step ①.

Further, the conversion process from CAN protocol data to Ethernet frame is:

① Start the Ethernet module to receive data;

② If there is data in the receiving buffer of the Ethernet module, judge the network layer protocol type; if there is no data in the receiving buffer of the Ethernet module, return to step ①;

3. if the network layer protocol type is the ARP protocol in step 2., process the ARP message, and return to step 1; if the network layer protocol type is the IP protocol in the step 2., process the IP message;

4. determine the upper layer protocol type carried by the IP message in step 3. If it is the ICMP protocol, process the ICMP message and return to step 1; if it is the TCP protocol, process the TCP message and return to step 1;

⑤If the TCP message in step ④ carries CAN data, send the CAN data and return to step ①; otherwise, return to step ① directly.

The effect brought by the present invention is: realize mutual conversion between TCP/IP protocol and CAN protocol, and realize mutual communication between Ethernet and CAN bus. For a large number of short-frame datagrams, the Nagle algorithm is implemented in the TCP protocol, which greatly reduces the number of short-frame data packets, saves network bandwidth, and reduces the possibility of network congestion. For signals with high real-time requirements, without modifying the Nagle algorithm, the measures of filling the buffer or increasing the sampling frequency are adopted to eliminate the temporary "deadlock" phenomenon and ensure the real-time performance of data transmission.

Description of drawings

Figure 1 is a schematic diagram of the implementation of the Ethernet-CAN protocol converter

Figure 2 is a block diagram of the Ethernet-CAN protocol converter

Figure 3 is a diagram of the data processing process of the Ethernet-CAN protocol converter

Figure 4 is the protocol flow chart of the Ethernet-CAN protocol converter

Figure 5 is the application layer custom protocol data format

Figure 6 is the workflow diagram of Nagle algorithm

Figure 7 is a diagram of the interaction between the Nagle algorithm and the delayed confirmation strategy

Figure 8 is a distribution diagram of RTT with a sampling frequency of 1 byte/ms

Figure 9 is the distribution diagram of RTT with a sampling frequency of 10 bytes/ms

Figure 10 is a flowchart of the priority working mechanism

Figure 11 is the working flow chart of the Ethernet-CAN protocol converter

Detailed ways

The present invention will be further described below in conjunction with accompanying drawing.

As shown in Figure 1, Figure 1 is a schematic diagram of the implementation of the Ethernet-CAN protocol converter. The Ethernet-CAN protocol converter of the present invention is used as a bridge between the CAN bus and the Ethernet to realize mutual communication between the CAN bus and the Ethernet.

Figure 2 is a block diagram of the Ethernet-CAN protocol converter. The Ethernet-CAN protocol converter is composed of a microcontroller 1, a peripheral circuit 2, a CAN module 3 and an Ethernet module 4 in terms of hardware design. The CAN module 3 is composed of a CAN transceiver and a CAN interface. The Ethernet module 4 is composed of an Ethernet PHY transceiver and an RJ45 socket integrating a network isolation transformer.

The microcontroller 1 is the core of the Ethernet-CAN protocol converter, and is connected with the peripheral circuit 2, the CAN module 3 and the Ethernet module 4 respectively, so as to realize the mutual exchange between CAN protocol data and Ethernet frame data. transform. The present invention selects the ARM7 series chip LPC2368 produced by Philips as the microcontroller 1 .

The peripheral circuit 2 is the minimum system circuit of the microcontroller 1, including a clock circuit, a reset circuit, a power supply circuit and a JTAG interface circuit. It should be noted that the frequency of the external clock crystal oscillator used in the present invention is 11.0592 MHz, and the power supply circuit used is a 5V-3.3V DC power supply circuit.

The CAN module 3 is composed of CAN transceiver and CAN interface. The CAN transceiver sends and receives data respectively through the buses CANH and CANL, and the CAN interface provides input and output interfaces for the buses CANH and CANL. Adopt TJA1040 chip as CAN transceiver in the present invention.

The Ethernet module 4 is composed of an Ethernet PHY transceiver and an RJ45 socket integrating a network isolation transformer. The Ethernet PHY transceiver has the functions of data signal transmission and reception, Manchester encoding and decoding, and conflict detection. The present invention adopts the DM9161AEP chip as the Ethernet PHY transceiver, and selects J00-0061NL as the RJ45 socket. The socket integrates a network isolation transformer as a whole, which can restrain common mode interference, isolate lines and match impedance.

Figure 3 is a diagram of the data processing process of the Ethernet-CAN protocol converter. Direction 1->2 is the CAN data->Ethernet data conversion process: the CAN interface sends the received data signal to the physical layer of the CAN bus, and obtains the application layer data after being processed by the CAN bus physical layer and data link layer. The application layer data is processed by the Ethernet transport layer, network layer, data link layer, and physical layer in turn, and then converted into Ethernet data signals and sent out through the RJ45 socket. Direction 2->1 is Ethernet data->CAN data conversion process: the RJ45 socket sends the received data signal to the physical layer of Ethernet, and then passes through the physical layer, data link layer, network layer and transport layer of Ethernet in turn After processing, the application layer data is obtained. The application layer data is converted into CAN data signals through the data link layer and physical layer of the CAN bus in turn and sent out through the CAN interface.

Figure 4 is the protocol flowchart of the Ethernet-CAN protocol converter. The application layer protocol is a custom protocol, and Figure 5 shows the data format of the application layer custom protocol. Flag in FIG. 5 represents the data flow direction, and the length is 1 byte. 0xFF represents the direction 1->2 in FIG. 3, and 0xFE represents the direction 2->1 in FIG. 3. CAN_ID is 2 bytes in length and represents the CAN node ID. The length of CAN_DATA is not limited, generally several to dozens of bytes. Only one protocol definition method is provided here, and users can customize the application layer protocol according to actual needs, which will not be repeated here. The invention realizes TCP protocol at the transmission layer, and realizes IP, ICMP and ARP protocols at the network layer. As for the physical layer and data link layer functions of CAN bus and Ethernet, they are all realized by corresponding hardware and drivers.

Figure 6 is a flowchart of the Nagle algorithm. Since the CAN bus adopts a short-frame structure, the existence of a large number of short-frame data packets in the network will reduce the bandwidth utilization rate and increase the possibility of congestion. Therefore, the present invention implements the Nagle algorithm in the TCP protocol. The specific workflow is shown in Figure 6: The TCP sender receives the data generated by the application layer. If the confirmation of the last data packet is received at this time or the TCP data length has reached the maximum message segment length (MSS), immediately send the TCP data. Otherwise, block the data received by TCP until the above two conditions are triggered. The essence of Nagle's algorithm is the block technology. The invention embeds the Nagle algorithm in the TCP protocol, which can greatly reduce the number of short-frame data packets in the network and save network bandwidth.

Fig. 7 is a diagram of the interaction between the Nagle algorithm and the delayed confirmation strategy. In method 1, the sending end sends data1 to the receiving end, and at the same time blocks the subsequent data generated by the application layer; after receiving the data, the receiving end sets a timer of 200-500ms (typically 200ms), after timeout, The receiving end immediately generates an acknowledgment packet, and the sending end sends data2 after receiving the acknowledgment of data1. In method 2, after the sending end sends data1, before the receiving end timer times out, the sending end generates a message data2 that reaches the MSS and sends it immediately, and the receiving end immediately sends an acknowledgment after receiving two consecutive unacknowledged messages package, and delete the timer at the same time. Method 1 will generate a delay of at least 200ms during each data interaction, which is also called a temporary "deadlock" ("deadlock"). If the real-time requirements of the system are not high, at the same application layer data generation rate, the block effect of method 1 is the most ideal, because its delay time is the largest. In a system with high real-time requirements, the effect of the second method is more ideal than that of the first method. The present invention starts from the data signal type, and selects different interaction modes according to the different priorities thereof, so as to ensure the real-time requirement of the data signal.

Table 1 is a schematic diagram of data priority classification and corresponding processing methods. The present invention sets three priority types: high, medium and low.

priority Can you tolerate 0.2s delay Data signal type processing method high cannot random signal fill buffer middle cannot periodic signal Increase the sampling frequency Low able - -

Table 1

High-priority data must meet the following two conditions: ① random signal; ② transmission delay of 200ms cannot be tolerated. The present invention adopts the processing mode of filling the buffer zone for the high-priority data. That is, if TCP receives high-priority data generated by the application layer, it immediately fills the data to the maximum segment length, triggers the sending data condition of the Nagle algorithm, and sends the data immediately without waiting for the confirmation.

Medium-priority data must meet the following two conditions: ① periodic signal; ② transmission delay of 200ms cannot be tolerated. The present invention adopts a processing method of increasing the sampling frequency for the medium priority data. That is, increase the sampling frequency of this type of data so that it generates a message equal to MSS within 200ms, thereby breaking the "deadlock" mechanism. Figure 8 and Figure 9 are the RTT comparisons with sampling frequencies of 1 byte/ms and 10 bytes/ms respectively, under the condition that MSS=1460 bytes.

For low-priority data signals, signals that can tolerate 200ms transmission delay, the present invention does not process, and because the delay time is the longest at this time, the blocking effect is the best. Figure 10 is a flowchart of the priority working mechanism.

Fig. 11 is the workflow diagram of the Ethernet-CAN protocol converter. After the hardware initialization is completed, process data according to the 1->2 direction and 2->1 direction shown in Figure 3 respectively.

1->2 direction data processing process:

① Start the CAN module to receive data;

②If the data is received, save it to the application layer buffer; if the data is not received, return to step ①;

③A priority mechanism is used to process the data in the application layer buffer;

④If the data sending condition of Nagle algorithm is met at this time, perform TCP/IP packet on the application layer buffer data and send it immediately, return to step ①; if the sending data condition of Nagle algorithm is not satisfied at this time, return to step ①.

2->1 direction data processing process:

① Start the Ethernet module to receive data;

② If there is data in the Ethernet receiving buffer, judge the network layer protocol type; if there is no data in the Ethernet receiving buffer, return to step ①;

3. if the network layer protocol type is the ARP protocol in step 2., process the ARP message, and return to step 1; if the network layer protocol type is the IP protocol in the step 2., process the IP message;

4. determine the upper layer protocol type carried by the IP message in step 3. If it is the ICMP protocol, process the ICMP message and return to step 1; if it is the TCP protocol, process the TCP message and return to step 1;

⑤If the TCP message in step ④ carries CAN data, send the CAN data and return to step ①; otherwise, return to step ① directly.

What is described above and shown in the figure is only the preferred embodiment of the present invention. It should be pointed out that those skilled in the art can make some modifications and improvements without departing from the principle of the present invention, and these should also be regarded as belonging to the protection scope of the present invention.

Claims (6)

1. An Ethernet-CAN protocol converter is composed of a microcontroller (1), a peripheral circuit (2), a CAN module (3) and an Ethernet module (4), and the microcontroller (1) is connected to the peripheral circuit respectively (2), the CAN module (3) is connected to the Ethernet module (4), characterized in that: the CAN module (3) is composed of a CAN transceiver and a CAN interface, and the Ethernet module (4) is composed of an Ethernet PHY transceiver Composed of an RJ45 socket with an integrated network isolation transformer, the Ethernet-CAN protocol converter can realize the conversion from CAN protocol data to Ethernet frame, and the conversion from Ethernet frame to CAN protocol data; The conversion process from Ethernet frame to CAN protocol data is: ① Start the CAN module (3) to receive data; ②If the data is received, save it to the application layer buffer; if the data is not received, return to step ①; ③A priority mechanism is used to process the data in the application layer buffer; ④If the conditions for sending data by the Nagle algorithm are met at this time, perform TCP/IP packets on the application layer buffer data and send them immediately, and return to step ①; if the conditions for sending data by the Nagle algorithm are not satisfied at this time, return to step ①; The conversion process from the CAN protocol data to the Ethernet frame is: one. Start the Ethernet module (4) to receive data; two. If there is data in the receiving buffer of the Ethernet module (4), judge the network layer protocol type; if there is no data in the receiving buffer of the Ethernet module (4), return to step 1; three. If the network layer protocol type is the ARP protocol in step 2, process the ARP message and return to step 1; if the network layer protocol type in the step 2 is the IP protocol, process the IP message; Four. Judge the upper layer protocol type carried by the IP message in step 3, if it is the ICMP protocol, process the ICMP message, and return to step one; if it is the TCP protocol, process the TCP message, and return to step one; five. If the TCP message carries CAN data in step 4, send the CAN data and return to step 1; otherwise, return to step 1 directly. 2. Ethernet-CAN protocol converter according to claim 1, is characterized in that: described Ethernet-CAN protocol converter embeds TCP/IP protocol stack, realizes TCP, IP, ARP, ICMP agreement. 3. Ethernet-CAN protocol converter according to claim 2, is characterized in that: use self-defined agreement in its application layer, the data format of described self-defined agreement comprises: represent data flow to Flag field, represent CAN node ID A CAN_ID field and a CAN_DATA field representing data. 4. Ethernet-CAN protocol converter according to claim 2, is characterized in that: use Nagle algorithm in TCP agreement, workflow is: the data that TCP sender receives application layer to produce, if satisfy two conditions now: Receive the acknowledgment of the last data packet or the TCP data length has reached the maximum segment length (MSS), send TCP data immediately; otherwise, block the data received by TCP until the above two conditions are triggered. 5. The Ethernet-CAN protocol converter according to claim 4, characterized in that: according to the data signal, the real-time requirements and data types are different, and the data signal is divided into three priorities: high, medium and low. 6. Ethernet-CAN protocol converter according to claim 5, is characterized in that: take priority processing mechanism for application layer data, work flow is: take the processing mode of filling buffer to high priority data, promptly if TCP When receiving high-priority data generated by the application layer, immediately fill the data to the maximum segment length, trigger the sending data condition of the Nagle algorithm, and send the data immediately without waiting for the arrival of the confirmation; increase the sampling frequency for medium-priority data The processing method is to increase the sampling frequency of this type of data so that it generates a message equal to MSS within 200ms, thus breaking the "deadlock" mechanism; for low-priority data signals, that is, signals that can tolerate 200ms transmission delay, Do not deal with.