Transmission method of Esp32 serial port communication system

Abstract

The invention discloses a transmission method of an Esp32 serial port communication system, which is applied to the technical field of communication, the J1939 communication technology of a Can bus is improved, any one value of a PGN number can be selected from 0-65565, a client defines the function of the PGN number, each time an ESP32 unvarnished transmission module is powered on, and a plurality of PGN numbers of a user form only need to be transmitted respectively for the first time, so that the PGN numbers can be transmitted to the client, and the PGN numbers can be transmitted to the client. The ESP32 module memorizes the PGN number at the first time, data can be successfully transmitted in a transparent manner at the second time, and memory is emptied in case of power failure; by adopting the method disclosed by the invention, intelligent memory can be quickly realized, the master machine and the slave machine completely upload and download data in a form form, unvarnished transmission is completely realized, automatic splicing is realized during multi-packet data transmission, and after complete data unvarnished transmission is successful, a data explanation right is automatically handed over to an upper-layer user interface, so that a user does not need to care about an internal implementation process.

Description

Technical Field

[0001] This invention belongs to the field of communication technology, and specifically relates to a serial communication technology. Background Technology

[0002] The commonly used MODBUS_RTU is based on RS-485 / RS-232 serial communication interfaces, employs differential signal transmission (RS-485), supports half-duplex communication mode, and requires a master-slave polling mechanism for device interaction. Its standard frame format is: address code (1 byte) + function code (1 byte) + data field (N bytes) + CRC checksum (2 bytes). It suffers from slow response, small data transmission volume per transmission, and the requirement that the host must clearly know the requested address and data length. Existing serial communication also has the following technical drawbacks:

[0003] 1) The existing serial communication frame verification is entirely defined by the protocol developer, which is rigid and not flexible enough for the application layer;

[0004] 2) Existing serial communication protocols require pre-definition of frame headers and trailers, resulting in limited universality;

[0005] 3) Existing serial communication protocols are not robust, lack reconnection and pause functionality, and multi-packet transmission is difficult to implement. Summary of the Invention

[0006] To solve the above-mentioned technical problems, this invention proposes a transmission method for an Esp32 serial communication system. After the Esp32 module is powered on, it can automatically learn the PGN number of the user form and achieve data pass-through effect.

[0007] The technical solution adopted in this invention is as follows: a transmission method for an ESP32 serial communication system, wherein the PGN number can be any value from 0 to 65565, and the client can define its function arbitrarily; when the receiver receives the information sent by the sender, the receiver's ESP32 module first searches for its PGN number. If the sender's PGN number is not registered, the receiver's ESP32 module registers the current PGN number; if the PGN number is already registered, the data reception process begins. After all data is received, the receiver extracts the data content based on the data extraction function and delivers it to the application layer.

[0008] The beneficial effects of this invention are as follows: The method of this invention can quickly realize intelligent memory. The master and slave machines upload and download data entirely in the form of forms, which fully realizes transparent transmission. When transmitting multi-packet data, it automatically splices the data. After the complete data is successfully transmitted, the right to interpret the data will be automatically handed over to the upper-layer user interface. Users do not need to care about the internal implementation process. Attached Figure Description

[0009] Figure 1 This is a diagram illustrating the automatic learning of PGN numbers.

[0010] Figure 2 This refers to the data transmission order in connection mode;

[0011] Wherein, (a) is the data transmission order under the condition of transmission error, and (b) is the data transmission order under the condition of transmission error;

[0012] Figure 3 For the order of broadcast data transmission;

[0013] Figure 4 The data transmission order that allows the maximum number of RTS data packets to be used for data transmission;

[0014] Figure 5 The data transmission order is determined by the maximum number of RTS packets that cannot be used for data transmission. Detailed Implementation

[0015] To facilitate understanding of the technical content of this invention by those skilled in the art, the following description, in conjunction with the accompanying drawings, further illustrates the invention.

[0016] In this embodiment, the maximum single packet data length is defined as: J1939_MAXONEPAGE_LEN = 100. In actual applications, users can determine the single packet data length according to the channel quality and baud rate.

[0017] The determination of the baud rate is related to the transmission distance. It is estimated based on the principle that length * baud rate < 10^6. In long-distance transmission, the baud rate must be actively reduced to improve reliability. Baud rate selection criteria:

[0018] For long distances (>50 meters): typically choose 4800, 9600 or lower baud rates.

[0019] For short distances (<10 meters): baud rates of 115200 or even higher can be used.

[0020] Channel quality can be divided into high channel quality and general channel quality, for example:

