Method for interface conversion of multiple types of hardware based on ZYNQ

Abstract

The application discloses a kind of based on ZYNQ's interface conversion of multi-class hardware, including exchange module, external CAN equipment, external ETH equipment, external RS422 equipment and external LVDS equipment connected with exchange module;Exchange module includes ZYNQ chip, ZYNQ chip includes PS module and PL module, and PL module is used to carry out LVDS interface and RS422 interface data transceiving and packet;PS module is used to carry out the data transceiving, packet, data packet analysis and routing of ETH interface and CAN interface, data packet analysis and routing of LVDS interface and RS422 interface;Data interaction is carried out between PS module and PL module by AXI bus.This application judges data destination interface type and interface number and exports data by ZYNQ analysis data packet content, can realize that different electronic equipment is used different interface to carry out data interaction, in the scene that the electronic equipment needing to interact data is more, the complexity of hardware wiring is simplified.

Description

Technical Field

[0001] This invention relates to a method for interface conversion of multiple types of hardware based on ZYNQ. Background Technology

[0002] ZYNQ-based interface conversion is applied in the design of electronic devices in various industries. When two electronic devices need to interact with each other, they generally need to use the same interface for hardware interconnection. When multiple devices need to interact with each other, they generally need to use the same hardware interface for interconnection, which makes the hardware connection complex. Summary of the Invention

[0003] The purpose of this invention is to overcome the shortcomings of the prior art and provide a method for interface conversion of multiple types of hardware based on ZYNQ, which can realize data interaction between different electronic devices using different interfaces by parsing data packet content, determining the data destination interface type and interface number, and outputting the data.

[0004] The objective of this invention is achieved through the following technical solution: a method for interface conversion of multiple types of hardware based on ZYNQ, including a switching module, and external CAN devices, external ETH devices, external RS422 devices, and external LVDS devices connected to the switching module; the switching module includes a ZYNQ chip and a DDR3 chip for program execution and a QSPI FLASH chip for program storage, respectively connected to the ZYNQ chip; the ZYNQ chip includes a PS module and a PL module, the PL module being used for LVDS interface data transmission and reception and packet assembly, RS422 interface data transmission and reception and packet assembly; the PS module being used for ETH interface data transmission and reception, packet assembly, packet parsing and routing, CAN interface data transmission and reception, packet assembly, packet parsing and routing, LVDS interface packet parsing and routing, RS422 interface packet parsing and routing; the PS module and the PL module interact with each other via an AXI bus.

[0005] Furthermore, the CAN interface data transmission, packet assembly, data packet parsing, and routing are implemented by a CAN controller integrated on the PS module in conjunction with an external C device. The external CAN device includes a CAN bus, a CAN transceiver, and an optocoupler connected in sequence. The optocoupler is connected to the CAN controller. CAN data communication is performed using the standard CAN 2.0B protocol. The protocol uses a data frame message type and an extended frame ID type, with a custom extended frame ID content, including the frame sequence number, message ID, source device ID, destination device ID, and CAN message frame data. When the external device sends a data packet through the CAN interface, the data packet needs to be divided into several 8-byte CAN message frames and sent sequentially. The frame sequence number of the CAN message frame starts from 0 and increments. The message ID, source device ID, and destination device ID of each CAN message frame identify that these CAN message frames are split from the same message packet.

[0006] The transmission, packet assembly, packet parsing, and routing processes include three tasks: CAN message reception, CAN message parsing, and CAN message routing. The CAN message reception method is as follows: the PS module listens for CAN message frames sent to it on the CAN bus. By identifying the message ID, source device ID, destination device ID, and frame sequence number of each CAN message frame, it distinguishes CAN message frames belonging to the same message packet, extracts the message body of these CAN message frames to assemble a complete message packet, and places the message packet into a message queue. The CAN message parsing method is as follows: it retrieves the message packet from the message queue, extracts the destination ID, interface type, and interface number from the message header, and establishes a mapping table of interface number, interface type, and device ID. The CAN message routing method is as follows: by querying the mapping table, it outputs the message from the corresponding interface.

[0007] Furthermore, the ETH interface data transmission and reception, packet assembly, packet parsing, and routing are implemented by the GMAC controller integrated on the PS module in conjunction with external ETH devices. The external ETH devices include a PHY chip, a transformer, and a network port connected in sequence, with the PHY chip connected to the GMAC controller.

[0008] The PS module running on ZYNQ implements a TCP or UDP server, binds a different port number to each independent network interface, and connects to an external ETH device to implement a TCP or UDP client, with the corresponding network interface bound to the corresponding port number;