[0021] High-quality channel (well-shielded cable, short distance, low noise environment): RS232: recommended transmission distance < 5 meters, baud rate 115200 or higher, then single packet data length ≤ 100; RS485: recommended transmission distance < 1200 meters, baud rate 9600, then single packet data length ≤ 50.

[0022] For general quality channels (ordinary cables), RS232: recommended transmission distance < 1 meter, baud rate 115200 or higher, then single packet data length ≤ 100; RS485: recommended transmission distance < 400 meters, baud rate 9600, then single packet data length ≤ 50, or recommended transmission distance < 100 meters, baud rate 115200, then single packet data length ≤ 100.

[0023] The data format PDU (Protocol Data Unit) of this invention is shown in Table 1, including a frame header and a data portion. The frame header includes Head, PDUFormat, Dest_Addr, Sre_Addr, LEN, and CRC, and the data portion is Data.

[0024] Table 1 Data Format PDU Structure Table

[0025]

[0026] The following uses different single-packet data lengths as examples to illustrate the data format PDUs shown in Table 1:

[0027] 1: The length of a single packet of data is less than the J1939_MAXONEPAGE_LEN set in this embodiment.

[0028] Head: Fixed at 0x18

[0029] PDUFormat: This is the user form identifier, which can be defined arbitrarily by the user. For example, 1 indicates the following form Buffer[N].

[0030] This represents battery voltage data; for example, 2 indicates that the subsequent form Buffer[N] contains temperature data...

[0031] Dest_Addr: Data receiver address ID

[0032] Sre_Addr: The address ID of the data sender.

[0033] LEN: Actual data buffer length

[0034] CRC: Cross-domain checksum of all PDU data

[0035] Data: As shown in Table 2, if the actual user form data is less than or equal to J1939_MAXONEPAGE_LEN, then there is no need to send it in packets.

[0036] Table 2. Transmission data structure table for actual user form data less than or equal to J1939_MAXONEPAGE_LEN.

[0037]

[0038] The connection establishment, connection agreement, and transmission completion processes during transmission can be referred to in the corresponding descriptions in the subsequent example where the single packet data length is greater than J1939_MAXONEPAGE_LEN. This invention will not elaborate on these details here.

[0039] 2: The length of a single packet of data is greater than J1939_MAXONEPAGE_LEN

[0040] Head: Fixed at 0x18

[0041] PDUFormat: 0xEC - Initiator requests connection, 0xEB - Initiator sends packet fragments.

[0042] Dest_Addr: Data receiver address ID

[0043] Sre_Addr: The address ID of the data sender.

[0044] LEN: Actual data buffer length

[0045] CRC: Cross-domain checksum of all PDU data

[0046] The linking process for J1939_MAXONEPAGE_LEN is as follows:

[0047] 1) The sender requests to establish a connection. The data format sent by the sender to the receiver is shown in Table 3, which includes a frame header and a connection request part. The frame header includes: Head, PDUFormat, Dest_Addr, Sre_Addr, LEN, and CRC. The connection request part includes: function code, transmission length, total number of packets, default value 1, PGN, and default value 2.

[0048] Table 3. Data format table for connection requests

[0049]

[0050] TPCM_RTS:0x10 Fixed function code

[0051] Transmission length: The total length of user data, 2 bytes, low-order first, high-order last.

[0052] Total number of packets: Each packet has a data length of J1939_MAXONEPAGE_LEN, and the total number of packets is the user data.

[0053] / J1939_MAXONEPAGE_LEN

[0054] Default value 1: 0xFF

[0055] PGN: User's Actual Data Form Identifier

[0056] Default value 2: 0x00

[0057] 2) The receiver agrees to establish a connection. The data format sent by the receiver to the sender is shown in Table 4, including the frame header and the response connection part. The frame header includes: Head, PDUFormat, Dest_Addr, Sre_Addr, LEN, CRC; the response part includes: function code, receiveable packet, next packet, default value 1, PGN, default value 3.

[0058] Table 4 Data Format Table for Response Connection

[0059]

[0060] TPCM:0x11 Fixed Function Code

[0061] Packet Receiver: The number of packets the receiver can actually receive; its value is less than or equal to the total number of packets in the request connection initiated by the sender.

[0062] Next packet: During packet transmission, inform the sender of the starting packet number it will receive.

[0063] Default value 1: 0xFF

[0064] Default value 2: 0xFF

[0065] PGN: User Actual Data Form Identifier

[0066] Default value 3: 0x00

[0067] 3) During packet transmission, the data structure sent from the sender to the receiver is shown in Table 5, which includes a frame header and a packet transmission part. The frame header includes: Head, PDUFormat, Dest_Addr, Sre_Addr, LEN, and CRC. The packet transmission part includes: packet number and user data.