[0009] The ETH interface data transmission, packet assembly, packet parsing, and routing include three tasks: ETH message reception, ETH message parsing, and ETH message routing. When data is input to a network interface, the ETH message reception task performs CRC checksum calculation on the received data packet, compares the calculation result with the CRC checksum field at the end of the message, and if they match, the data packet is considered complete and correct, and the complete data packet is placed into the message queue; otherwise, the data packet is discarded. The ETH message parsing task retrieves the data packet from the message queue and parses it. The parsing action involves: determining the destination ID, interface type, and interface number in the message header, and establishing a mapping table of interface number, interface type, and device ID. The ETH message routing task queries the mapping table and outputs the message from the corresponding interface.

[0010] Furthermore, the LVDS interface data transmission and packet assembly, and the RS422 interface data transmission and packet assembly are implemented by the PL module, using the UART protocol for software communication. The external RS422 device includes an RS422 chip and an RS422 interface connected to it, using the UART protocol for communication. The external device is connected to the switching module through the RS422 interface or the LVDS interface. The external device packages data into a fixed format and inputs it into the switching module. After receiving the LVDS or RS422 interface data stream, the PL module divides the data stream into data packets according to different time intervals. After packetization, the data packets are sequentially buffered in the FIFO opened by the PL module. Then, the data is retrieved from the FIFO and placed in DDR3 through the AXI_HP interface. The packet length information is placed in the QSPI FLASH chip built by the PL module and notified to the PS module. The PS module then performs subsequent processing on the data.

[0011] For the LVDS interface, the subsequent processing flow is as follows: the PS module runs three tasks: LVDS data reception, LVDS data parsing, and LVDS data routing; for the RS422 interface, the PS module runs three tasks: RS422 data reception, RS422 data parsing, and RS422 data routing.

[0012] The specific methods for LVDS and RS422 data reception are as follows: obtain the data packet length through the AXI-GP interface, and then extract the data packet from DDR3; the specific methods for LVDS and RS422 data parsing are as follows: extract the destination ID, interface type, and interface number from the message header, and establish a mapping table of interface number, interface type, and device ID; the specific methods for LVDS and RS422 data routing are as follows: output the message from the corresponding interface by querying the mapping table.

[0013] The beneficial effects of this invention are as follows: This invention provides a method for data conversion between ETH, CAN, RS422, and LVDS interfaces. Data from each interface is packaged according to a fixed format, input from one of the interfaces, and the data packet content is parsed using ZYNQ to determine the destination interface type and interface number before outputting the data. This enables different electronic devices to interact using different interfaces, simplifying the complexity of hardware connections in scenarios with many electronic devices requiring data exchange. Attached Figure Description

[0014] Figure 1 This is a schematic diagram of the interface conversion system for multiple types of hardware based on ZYNQ according to the present invention;

[0015] Figure 2 This is the data packet format of the present invention;

[0016] Figure 3 Flowchart of interface data processing

[0017] Figure 4 A flowchart of the data transmission and reception process;

[0018] Figure 5 Schematic diagram of a CAN controller;

[0019] Figure 6 This is a schematic diagram of a CAN message frame;

[0020] Figure 7 This is a schematic diagram of the CAN message frame assembly process;

[0021] Figure 8 This is a schematic diagram of the CAN message frame assembly process;

[0022] Figure 9 This is a hardware diagram of RS422 and LVDS;

[0023] Figure 10 This is a schematic diagram of the data transmission and reception process for RS422 and LVDS interfaces. Detailed Implementation

[0024] The technical solution of the present invention will be further described below with reference to the accompanying drawings.

[0025] like Figure 1As shown, this invention discloses a method for interface conversion of multiple types of hardware based on ZYNQ, comprising a switching module, and external CAN devices, external ETH devices, external RS422 devices, and external LVDS devices connected to the switching module; the switching module includes a ZYNQ chip and a DDR3 chip for program execution and a QSPI FLASH chip for program storage, respectively connected to the ZYNQ chip; the ZYNQ chip includes a PS module and a PL module, the PL module being used for LVDS interface data transmission and reception and packet assembly, RS422 interface data transmission and reception and packet assembly; the PS module being used for ETH interface data transmission and reception, packet assembly, packet parsing and routing, CAN interface data transmission and reception, packet assembly, packet parsing and routing, LVDS interface packet parsing and routing, RS422 interface packet parsing and routing; the PS module and the PL module interact with each other via an AXI bus.

[0026] External devices connect to the switching module via an ETH interface, LVDS interface, CAN bus interface, or RS422 interface. Each external device has a unique device ID, and the switching module itself also requires a unique device ID. The external devices package data in a fixed format and input the data to the data switching module through the interface connected to it. The data switching module parses the data packets according to the corresponding receiving interface and the data packet format, determines the destination interface type and number, and then transmits the data transparently to the destination external device.

[0027] This invention implements internal data packet parsing and routing through software running on the ZYNQ PS client, divided into three tasks: message reception, message parsing, and message routing. Each interface has its own message reception, parsing, and routing tasks, and each interface has its own message queue to ensure that different types of messages do not interfere with each other. Data packets sent by each interface need to have a fixed format, such as... Figure 2 As shown (this data format is just one implementation method; you can also design your own data packet format according to specific circumstances).

[0028] It includes a message header (including frame header (2 bytes), message ID (1 byte), interface type and interface number (2 bytes), source ID (1 byte), destination ID (1 byte), and message length (2 bytes)), a message body (n bytes), and a message trailer (i.e., CRC checksum (2 bytes)). The specific processes for the three tasks are as follows: Figure 3As shown, data packets from each interface are input to the switching module. The message receiving task checks the integrity of the packet and places the entire message into the message queue to buffer the data packet. The data packet parsing task retrieves messages sequentially from the message queue, parses the message header content, determines the destination interface type and interface number, and establishes a mapping table of interface number, interface type, and device ID in the PS module to match the interface number, interface type, and device ID. The message routing task then sends the parsed message out from the corresponding interface according to the mapping table. A schematic diagram of the data transmission and reception process is shown below. Figure 4 As shown. Message reception specifically includes the following process:

[0029] (1) Create a message receiving task, set the task priority and stack size, and let the task wait for data to be received in the background.

[0030] (2) Determine if any data has arrived. If so, determine if a complete data packet has been received. Otherwise, return (2).

[0031] (3) If a complete data packet is received, put the entire data packet into the message queue; otherwise, return (2).

[0032] Message parsing specifically includes the following process:

[0033] (4) Create a message parsing task, set the task priority and stack size, and ensure that the background message queue for the task is not empty;

[0034] (5) Determine if there is data in the message queue. If so, take a data packet from the message queue; otherwise, continue to wait until the message queue is not empty.

[0035] (6) Parse the extracted data packets, determine the destination interface type and interface number, establish a mapping table of interface number, interface type and device ID, and match the interface number, interface type and device ID;

[0036] Message routing specifically includes the following process:

[0037] (7) Create a message routing task, set the task priority and stack size, and let the task wait in the background for message parsing to complete;

[0038] (8) Determine if a message has been parsed. If so, query the message destination interface type and interface number, and send the data out from the corresponding interface according to the mapping table of interface number, interface type and device ID.

[0039] The core of this invention is the implementation of various types of interfaces and the internal data packet reception, parsing, and routing. The design of each part is described in detail below.

[0040] like Figure 5As shown, the CAN interface data transmission and reception, packet assembly, data packet parsing, and routing are implemented by the CAN controller integrated on the PS module in conjunction with external C external devices; the external CAN device includes a CAN bus, a CAN transceiver, and an optocoupler connected in sequence, with the optocoupler connected to the CAN controller;

[0041] CAN data communication uses the standard CAN 2.0B protocol. The CAN communication protocol specifies two message types: data frames and remote frames, with a maximum single frame size of 8 bytes. It also specifies two types of CAN message IDs: standard frame ID and extended frame ID. The standard frame ID is 11 bits long, and the extended frame ID is 29 bits long. When using the CAN protocol for communication, users can freely choose between data frames and remote frames, and between standard and extended frame IDs. Furthermore, the content of the frame ID can be user-defined. In this invention, the protocol uses the data frame message type and the extended frame ID type, with a user-defined extended frame ID content, including the frame sequence number, message ID, source device ID, destination device ID, and CAN message frame data, such as... Figure 6 As shown; when an external device sends a data packet through the CAN interface, the data packet needs to be divided into several 8-byte CAN message frames and sent sequentially. The frame sequence number of the CAN message frame starts from 0 and increments. The message ID, source device ID, and destination device ID of each CAN message frame identify that these CAN message frames are split from the same message packet, such as... Figure 7 As shown;