[0068] Table 5 Data Structure Table for Packet Transmission

[0069]

[0070] Head: 0x18 Fixed function code

[0071] PDUFormat:0xEB Fixed Function Code

[0072] Packet number: The packet number sent by the initiator in turn.

[0073] 4) When the receiver has finished receiving all data, the data structure sent by the receiver to the sender is shown in Table 6, which includes a frame header and a reception completion confirmation part. The frame header includes: Head, PDUFormat, Dest_Addr, Sre_Addr, LEN, and CRC. The reception completion part includes: function code, transmission length, total packet number, default value 1, PGN, and default value 2.

[0074] Table 5: Data Structure Format Table for Completed Data Reception

[0075]

[0076] Function code: 0x13 (fixed function code)

[0077] Transmission length: The total length of all data received by the receiver.

[0078] Total Packet Number: The total number of data packets received by the receiver.

[0079] Default value 1: 0xFF

[0080] PGN: User's actual data form identification number for this connection

[0081] Default value 2: 0x00

[0082] In this embodiment, the key data structures are defined as follows:

[0083]

[0084]

[0085] In this embodiment, the key function is defined as follows:

[0086] Receive function: Features - Automatically supports single-packet and multi-packet reception

[0087] j1939_ReceiveMessage_Rs(S_J1939_MSGINFO_EX*s_info,uint16_tdatabufflen,void

[0088] (*cb_fun)(uint8_t addr,uint16_t pgn));

[0089] 1. Recipient PGN Registration Function

[0090] 2.s_info: Defines the current user's form attributes, i.e., who sent it and what their identifier is.

[0091] 3. databufflen: Current user form length

[0092] 4. *cb_fun: The function corresponding to the user application layer processing table. For example, if the PGN number is 0x01, it corresponds to the A_fun processing function. The protocol layer automatically receives the data and automatically jumps to the user layer A_fun after completion. The user interprets the data according to the PGN number, where addr is the name of the sender of the data.

[0093] Send function: Features - Automatically supports single-packet and multi-packet sending

[0094] j1939_SendMessage_Rs(const S_J1939_MSGINFO_EX*s_info,uint8_tdesAddr);

[0095] 1. Function for initiating the form submission

[0096] The 2.s_info structure definition includes the PGN number and the sender's form header address.

[0097] 3. desAddr Receiver target address

[0098] PGN Number Self-Learning Process Explanation: Each time the ESP32 pass-through module powers on, assuming the user form has 1-100 PGN numbers, the ESP32 module only needs to remember the PGN numbers during the first transmission of each number (1-100). The second transmission will then successfully pass through the data. Power failure clears the memory. The specific process is as follows: Figure 1 As shown, the sending method is PGN(0x01). The receiver retrieves the PGN number and checks whether the PGN number is registered. If it is not registered, it registers (PGN number, User_Fun) and then returns to retrieve the next PGN number. If it is already registered, it starts receiving data. After receiving all the data, it enters the User_fun interpretation function in the user layer, where the user layer data logic is applied.

[0099] like Figure 2(a) shows the data transmission sequence in connection mode. The sender requests a connection via a TP.CM_RTS message and informs the receiver that it will send four data packets totaling 23 bytes. The receiver replies with a TP.CM_CTS message, indicating that it is ready to process the first two data packets, starting with packet number 1. The sender sends the first two data packets over the network using a TP.DT message. Then, the receiver sends a TP.CM_CTS message, indicating that it wants to maintain the connection but cannot immediately receive any more data packets. After a maximum delay of 500 milliseconds, it must send another TP.CM_CTS message to maintain the connection. In this example, the receiver sends another TP.CM_CTS message, indicating that it can receive the second two data packets, starting with packet number 3. Once packets numbered 3 and 4 have been transmitted, the receiver sends a TP.EndofMsgACK message, indicating that all data packets have been received and the connection is now closed. Note that packet number 4 contains two bytes of valid data, namely bytes 22 and 23, and the remaining invalid bytes of the packet are set to 255 (FF). 16 The message is transmitted using , so the message length is 8 bytes.

[0100] like Figure 2 (b) shows the data transmission sequence in connection mode under the condition of transmission errors. The first two data packets are sent, but the receiver believes that there is an error in data packet number 2. Then the receiver sends a TP.CM_CTS message, indicating that it wants data packet number 2 to be sent as a separate data packet. The sender responds and retransmits data packet number 2. Next, the sender sends a CTS message, indicating that it wants the two data packets starting from number 3. This TP.CM_CTS message confirms that data packets number 2 and 2 have been received correctly. Once the last data packet is received correctly, the receiver sends a TP.EndofMsgACK message, indicating that the entire message has been received correctly.