[0042] Transmitting, receiving, assembling, parsing, and routing CAN messages include three tasks: CAN message reception, CAN message parsing, and CAN message routing. The specific method for CAN message reception is as follows: The PS module listens for CAN message frames sent to it on the CAN bus (the destination device ID in the frame ID is the CAN message frame of the switching module). By identifying the message ID, source device ID, destination device ID, and frame sequence number of each CAN message frame, it distinguishes CAN message frames belonging to the same message packet. It then extracts the message body portion of these CAN message frames to assemble a complete message packet (the message packet should include a message header, message body, and message trailer, such as...). Figure 2 As shown), the message packet is placed into the message queue; the CAN message parsing method is as follows: retrieve the message packet from the message queue, extract the destination ID, interface type and interface number from the message header, and establish a mapping table of interface number, interface type and device ID; the CAN message routing method is as follows: output the message from the corresponding interface by querying the mapping table.

[0043] The ETH interface data transmission, packet assembly, packet parsing, and routing are implemented by the GMAC controller integrated on the PS module in conjunction with an external ETH device. The external ETH device includes a PHY chip, a transformer, and a network port connected in sequence. The PHY chip is connected to the GMAC controller. Figure 8 As shown; the switching module has two independent ETH interfaces, which can be configured with IP addresses from two different network segments.

[0044] The PS module running on ZYNQ implements a TCP or UDP server, binds a different port number to each independent network interface, and connects to an external ETH device to implement a TCP or UDP client. The corresponding network interface is bound to the corresponding port number to enable data interaction.

[0045] The ETH interface data transmission, packet assembly, packet parsing, and routing include three tasks: ETH message reception, ETH message parsing, and ETH message routing. When data is input to a network interface, the ETH message reception task performs CRC checksum calculation on the received data packet, compares the calculation result with the CRC checksum field at the end of the message, and if they match, the data packet is considered complete and correct, and the complete data packet is placed into the message queue; otherwise, the data packet is discarded. The ETH message parsing task retrieves the data packet from the message queue and parses it. The parsing action involves: determining the destination ID, interface type, and interface number in the message header, and establishing a mapping table of interface number, interface type, and device ID. The ETH message routing task queries the mapping table and outputs the message from the corresponding interface.

[0046] The LVDS interface data transmission and packet assembly, and the RS422 interface data transmission and packet assembly are implemented by the PL module, such as... Figure 9 As shown, the software communication protocol uses the UART protocol; the external RS422 device includes an RS422 chip and an RS422 interface connected to it, and the communication protocol uses the UART protocol; the external device is connected to the switching module through the RS422 interface or LVDS interface; the external device packages data into a fixed format and inputs it into the switching module; after receiving the data stream from the LVDS or RS422 interface, the PL module divides the data stream into data packets according to different time intervals, and the format of the packetized data is as follows. Figure 2 As shown; after packetization, the data packets are cached sequentially in the FIFO opened by the PL module. Then, the data is retrieved from the FIFO and placed in DDR3 through the AXI_HP interface. The packet length information is placed in the QSPI FLASH chip built by the PL and notified to the PS module. The PS module then performs subsequent processing on the data.

[0047] For the LVDS interface, the subsequent processing flow is as follows: the PS module runs three tasks: LVDS data reception, LVDS data parsing, and LVDS data routing; for the RS422 interface, the PS module runs three tasks: RS422 data reception, RS422 data parsing, and RS422 data routing. Figure 10 As shown;

[0048] The specific methods for LVDS and RS422 data reception are as follows: obtain the data packet length through the AXI-GP interface, and then extract the data packet from DDR3; the specific methods for LVDS and RS422 data parsing are as follows: extract the destination ID, interface type, and interface number from the message header, and establish a mapping table of interface number, interface type, and device ID; the specific methods for LVDS and RS422 data routing are as follows: output the message from the corresponding interface by querying the mapping table.

[0049] Those skilled in the art will recognize that the embodiments described herein are intended to help the reader understand the principles of the invention, and should be understood that the scope of protection of the invention is not limited to such specific statements and embodiments. Those skilled in the art can make various other specific modifications and combinations based on the technical teachings disclosed in this invention without departing from the spirit of the invention, and these modifications and combinations are still within the scope of protection of this invention.

Claims

1. A method for interface conversion of multiple types of hardware based on ZYNQ, characterized in that, The system includes a switching module and external CAN, ETH, RS422, and LVDS devices connected to the switching module. The switching module includes a ZYNQ chip and a DDR3 chip for program execution and a QSPI FLASH chip for program storage, both connected to the ZYNQ chip. The ZYNQ chip includes a PS module and a PL module. The PL module is used for LVDS and RS422 interface data transmission, reception, and packet assembly. The PS module is used for ETH, CAN, LVDS, and RS422 interface data transmission, reception, packet assembly, data packet parsing, and routing. The PS and PL modules interact via an AXI bus. The CAN interface data transmission, packet assembly, data packet parsing, and routing are implemented by the CAN controller integrated on the PS module in conjunction with external C external devices. The external CAN device includes a CAN bus, a CAN transceiver, and an optocoupler connected in sequence. The optocoupler is connected to the CAN controller. CAN data communication uses the standard CAN 2.0B protocol, which uses a data frame message type and an extended frame ID type. The extended frame ID content is customized and includes the frame sequence number, message ID, source device ID, destination device ID, and CAN message frame data. When the external device sends a data packet through the CAN interface, the data packet needs to be divided into several 8-byte CAN message frames and sent sequentially. The frame sequence number of the CAN message frame starts from 0 and increments. The message ID, source device ID, and destination device ID of each CAN message frame identify that these CAN message frames are split from the same message packet. The transmission, packet assembly, packet parsing, and routing processes include three tasks: CAN message reception, CAN message parsing, and CAN message routing. The CAN message reception method is as follows: the PS module listens for CAN message frames sent to it on the CAN bus. By identifying the message ID, source device ID, destination device ID, and frame sequence number of each CAN message frame, it distinguishes CAN message frames belonging to the same message packet, extracts the message body of these CAN message frames to assemble a complete message packet, and places the message packet into a message queue. The CAN message parsing method is as follows: it retrieves the message packet from the message queue, extracts the destination ID, interface type, and interface number from the message header, and establishes a mapping table of interface number, interface type, and device ID. The CAN message routing method is as follows: by querying the mapping table, it outputs the message from the corresponding interface.

2. The method for interface conversion of multiple types of hardware based on ZYNQ according to claim 1, characterized in that, The ETH interface data transmission, packet assembly, packet parsing, and routing are implemented by the GMAC controller integrated on the PS module in conjunction with external ETH devices. The external ETH devices include a PHY chip, a transformer, and a network port connected in sequence. The PHY chip is connected to the GMAC controller. The PS module running on ZYNQ implements a TCP or UDP server, binds a different port number to each independent network interface, and connects to an external ETH device to implement a TCP or UDP client, with the corresponding network interface bound to the corresponding port number; The ETH interface data transmission, packet assembly, packet parsing, and routing include three tasks: ETH message reception, ETH message parsing, and ETH message routing. When data is input to a network interface, the ETH message reception task performs CRC checksum calculation on the received data packet, compares the calculation result with the CRC checksum field at the end of the message, and if they match, the data packet is considered complete and correct, and the complete data packet is placed into the message queue; otherwise, the data packet is discarded. The ETH message parsing task retrieves the data packet from the message queue and parses it. The parsing action involves: determining the destination ID, interface type, and interface number in the message header, and establishing a mapping table of interface number, interface type, and device ID. The ETH message routing task queries the mapping table and outputs the message from the corresponding interface.

3. The method for interface conversion of multiple types of hardware based on ZYNQ according to claim 1, characterized in that, The LVDS interface data transmission and packet assembly, and the RS422 interface data transmission and packet assembly are implemented by the PL module, using the UART protocol for software communication. The external RS422 device includes an RS422 chip and a connected RS422 interface, using the UART protocol for communication. The external device connects to the switching module via the RS422 or LVDS interface. The external device packages data into a fixed format and inputs it to the switching module. After receiving the LVDS or RS422 interface data stream, the PL module divides the data stream into data packets according to different time intervals. After packetization, the data packets are sequentially buffered in a FIFO allocated by the PL module. The data is then retrieved from the FIFO and placed in DDR3 via the AXI_HP interface. The packet length information is placed in the QSPIFLASH chip built by the PL module, and the PS module is notified. The PS module then performs subsequent data processing. For the LVDS interface, the subsequent processing flow is as follows: the PS module runs three tasks: LVDS data reception, LVDS data parsing, and LVDS data routing; for the RS422 interface, the PS module runs three tasks: RS422 data reception, RS422 data parsing, and RS422 data routing. The specific methods for LVDS and RS422 data reception are as follows: obtain the data packet length through the AXI-GP interface, and then extract the data packet from DDR3; the specific methods for LVDS and RS422 data parsing are as follows: extract the destination ID, interface type, and interface number from the message header, and establish a mapping table of interface number, interface type, and device ID; the specific methods for LVDS and RS422 data routing are as follows: output the message from the corresponding interface by querying the mapping table.

Images