[0101] like Figure 3 The diagram illustrates the broadcast data transmission order, where a node indicates to the network that it will use the transport protocol's services to transmit multiple sets of messages. In... Figure 3 In the example shown, the PGN 65260 vehicle identification identifier is broadcast across the network. The sending node first sends a TP.CM_BAM message (i.e., a broadcast announcement message), followed by a data packet. None of the receivers acknowledge receipt.

[0102] like Figure 4 The image shows the transmission order of the maximum number of RTS data packets that can be used for data transmission. Figure 4In the example shown, both devices support the maximum data packet parameter, which the sender uses to limit the number of data packets the receiver needs to request to be transmitted.

[0103] like Figure 5 Data packet transmission cannot utilize the maximum number of RTS data packets and their transmission order. Figure 5 If the sender supports the RTS parameter "Maximum Number of Packets" but the receiver does not, then the sender must comply with the receiver's CTS limit. Figure 5 As shown, although it would be more appropriate for the sender to send 5 data packets each time (TP.CM_RTS:16 46 7 5 65227, connection request function code 16, total data length 46 07 (actual hexadecimal data is 0x2E, 0x07, i.e., total bytes 0x072E, which is 1838 bytes), requesting 5 packets to send (5*J1939_MAXONEPAGE_LEN)), it will have to send 7 data packets (TP.CM_CTS:17 7 1 255 255 65227, response request function code 17, response receiving packets 7 (7*(J1939_MAXONEPAGE_LEN-1)), starting from receiving the first packet).

[0104] Figure 5 It is important to note that if the responder sends a CTS to packet 1 after packet 7 has been transmitted, the sender will recalculate the information. Therefore, the data transmitted in the second packet 1 may differ from the original packet 1, depending on the data type contained in the PGN. For example, PGN 65227 contains dynamic data, which may cause changes in packet 1; PGN 65242 contains static data and will not cause changes in packet 1 during the second transmission.

[0105] Those skilled in the art will recognize that the embodiments described herein are for the purpose of helping to 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. Various modifications and variations can be made to the invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the invention should be included within the scope of the claims of the invention.

Claims

1. A transmission method for an ESP32 serial communication system, characterized in that, The sender's PGN number can be any value from 0 to 65565, and its function can be defined as follows: When the receiver receives the information sent by the sender, the receiver's Esp32 module first searches for its PGN number. If the sender's PGN number is not registered, the receiver's Esp32 module registers the current PGN number. If the PGN number is already registered, the data reception process begins. After all the data has been received, the receiver extracts the data content based on the data extraction function and delivers it to the application layer.

2. The transmission method of an ESP32 serial communication system according to claim 1, characterized in that, The longest single packet data length is determined based on channel quality and baud rate.

3. The transmission method of an ESP32 serial communication system according to claim 2, characterized in that, When the length of a single packet of data sent by the sender is less than or equal to the longest single packet of data length, single packet transmission is used.

4. The transmission method of an ESP32 serial communication system according to claim 3, characterized in that, When the length of a single packet sent by the sender is less than or equal to the longest single packet length, multiple packets are sent.

5. The transmission method of an ESP32 serial communication system according to claim 4, characterized in that, The multi-packet sending process is as follows: A1. The sender sends a connection request message to the receiver; A2. The receiver first searches for the sender's PGN number. If the sender's PGN number is not registered, the receiver's Esp32 module registers the current PGN number and then sends an acknowledgment connection message. If the PGN number is already registered, the receiver directly sends an acknowledgment connection message. A3. The sender sends packets according to the requirements in the response connection; A4. When the receiver has finished receiving all data, it sends a message indicating that the reception is complete and closes the connection.

6. The transmission method of an ESP32 serial communication system according to claim 5, characterized in that, The response connection message should include at least the number of packets that can be received and the initial number of packets to be received.

7. The transmission method of an ESP32 serial communication system according to claim 6, characterized in that, When the receiver needs to pause receiving data packets, it sends an acknowledgment connection message at regular intervals. In the acknowledgment connection message, the number of packets that can be received is set to 0.

8. A transmission method for an ESP32 serial communication system according to claim 6 or 7, characterized in that, When the receiver considers the received data packet to be erroneous, it sets the number of packets it can receive to 1 and the starting number of packets to receive to the number of erroneous data packets in the response connection message it sends to the sender.

Images