A method and system for CAN and UART protocol processing

Abstract

The application relates to the technical field of protocol processing, and discloses a CAN and UART protocol processing method and system. The method comprises the following steps: cutting a UART format data packet to obtain a fragmented byte array, encapsulating each fragment in the fragmented byte array into a CAN extended frame sequence, and sending the CAN extended frame sequence according to a fragment serial number; a receiving end captures a CAN extended frame with an ID falling within the ID range from a reference ID to an end frame, writes the data field content of each CAN extended frame into a recombination buffer area to obtain recombination buffer area data; after receiving the end frame, the recombination buffer area data is checked, and after all the checks are passed, the recombination buffer area data is submitted to a BMS application layer protocol stack. No matter what kind of service function code the BMS system contains, the same set of fixed ID pool is reused for data transmission, the traditional mode of 'one function one ID' is completely abandoned, and the BMS system can stably run in a complex multi-device CAN network environment.

Description

Technical Field

[0001] This invention relates to the field of protocol processing technology, and in particular to a method and system for processing CAN and UART protocols. Background Technology

[0002] The CAN bus is widely used in communication scenarios between battery management systems and host computers due to its high reliability and strong real-time performance. However, existing BMS communication protocols were initially designed based on UART serial ports, with their protocol frame structure based on continuous byte streams, supporting flexible data packet lengths and a unified function code system. As applications migrate to the CAN bus, how to effectively port the byte-stream-oriented UART protocol to the discrete-frame-oriented CAN bus has become a pressing technical problem.

[0003] Existing technologies employ a "one function, one ID" approach, assigning a separate CAN identifier to each service function in the BMS system. Since a single CAN frame carries only 8 bytes of data, large data transmissions consume significant ID resources. As service functions expand, ID usage increases dramatically, easily conflicting with the ID planning of third-party devices in the customer's existing CAN network, leading to bus communication anomalies. Furthermore, due to the fundamental differences between the byte-stream communication mode of the UART protocol and the ID-frame communication mode of the CAN protocol, existing technologies require maintaining a separate ID mapping table and data reassembly code for the CAN interface, logically independent of the original UART protocol. The same service function has two sets of implementation logic under the two interfaces, resulting in extremely high development and maintenance costs. Moreover, the receiving end lacks a unified and definitive frame boundary determination mechanism, posing risks of packet errors and packet merging. Summary of the Invention

[0004] The main objective of this invention is to provide a CAN and UART protocol processing method and system. Regardless of the service function codes included in the BMS system, this invention reuses the same fixed ID pool for data transmission, completely abandoning the traditional "one function, one ID" model. It compresses the ID resources required for the transmission of all service data to a fixed number, eliminating the risk of ID conflicts caused by the expansion of ID resources as the number of service functions increases, and enabling the BMS system to operate stably in a complex multi-device CAN network environment.

[0005] To achieve the above objectives, the present invention provides a CAN and UART protocol processing method, comprising the following steps: The UART format data packet is segmented into a fragmented byte array, and each fragment in the fragmented byte array is encapsulated into a CAN extended frame sequence. The CAN extended frame sequence is sent according to the fragment sequence number. The receiving end captures CAN extended frames whose IDs fall within the range of the base ID to the end frame ID, and writes the data field content of each CAN extended frame into the reassembly buffer to obtain the reassembly buffer data; Upon receiving the end frame, the data in the reassembled buffer is verified. After all verifications pass, the data in the reassembled buffer is submitted to the BMS application layer protocol stack.

[0006] Optionally, in a first implementation of the first aspect of the present invention, the step of segmenting a UART format data packet into a fragmented byte array, encapsulating each fragment in the fragmented byte array into a CAN extended frame sequence, and sending the CAN extended frame sequence according to the fragment sequence number includes: Read the data length field in the UART format data packet, add the value of the data length field to the fixed number of bytes occupied by the protocol header field and the data length field, and get the total number of bytes in the data packet; The total number of bytes in the data packet is divided by 8 bytes as a fixed payload length. Any remainder less than 8 bytes is counted as a fragment, and the total number of fragments is obtained. Based on the total number of fragments, 8-byte segments are sequentially extracted from the first byte of the UART format data packet, and the last segment is the actual remaining bytes, to obtain the fragment byte array; Each fragment in the fragmented byte array is encapsulated into a CAN extended frame sequence, and the CAN extended frame sequence is sent according to the fragment sequence number.

[0007] Optionally, in a second implementation of the first aspect of the present invention, the step of encapsulating each fragment in the fragmented byte array into a CAN extended frame sequence and sending the CAN extended frame sequence according to the fragment sequence number includes: Each fragment in the fragmented byte array is encapsulated into a CAN extended frame sequence; The CAN extended frame sequence is sent according to the fragment sequence number. After the entire CAN extended frame sequence has been sent, an end frame is constructed and sent. The data field of the end frame is not written with any content in the fragment byte array.

[0008] Optionally, in a third implementation of the first aspect of the present invention, the step of encapsulating each fragment in the fragmented byte array into a CAN extended frame sequence includes: S101. Using the segment number i as an index, fill all the bytes of the i-th segment in the segment byte array into the data field of a CAN extended frame in sequence, and set the data length code of the corresponding CAN extended frame to the actual number of bytes of the i-th segment, so as to obtain the CAN extended frame with the data field and data length code set. S102. Set the ID of the CAN extended frame with the data field and data length code set to the sum of the base ID and the fragment number i to obtain the CAN extended frame with the ID set. S103. Increment the fragment sequence number i by 1, and repeat S101 to S102 for the next fragment in the fragment byte array until all fragments within the total number of fragments are encapsulated, thus obtaining the CAN extended frame sequence.

[0009] Optionally, in a fourth implementation of the first aspect of the present invention, the step of sending the CAN extended frame sequence according to the fragment sequence number, and constructing and sending an end frame after all the CAN extended frame sequences have been sent, wherein the data field of the end frame is not written with any content in the fragment byte array, includes: According to the fragment sequence number, each CAN extended frame in the CAN extended frame sequence is sent sequentially through the CAN controller until all the CAN extended frames corresponding to the total number of fragments have been sent. After the entire CAN extended frame sequence has been sent, an empty data field is constructed as an end frame. The ID of the end frame is set to the sum of the reference ID and the preset offset upper limit value. The end frame is then sent through the CAN controller. The data field of the end frame is not written with any content in the fragment byte array.

[0010] Optionally, in a fifth implementation of the first aspect of the present invention, the receiving end captures CAN extended frames whose IDs fall within the range of the reference ID to the end frame ID, and writes the data field content of each CAN extended frame into a reassembly buffer to obtain reassembly buffer data, including: The receiver captures CAN extended frames whose IDs fall within the range of the base ID to the end frame ID, and calculates the buffer write offset for each captured CAN extended frame. Write the data field content of each CAN extended frame into a reassembly buffer, with the buffer write offset of each CAN extended frame multiplied by the fixed payload length as the starting byte position of a continuous byte region; When the write offset of the CAN extended frame buffer is zero, the reassembly buffer is cleared and then written again. The CAN extended frames are written sequentially according to their arrival order until the end frame is received, thus obtaining the reassembly buffer data.

[0011] Optionally, in a sixth implementation of the first aspect of the present invention, the receiving end captures CAN extended frames whose IDs fall within the range of the reference ID to the end frame ID, and calculates a buffer write offset for each captured CAN extended frame, including: Write an ID filter register to the CAN controller, set the filter start value to the reference ID and the filter end value to the ID of the end frame, so that the CAN controller discards all CAN messages whose IDs are not within the range of the reference ID to the ID of the end frame at the hardware layer, and the receiving end captures CAN extended frames whose IDs fall within the range of the reference ID to the ID of the end frame. For each captured CAN extended frame, the ID of the CAN extended frame is subtracted from the reference ID to obtain the buffer write offset, and it is verified whether the buffer write offset is equal to the quotient of the number of bytes written to the reassembled buffer divided by the fixed payload length. If they are not equal, it is determined that the frame sequence number of the CAN extended frame is not continuous. The reassembly buffer is cleared and the number of bytes written is reset to zero. The writing is retried after the next CAN extended frame with a write offset of zero arrives in the buffer.

[0012] Optionally, in the seventh implementation of the first aspect of the present invention, after receiving the end frame, verifying the reassembled buffer data, and submitting the reassembled buffer data to the BMS application layer protocol stack after all verifications pass, includes: Upon receiving the end frame, the protocol header validity and data length consistency are checked on the reassembled buffer data to obtain the total number of bytes in the frame. Based on the total number of bytes in the frame, two bytes located at the CRC field position are extracted from the reconstructed buffer data as the received check value. The ModBusCRC16 algorithm is executed on all bytes before the start position of the CRC field in the reconstructed buffer data to obtain the calculated check value. The received verification value is compared with the calculated verification value. After the verification value comparison is successful, the last byte of the reassembled buffer data is checked to see if it is an end code. If it is, the reassembled buffer data is submitted to the BMS application layer protocol stack.

[0013] Optionally, in a ninth implementation of the first aspect of the present invention, after receiving the end frame, performing protocol header validity verification and data length consistency verification on the reassembled buffer data to obtain the total number of bytes in the frame includes: Upon receiving the end frame, the first two bytes of the reassembled buffer data are subjected to protocol header validity verification. After the protocol header validity verification passes, a protocol header type flag is generated. Based on the protocol header type marker, the data length field value composed of the third and fourth bytes of the reassembled buffer data is read, and the data length field value is added to the fixed number of bytes occupied by the protocol header field and the data length field to obtain the total number of bytes in the frame; If the total number of bytes in the frame is equal to the number of bytes already written in the reassembly buffer, then the data length consistency check is passed, and the total number of bytes in the frame is obtained.

[0014] The present invention also provides a CAN and UART protocol processing system, comprising: The segmentation and transmission module is used to segment UART format data packets into a segmented byte array, encapsulate each segment in the segmented byte array into a CAN extended frame sequence, and transmit the CAN extended frame sequence according to the segment sequence number. The reassembly buffer module is used by the receiving end to capture CAN extended frames whose IDs fall within the range of the base ID to the end frame ID, and write the data field content of each CAN extended frame into the reassembly buffer to obtain the reassembly buffer data. The verification and submission module is used to verify the reassembled buffer data after receiving the end frame, and submit the reassembled buffer data to the BMS application layer protocol stack after all verifications pass.

[0015] In summary, this invention redefines the low byte of the CAN extended frame ID as the data fragmentation location index, uses the sum of the base ID and the fragmentation sequence number as the ID of each fragmented frame, and uses the ID of the dedicated end frame as the transmission boundary signaling, thus constructing a complete processing flow for data fragmentation, sequential transmission, ordered reassembly, and integrity verification. Compared to existing technologies, this invention reuses the same fixed ID pool for data transmission regardless of the service function codes included in the BMS system, completely abandoning the traditional "one function, one ID" model. It compresses the ID resources required for the transmission of all service data to a fixed number, eliminating the risk of ID conflicts caused by the expansion of ID resources with the increase in the number of service functions, enabling the BMS system to operate stably in complex multi-device CAN network environments. Simultaneously, this invention achieves accurate frame boundary determination at the receiving end through buffer offset continuity verification and end frame-triggered reassembly mechanisms, effectively avoiding packet errors and packet merging problems, and ensuring the correctness of the data reassembly results. More importantly, the data submitted to the BMS application layer protocol stack after reassembly is completely consistent with the data received by the UART serial port in terms of frame format, function code definition and register mapping relationship. The application layer can directly reuse all business logic without making any modifications to the CAN interface, realizing the seamless operation of a single protocol code on both UART and CAN physical interfaces, and reducing the cost of protocol development and maintenance. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the steps of a CAN and UART protocol processing method in one embodiment of the present invention; Figure 2 As described in this embodiment of the invention; Figure 3As described in this embodiment of the invention; Figure 4 As described in this embodiment of the invention; Figure 5 As described in this embodiment of the invention; Figure 6 This is a block diagram of the CAN and UART protocol processing system in an embodiment of the present invention.

[0017] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0019] Reference Figure 1 This embodiment provides a method for processing CAN and UART protocols, including the following steps: S1. Cut the UART format data packet into a fragmented byte array, and encapsulate each fragment in the fragmented byte array into a CAN extended frame sequence, and send the CAN extended frame sequence according to the fragment sequence number; S2. The receiving end captures CAN extended frames whose IDs fall within the range of the base ID to the end frame ID, and writes the data field content of each CAN extended frame into the reassembly buffer to obtain the reassembly buffer data. S3. After receiving the end frame, verify the data in the reassembled buffer. After all verifications pass, submit the data in the reassembled buffer to the BMS application layer protocol stack.

[0020] In one example, such as Figure 2 The UART format data packet is segmented into a fragmented byte array, and each fragment in the fragmented byte array is encapsulated into a CAN extended frame sequence. The CAN extended frame sequence is sent according to the fragment sequence number, including: S11. Read the data length field in the UART format data packet, add the value of the data length field to the fixed number of bytes occupied by the protocol header field and the data length field, and get the total number of bytes in the data packet; S12. Divide the total number of bytes in the data packet by 8 bytes as a fixed payload length. The remainder that is less than 8 bytes is counted as a fragment, and the total number of fragments is obtained. S13. Based on the total number of fragments, extract 8-byte segments from the first byte of the UART format data packet, and take the actual remaining bytes for the last segment to obtain the fragment byte array. S14. Encapsulate each fragment in the fragment byte array into a CAN extended frame sequence, and send the CAN extended frame sequence according to the fragment sequence number.

[0021] In this example, the transmitter first receives a complete UART format data packet at the CAN relay adapter layer and parses the preamble field according to the predetermined frame structure. The protocol header occupies 2 bytes, with a value of 0xAA55 or 0xAA66. The data length field occupies 2 bytes, using a high-byte-first representation. The value given in the data length field is denoted as... , This represents the total number of bytes from the function code to the end code 0x77. Therefore, the total number of bytes in the data packet is... , The fixed 4-byte increment corresponds to the fixed number of bytes occupied by the protocol header field and the data length field, representing the total length of a complete UART format data packet. After obtaining... Next, the number of fragments is calculated, with the fixed payload length set to 8 bytes, and the total number of fragments calculated as follows: Rounding down For the required number of CAN extended frames, when When the value is exactly a multiple of 8, each frame loads 8 bytes. When the remainder after dividing by 8 is not 0, the last frame only loads the remaining valid bytes, thus satisfying the CAN single-frame payload limit while avoiding meaningless padding in intermediate segments. The segmented byte array is constructed according to the first byte priority and continuous truncation method. The starting byte position of each fragment is The end position is the last valid byte that does not exceed the total length boundary, and the fragment sequence number. Incrementing from 0 to The corresponding actual number of bytes loaded is denoted as ,when Time to take ,when and Time to take ,when The last piece was still taken After fragmentation is completed, the encapsulation and transmission stage begins. Each fragment is sequentially filled with the data field of a CAN extended frame, and the data length code is set to the corresponding value. Then according to Set the extended frame identifier. For the first Each fragment corresponds to a 29-bit extended frame identifier, with a fixed base value of [value missing]. The CAN bus operates using extended frame format, a 29-bit ID, and a 250kbps baud rate. The lower 8 bits of the fragment sequence number naturally form a position index from 0x00 to 0xFF. The receiving side can subsequently recover the byte write offset position simply by using the ID difference. No additional bytes are used within the data field to store sequence number information; therefore, the entire 8-byte payload can be used to carry the original service data. In terms of transmission control, the CAN controller sequentially sends out the encapsulated CAN extended frames according to the fragment sequence number from smallest to largest, until... After all fragments have been sent, when You can continue to send IDs. The end signaling is used to indicate the completion of a round of transmission, when The last data shard itself already corresponds The sending side does not need to add an extra end frame; combined with to A continuous range of 256 IDs, with a maximum data size carried by a single transparent process reaching [number missing]. Throughout the entire transmission process, the original byte order of the UART service frame remains unchanged. The function code, data field, CRC16 check field, and end code are all arranged in their original order and enter the fragmentation sequence.

[0022] In one example, each fragment in the fragmented byte array is encapsulated into a CAN extended frame sequence, and the CAN extended frame sequence is sent according to the fragment sequence number, including: Each fragment in the fragmented byte array is encapsulated into a CAN extended frame sequence; Send the CAN extended frame sequence according to the fragment sequence number. After all the CAN extended frame sequences have been sent, construct the end frame and send it. The data field of the end frame does not contain any content in the fragment byte array.

[0023] In this example, after receiving the fragmented byte array, the sender uses the fragment sequence number... As a frame-by-frame encapsulation index, It is a natural number, with an initial value of 0 and an ending value of 0. , This represents the total number of fragments. For any fragment corresponding to a sequence number, all valid bytes within the fragment are filled into the data field of a CAN extended frame in their original order, and the data length code is set to the actual number of bytes in the current fragment. The data length code corresponding to a complete 8-byte fragment is fixed at 8, and the data length code corresponding to fragments ending in less than 8 bytes is directly written into the remaining valid bytes, ensuring that the byte arrangement of the UART format data packet maintains continuous mapping on the CAN side. After completing the data field loading, a 29-bit extended frame identifier is set for each frame. The identifier corresponding to each fragment is written as ,in As the base identifier, the lower 8 bits naturally form a position index as the fragment number increases, therefore the 0th fragment corresponds to... The first fragment corresponds to This process is repeated until all data fragments are encapsulated. During the transmission phase, the CAN controller sends out the encapsulated CAN extended frames in ascending order of fragment number. Communication parameters remain the extended frame format, baud rate of 250kbps, and a fixed payload limit of 8 bytes per frame. The transmission order matches the fragment number order. The receiving end can then recover the original byte positions using only the ID difference, without needing to insert an additional sequence number field in the data field. All valid content of the fragment byte array can directly carry the service data. After the last data fragment is transmitted, the transmitting end constructs a dedicated end frame. The identifier of the end frame is the sum of the base identifier and the preset offset upper limit value, which is fixed at 255. Therefore, the end frame identifier is... When the end frame is sent, no content is written to the fragment byte array. The data field of the end frame only retains the end trigger semantics and does not undertake the task of business data transmission. The receiving end captures the end frame's data. Then, the current splicing and receiving process can be determined as the end of one round of transmission, and the process can proceed to the subsequent reassembly and verification. Combined with... to A total of 256 consecutive identifiers and The fixed byte concatenation capacity allows for a maximum single-round transmission length of 2048 bytes. When the actual business data has been sent within a few fragments, the end frame can be sent immediately without waiting for the entire bit field to be filled. For typical scenarios with a total number of fragments less than 256, Keep it as a dedicated end frame; when the total number of fragments reaches exactly 256. The last data fragment has been occupied. At this point, the last frame, after writing the last piece of valid data, also has the meaning of an end marker. No additional end frames will be sent repeatedly. The entire transmission link still maintains the consistency of encapsulation rules, position index rules, and end trigger rules.

[0024] In one example, such as Figure 3 The fragments in the fragmented byte array are encapsulated into a CAN extended frame sequence, including: S101. Using the slice number i as the index, fill all the bytes of the i-th slice in the slice byte array into the data field of a CAN extended frame in sequence, and set the data length code of the corresponding CAN extended frame to the actual number of bytes of the i-th slice, so as to obtain the CAN extended frame with the data field and data length code set. S102. Set the ID of the CAN extended frame with the data field and data length code set to the sum of the base ID and the fragment number i, and obtain the CAN extended frame with the ID set. S103. Increment the fragment sequence number i by 1, and repeat S101 to S102 for the next fragment in the fragment byte array until all fragments within the total number of fragments are encapsulated, and obtain the CAN extended frame sequence.

[0025] In this example, after the sending end's relay adaptation layer completes the generation of the fragmented byte array, it sets the fragment sequence number... Initialize to 0, and use the total number of fragments as the loop termination boundary. Upon entering each encapsulation round, first read the fragment byte array with the sequence number... The target fragment is written byte by byte into the data field of a CAN extended frame in its original order, without changing the byte arrangement or inserting additional sequence number bytes, control flag bytes, or supplementary function fields into the data field, maintaining the consistency of the UART format data packet content before and after the transport layer split; the data length code set synchronously with the data field is directly taken from the first byte. The actual number of bytes in the i-th slice, when the i-th slice When the first fragment is a complete fragment, the data length code is fixed at 8. When the last fragment is the remaining fragment, the data length code is written as the number of remaining valid bytes. This allows the receiver to accurately recover the valid boundary of the last fragment during the reassembly phase based on the data length code, without having to make additional guesses about the end of the data field. After the data field and data length code are written, identifier mapping is performed, and the ID of the CAN extended frame is determined according to... Settings, in which As the base ID, the preset value is taken as follows: , Given the current fragment sequence number, the extended frame ID corresponding to the 0th fragment is... The extended frame ID corresponding to the first fragment is The numbers increment sequentially until the last fragment. Under this mapping rule, the lower 8 bits of the 29-bit extended frame ID automatically form the fragment position index. The receiving end only needs to subtract the received frame ID from the base ID to restore the current fragment's sequential position in the original byte stream. Therefore, the entire 8-byte data field is used to carry valid service content, avoiding the payload compression caused by "saving the sequence number in the first byte of the data field". After completing the encapsulation of a frame, the fragment sequence number is... Increment by 1, and repeat the data field filling, data length code setting, and ID mapping for the next fragment in the fragment byte array until... Until the maximum number of fragments is reached, a sequentially arranged CAN extended frame sequence is obtained; the CAN communication parameters are preset to extended frame mode, single frame payload maximum of 8 bytes, baud rate of 250kbps, and ID pool range of [missing information]. to It occupies a total of 256 consecutive IDs, corresponding to a maximum concatenation capacity of [missing information]. Therefore, during the encapsulation stage, it is synchronously determined whether the total number of fragments exceeds 256. If it does, it is directly determined that the length of the current UART format data packet exceeds the limit and will not enter the subsequent transmission process. If it does not exceed the limit, the fragment encapsulation mechanism continues to run until a complete CAN extended frame sequence is formed.

[0026] In one example, the CAN extended frame sequence is sent according to the fragment sequence number. After the entire CAN extended frame sequence has been sent, an end frame is constructed and sent. The data field of the end frame does not contain any content from the fragment byte array, including: According to the fragment sequence number, each CAN extended frame in the CAN extended frame sequence is sent sequentially through the CAN controller until all CAN extended frames corresponding to the total number of fragments have been sent. After the entire CAN extended frame sequence has been sent, an empty data field is constructed as an end frame. The ID of the end frame is set to the sum of the base ID and the preset offset upper limit value. The end frame is then sent through the CAN controller. The data field of the end frame is not written with any content in the fragment byte array.

[0027] In this example, after forming a sequence of CAN extended frames arranged by fragment number, the transmitting end keeps the transmission index consistent with the fragment number and writes each frame into the CAN controller's transmission mailbox in ascending order of sequence number. The CAN controller operates in extended frame mode, maintains a communication baud rate of 250kbps, and uses a fixed base ID of 0x18000000. Therefore, the transmission frame ID corresponding to the i-th fragment is still 0x18000000+i. The transmission order is consistent with the byte array segmentation order. The receiving side can directly restore the fragment position based on the ID difference during subsequent reassembly without needing to append sequence number information to the data field. The entire 8-byte payload space is reserved for the original content of the UART format data packet. As the transmission index continues to increase until it reaches the boundary of the total number of fragments, all CAN extended frames corresponding to the total number of fragments have completed one round of transmission. After the signal is sent, the termination trigger phase begins. The termination frame no longer loads any bytes from the fragmented byte array and does not carry out any business data transmission tasks. The termination frame only serves as a boundary marker for the completion of this round of data splicing. The preset upper limit of the offset is fixed at 255, so the termination frame ID is set to 0x18000000+255, i.e., 0x180000FF. Once the receiving side captures 0x180000FF, it can transfer the current buffer content to the reassembly and verification process. If the control method of "data field empty" is strictly followed, the data length code of the termination frame can be directly set to 0, making the termination frame a pure termination signaling frame. If the underlying driver still maintains that the termination signaling frame occupies 1 frame of CAN message resources, the data field buffer of the termination frame must not be written with any content from the fragmented byte array. The receiving side only recognizes the termination frame ID and does not regard the termination frame data field as a valid business payload. Since the cached frame ID ranges from 0x18000000 to 0x180000FF, occupying a total of 256 consecutive IDs, the maximum transmission limit for a single round of splicing is 2048 bytes. In actual transmission, the end frame can be sent immediately after all valid data fragments have been sent, without waiting for the entire ID space to be filled. Therefore, when the number of fragments is 1, 1 data frame plus 1 end frame is sent; when the number of fragments is 20, 20 data frames plus 1 end frame are sent. The transmission process always maintains the same set of ID mapping rules and end judgment rules.

[0028] In one example, such as Figure 4 The receiving end captures CAN extended frames whose IDs fall within the range of the base ID to the end frame ID, and writes the data field content of each CAN extended frame into the reassembly buffer to obtain the reassembly buffer data, including: S21. The receiving end captures CAN extended frames whose IDs fall within the range of the reference ID to the ID of the end frame, and calculates the buffer write offset for each captured CAN extended frame. S22. Write the data field content of each CAN extended frame into the reassembly buffer, which is a continuous byte area starting from the buffer write offset of each CAN extended frame multiplied by the fixed payload length. S23. When the write offset of the CAN extended frame buffer is zero, clear the reassembly buffer and then write it again. Write the CAN extended frames in the order they arrive until the end frame is received to obtain the reassembly buffer data.

[0029] In this example, the receiver first configures the ID filtering range on the CAN controller side, fixing the starting value of the filter to the base ID 0x18000000 and the ending value to the ending frame ID 0x180000FF. This ensures that the receiver only receives extended frames falling within the range of 0x18000000 to 0x180000FF, discarding other irrelevant messages at the hardware layer. Then, at the software layer, a 2048-byte reassembly buffer is allocated for this round of splicing, and the number of bytes already written is initialized to 0. When any target CAN extended frame arrives, the buffer write offset is calculated based on the frame ID, and the calculation relationship is written as follows: In the formula, Write the offset to the buffer. The ID of the currently received frame. The base ID is fixed at 0x18000000. Since the transit ID pool continuously occupies 256 IDs... The value range is 0 to 255, where 0 corresponds to the start fragment position and 255 corresponds to the end boundary position. After obtaining the offset, the starting byte position of the current fragment in the reassembly buffer is calculated, and the calculation relationship is written as follows: In the formula, The starting byte write position is given, and the fixed payload length is 8 bytes. Therefore, when Writes start from byte 0 in the buffer. Write starting from byte 8, when The receiving end starts writing from byte 16, and so on, writing all valid bytes in the current CAN extended frame data field sequentially according to the actual number of bytes given by the data length code. Within the initial contiguous byte region, the original UART byte stream is kept in its original order after reassembly. To prevent splicing contamination caused by out-of-order fragmentation, frame loss, or remnants, the receiving end performs a continuity check on the current offset and the currently written state before writing. The check relationship is written as follows: In the formula, The number of bytes written to the reassembly buffer is used to determine the sequence number of the current frame. When this relationship is true, it indicates that the current frame is a contiguous fragment of the next frame that should arrive. The receiving end can then append the current frame data and update the number of bytes written to the sum of the original value and the current data length code. When this relationship is false, it indicates that the current frame sequence number is not contiguous. The receiving end directly determines that this round of reassembly has failed, immediately clears the reassembly buffer, resets the number of bytes written to 0, and then waits for the arrival of the next starting frame with a buffer write offset equal to 0 before restarting the new round of writing. When the receiving end captures the starting frame with ID 0x18000000, regardless of whether the previous round of transmission has completely ended, it first performs buffer clearing and write status reset, and then writes the data field of the current frame to the header area of ​​the buffer. This ensures that the new round of splicing always starts from a clean buffer and also forces the discard of residual fragments in the event of an abnormal interruption in the previous round, avoiding the mixing of old and new data. Subsequently, each subsequent fragment continues to be written in the order of arrival until the end frame 0x180000FF is received, thus obtaining the complete reassembly buffer data. When the total number of fragments is less than 256, 0x180000FF is only used as a transmission end trigger signal. After the receiver recognizes the frame, it proceeds to subsequent parsing and verification processing. When the total number of fragments in a single round is exactly equal to 256, the frame with ID 0x180000FF carries both the last data fragment and the end semantics. The receiver first writes the data field of the frame into the end area of ​​the buffer according to the aforementioned offset rules, and then immediately submits the contents of the current buffer as the complete reassembly result of this round for subsequent processing.

[0030] In one example, the receiver captures CAN extended frames whose IDs fall within the range of the base ID to the end frame ID. For each captured CAN extended frame, a buffer write offset is calculated, including: Write the ID filter register to the CAN controller, set the filter start value to the base ID and the filter end value to the ID of the end frame, so that the CAN controller discards all CAN messages whose IDs are not in the range of the base ID to the ID of the end frame at the hardware level, and the receiving end captures CAN extended frames whose IDs fall within the range of the base ID to the ID of the end frame. For each captured CAN extended frame, the difference between the CAN extended frame ID and the reference ID is used to obtain the buffer write offset, and it is verified whether the buffer write offset is equal to the quotient of the number of bytes written to the reassembly buffer divided by the fixed payload length. If they are not equal, it is determined that the frame sequence number of the CAN extended frame is not continuous. The reassembly buffer is cleared and the number of bytes written is reset to zero. The writing is retried after the next CAN extended frame with a write offset of zero arrives in the buffer.

[0031] In this example, the receiver completes the hardware filtering configuration of the CAN controller during the initialization phase. It sets the starting value of the ID filter register to the base ID 0x18000000 and the ending value to the ending frame ID 0x180000FF. This ensures that only CAN messages with IDs falling within the range of 0x18000000 to 0x180000FF enter the receiving processing channel. Other CAN messages with IDs outside this range are discarded at the hardware layer and do not enter the software parsing path. This isolates the relay splicing service from the services of other devices on the same bus, while reducing the burden of software polling and frame judgment on the receiver. After the filtering rules are written, the receiver pre-allocates a 2048-byte reassembly buffer, sets the number of bytes already written to 0, resets the receiving state to idle, and then waits for the start frame to arrive. Whenever a CAN extended frame that meets the filtering range is captured, the receiver first performs buffer write offset calculation, the calculation relationship is written as follows: ,in, Indicates the buffer write offset. Indicates the ID of the currently received frame. Indicates the base ID, which is fixed. Therefore, the ID is The frame corresponds to offset 0, and the ID is The frame corresponds to an offset of 1, and so on, with ID as... The frame corresponds to an offset of 255. This difference directly reflects the position number of the current fragment in the entire splicing sequence, eliminating the need to set an additional fragment number field in the data field. The entire 8-byte fixed payload length can be used to carry valid service data. After obtaining the offset, the receiving end performs a continuity check, and the check relationship is written as follows: ,in, This indicates the number of bytes written to the reassembly buffer. The fixed payload length is 8 bytes. When the current offset matches the quotient obtained by dividing the number of bytes written by the fixed payload length, it means that the current received frame corresponds to the next consecutive fragment, and the receiver can continue the writing process. When the two are not equal, it is determined that the frame sequence number of the current CAN extended frame is not consecutive, which means that frame loss, out-of-order arrival, or cross-round residual interference has occurred during transmission. At this time, it is no longer allowed to continue splicing the old buffer content. Instead, the 2048-byte reassembly buffer is immediately cleared, the number of bytes written is reset to 0, and the receiving state is set back to idle. The current abnormal fragment will no longer be accepted into the existing splicing result. Instead, it waits for the next frame buffer to write the CAN extended frame with an offset of 0 to trigger a new round of writing process. For frames with an offset of 0, the receiver considers this frame the start of a new round of transmission. Even if the previous round of transmission has not yet ended normally, it first clears the buffer and resets the count, then writes the data field of the current frame into the header area of ​​the reassembly buffer, storing it sequentially starting from byte 0, and updating the number of bytes written to the actual number of bytes corresponding to the current data length code. For ordinary fragments with an offset greater than 0 that have not yet reached the end position, after the continuity check passes, the receiver writes the data field of the current frame into the corresponding consecutive byte area of ​​the reassembly buffer starting at an offset multiplied by 8, thus ensuring that the arrangement order of all fragments in the reassembly buffer is consistent with the fragmentation order of the sender. For the end frame... The receiving end determines the end semantics based on the current total number of fragments. In the normal scenario where the total number of fragments is less than 256, this frame is regarded as the transmission completion trigger. In the scenario where the total number of fragments is exactly equal to 256, subsequent parsing is triggered immediately after the last piece of data is written.

[0032] In one example, such as Figure 5 Upon receiving the end frame, the data in the reassembled buffer is verified. After all verifications pass, the reassembled buffer data is submitted to the BMS application layer protocol stack, including: S31. After receiving the end frame, perform protocol header validity verification and data length consistency verification on the reassembled buffer data to obtain the total number of bytes in the frame; S32. Based on the total number of bytes in the frame, extract the two bytes located at the CRC field position from the reassembly buffer data as the received check value, and perform the ModBus CRC16 algorithm on all bytes before the start position of the CRC field in the reassembly buffer data to obtain the calculated check value; S33. Compare the received check value with the calculated check value. After the check value comparison is successful, check whether the last byte of the reassembled buffer data is the end code. If so, submit the reassembled buffer data to the BMS application layer protocol stack.

[0033] In this example, after the receiver identifies the end frame ID as 0x180000FF, it proceeds to the complete frame verification process. The verification entry point first checks the first two bytes of the reassembly buffer for protocol header validity. If the first two bytes are 0xAA55, it's determined to be the default protocol header type; if they are 0xAA66, it's determined to be the transparent protocol header type. If the first two bytes do not belong to either of these preset values, the current concatenation result is directly deemed invalid, the reassembly buffer is cleared, and the number of bytes written is reset to 0. After the protocol header passes, the data length field, composed of the third and fourth bytes, is read. The data length field uses a high-byte-first representation, and its range is fixed to the total number of bytes from the function code byte to the end code 0x77. The value of the data length field is recorded as... ,in Indicates the valid protocol length identified by the data length field, followed by... Calculate the total number of bytes in the complete frame, where This indicates the total length of the complete UART service frame. The fixed 4-byte increment corresponds to the 2-byte protocol header field and the 2-byte data length field; the receiving end then... A consistency check is performed between the current number of bytes written to the reassembly buffer and the data length consistency check result. Only if the two are exactly equal is the data length consistency check considered successful, and the data length is then... This serves as a unified length benchmark for CRC extraction and end-of-cycle code location. After length confirmation, the receiving end uses... Two bytes located at the CRC field position are extracted from the reassembly buffer as the received checksum. Specifically, the extraction positions are the third-to-last byte and the second-to-last byte, where the third-to-last byte is the low CRC byte and the second-to-last byte is the high CRC byte. The received checksum is formed by combining these bytes in a low-byte-first order. This received checksum is denoted as... Simultaneously, the receiving end performs ModBus CRC16 operations on all bytes in the reassembly buffer from byte 0 to the byte preceding the start position of the CRC field. The total number of bytes involved in the operation is... Since the last 3 bytes correspond to the CRC low byte, CRC high byte, and end code respectively, they are not included in the recalculation range. The calculation process uses a preset initial value of 0xFFFF as the initial value of the check register, and this register is denoted as... Then, read the input data byte by byte in sequence, and record the current input byte as... For each Perform bit processing 8 times consecutively, each time first checking... and The XOR result is checked against the least significant bit. If the least significant bit is 1, a right shift is performed and XORed with 0xA001. If the least significant bit is 0, only a right shift is performed. Then... Shift right by 1 bit until all bytes have been processed, then... The high and low bytes are swapped and output to obtain the calculated check value. .right and A value-by-value comparison is performed. Only if the two values ​​are completely identical is it determined that the reconstructed byte stream has not been corrupted during CAN transmission and reconstruction. If the two values ​​are inconsistent, the current buffer data is immediately discarded, and the number of bytes written is cleared to zero. After the CRC check passes, the reconstructed buffer is read again. One byte is used as the end marker of the frame, and it is determined whether the byte is equal to the preset end code 0x77. Only if the end code verification is successful will the current reassembled buffer data be submitted to the BMS application layer protocol stack, and the application layer will continue to perform function code recognition, register mapping and business processing.

[0034] In one example, after receiving the end frame, the data in the reassembly buffer is checked for protocol header validity and data length consistency to obtain the total number of bytes in the frame, including: Upon receiving the end frame, the first two bytes of the reassembled buffer data are checked for protocol header validity. After the protocol header validity check passes, a protocol header type flag is generated. Based on the protocol header type flag, the data length field value composed of the third and fourth bytes of the reassembled buffer data is read, and the data length field value is added to the fixed number of bytes occupied by the protocol header field and the data length field to obtain the total number of bytes in the frame; If the total number of bytes in the frame is equal to the number of bytes already written in the reassembly buffer, then the data length consistency check is passed, and the total number of bytes in the frame is obtained.

[0035] In this example, after the receiving end recognizes the end frame 0x180000FF, it freezes the byte stream in the current reassembly buffer as data to be verified, and first reads the first two bytes as the protocol header field for legality verification. When the first two bytes are 0xAA55, a default protocol header type flag is generated; when the first two bytes are 0xAA66, a pass-through protocol header type flag is generated. If the first two bytes do not belong to the two preset values ​​of 0xAA55 and 0xAA66, the current reassembly result is immediately determined to be invalid, the reassembly buffer is cleared, and the number of bytes written is reset to 0, and the subsequent length parsing process is no longer entered. After the protocol header verification passes, the receiving end continues to read the data length field composed of the third and fourth bytes. The data length field adopts the high byte-first representation method, and the range is fixed to the total number of bytes from the function code byte to the end code 0x77. The value of the data length field is denoted as L, where L represents the valid data length declared by the protocol. The 2 bytes fixedly occupied by the protocol header field and the 2 bytes fixedly occupied by the data length field are included in the total length. The total number of bytes of the frame is calculated according to T=L+4, where T represents the total length of the complete service frame. The fixed increase of 4 bytes is the fixed number of bytes occupied by the protocol header field and the data length field. The receiving end then compares T with the number of bytes currently written to the reassembly buffer. Only when the two are completely equal is the data length consistency check confirmed, and T is used as the unified length benchmark for CRC field positioning, end code positioning, and whole frame submission judgment. If the two are not equal, it means that the current reassembled byte stream is inconsistent with the length declared in the protocol header. The receiving end then determines that there is frame loss, out-of-order, or tail incompleteness in this round of splicing, directly discards the current buffer content, and restores the receiving state to the initial state of waiting for the next starting frame.

[0036] Reference Figure 6 This embodiment provides a CAN and UART protocol processing system, including: The segmentation and transmission module 1 is used to segment UART format data packets into a segmented byte array, encapsulate each segment in the segmented byte array into a CAN extended frame sequence, and transmit the CAN extended frame sequence according to the segment sequence number. Reassembly buffer module 2 is used by the receiving end to capture CAN extended frames whose IDs fall within the range of the reference ID to the end frame ID, and write the data field content of each CAN extended frame into the reassembly buffer to obtain the reassembly buffer data; The verification and submission module 3 is used to verify the reassembled buffer data after receiving the end frame, and submit the reassembled buffer data to the BMS application layer protocol stack after all verifications pass.

[0037] In this embodiment, the specific implementation of each unit in the above system embodiment is described in the above method embodiment, and will not be repeated here.

[0038] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, system, article, or method that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, system, article, or method. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, system, article, or method that includes that element.

[0039] The above description is only a preferred embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for processing CAN and UART protocols, characterized in that, include: The UART format data packet is segmented into a fragmented byte array, and each fragment in the fragmented byte array is encapsulated into a CAN extended frame sequence. The CAN extended frame sequence is sent according to the fragment sequence number. The receiving end captures CAN extended frames whose IDs fall within the range of the base ID to the end frame ID, and writes the data field content of each CAN extended frame into the reassembly buffer to obtain the reassembly buffer data; Upon receiving the end frame, the data in the reassembled buffer is verified. After all verifications pass, the data in the reassembled buffer is submitted to the BMS application layer protocol stack.

2. The CAN and UART protocol processing method according to claim 1, characterized in that, The step of segmenting UART format data packets into fragmented byte arrays, encapsulating each fragment in the fragmented byte array into a CAN extended frame sequence, and sending the CAN extended frame sequence according to the fragment sequence number includes: Read the data length field in the UART format data packet, add the value of the data length field to the fixed number of bytes occupied by the protocol header field and the data length field, and get the total number of bytes in the data packet; The total number of bytes in the data packet is divided by 8 bytes as a fixed payload length. Any remainder less than 8 bytes is counted as a fragment, and the total number of fragments is obtained. Based on the total number of fragments, 8-byte segments are sequentially extracted from the first byte of the UART format data packet, and the last segment is the actual remaining bytes, to obtain the fragment byte array; Each fragment in the fragmented byte array is encapsulated into a CAN extended frame sequence, and the CAN extended frame sequence is sent according to the fragment sequence number.

3. The CAN and UART protocol processing method according to claim 2, characterized in that, The step of encapsulating each fragment in the fragmented byte array into a CAN extended frame sequence and sending the CAN extended frame sequence according to the fragment sequence number includes: Each fragment in the fragmented byte array is encapsulated into a CAN extended frame sequence; The CAN extended frame sequence is sent according to the fragment sequence number. After the entire CAN extended frame sequence has been sent, an end frame is constructed and sent. The data field of the end frame is not written with any content in the fragment byte array.

4. The CAN and UART protocol processing method according to claim 3, characterized in that, The step of encapsulating each fragment in the fragmented byte array into a CAN extended frame sequence includes: S101. Using the segment number i as an index, fill all the bytes of the i-th segment in the segment byte array into the data field of a CAN extended frame in sequence, and set the data length code of the corresponding CAN extended frame to the actual number of bytes of the i-th segment, so as to obtain the CAN extended frame with the data field and data length code set. S102. Set the ID of the CAN extended frame with the data field and data length code set to the sum of the base ID and the fragment number i to obtain the CAN extended frame with the ID set. S103. Increment the fragment sequence number i by 1, and repeat S101 to S102 for the next fragment in the fragment byte array until all fragments within the total number of fragments are encapsulated, thus obtaining the CAN extended frame sequence.

5. The CAN and UART protocol processing method according to claim 4, characterized in that, The step of sending the CAN extended frame sequence according to the fragment sequence number, and constructing and sending an end frame after all the CAN extended frame sequences have been sent, wherein the data field of the end frame does not contain any content in the fragment byte array, including: According to the fragment sequence number, each CAN extended frame in the CAN extended frame sequence is sent sequentially through the CAN controller until all the CAN extended frames corresponding to the total number of fragments have been sent. After the entire CAN extended frame sequence has been sent, an empty data field is constructed as an end frame. The ID of the end frame is set to the sum of the reference ID and the preset offset upper limit value. The end frame is then sent through the CAN controller. The data field of the end frame is not written with any content in the fragment byte array.

6. The CAN and UART protocol processing method according to claim 5, characterized in that, The receiving end captures CAN extended frames whose IDs fall within the range of the base ID to the end frame ID, and writes the data field content of each CAN extended frame into the reassembly buffer to obtain reassembly buffer data, including: The receiver captures CAN extended frames whose IDs fall within the range of the base ID to the end frame ID, and calculates the buffer write offset for each captured CAN extended frame. Write the data field content of each CAN extended frame into a reassembly buffer, with the buffer write offset of each CAN extended frame multiplied by the fixed payload length as the starting byte position of a continuous byte region; When the write offset of the CAN extended frame buffer is zero, the reassembly buffer is cleared and then written again. The CAN extended frames are written sequentially according to their arrival order until the end frame is received, thus obtaining the reassembly buffer data.

7. The CAN and UART protocol processing method according to claim 6, characterized in that, The receiver captures CAN extended frames whose IDs fall within the range of the base ID to the end frame ID, and calculates a buffer write offset for each captured CAN extended frame, including: Write an ID filter register to the CAN controller, set the filter start value to the reference ID and the filter end value to the ID of the end frame, so that the CAN controller discards all CAN messages whose IDs are not within the range of the reference ID to the ID of the end frame at the hardware layer, and the receiving end captures CAN extended frames whose IDs fall within the range of the reference ID to the ID of the end frame. For each captured CAN extended frame, the ID of the CAN extended frame is subtracted from the reference ID to obtain the buffer write offset, and it is verified whether the buffer write offset is equal to the quotient of the number of bytes written to the reassembled buffer divided by the fixed payload length. If they are not equal, it is determined that the frame sequence number of the CAN extended frame is not continuous. The reassembly buffer is cleared and the number of bytes written is reset to zero. The writing is retried after the next CAN extended frame with a write offset of zero arrives in the buffer.

8. The CAN and UART protocol processing method according to claim 1, characterized in that, Upon receiving the end frame, the reassembled buffer data is verified. After all verifications pass, the reassembled buffer data is submitted to the BMS application layer protocol stack, including: Upon receiving the end frame, the protocol header validity and data length consistency are checked on the reassembled buffer data to obtain the total number of bytes in the frame. Based on the total number of bytes in the frame, two bytes located at the CRC field position are extracted from the reassembled buffer data as the received check value. The ModBus CRC16 algorithm is executed on all bytes before the start position of the CRC field in the reassembled buffer data to obtain the calculated check value. The received verification value is compared with the calculated verification value. After the verification value comparison is successful, the last byte of the reassembled buffer data is checked to see if it is an end code. If it is, the reassembled buffer data is submitted to the BMS application layer protocol stack.

9. The CAN and UART protocol processing method according to claim 8, characterized in that, Upon receiving the end frame, the protocol header validity and data length consistency are checked on the reassembled buffer data to obtain the total number of bytes in the frame, including: Upon receiving the end frame, the first two bytes of the reassembled buffer data are checked for protocol header validity. After the protocol header validity check passes, a protocol header type flag is generated. Based on the protocol header type marker, the data length field value composed of the third and fourth bytes of the reassembled buffer data is read, and the data length field value is added to the fixed number of bytes occupied by the protocol header field and the data length field to obtain the total number of bytes in the frame; If the total number of bytes in the frame is equal to the number of bytes already written in the reassembly buffer, then the data length consistency check is passed, and the total number of bytes in the frame is obtained.

10. A CAN and UART protocol processing system, characterized in that, The steps for implementing the CAN and UART protocol processing method according to any one of claims 1 to 9 include: The segmentation and transmission module is used to segment UART format data packets into a segmented byte array, encapsulate each segment in the segmented byte array into a CAN extended frame sequence, and transmit the CAN extended frame sequence according to the segment sequence number. The reassembly buffer module is used by the receiving end to capture CAN extended frames whose IDs fall within the range of the base ID to the end frame ID, and write the data field content of each CAN extended frame into the reassembly buffer to obtain the reassembly buffer data. The verification and submission module is used to verify the reassembled buffer data after receiving the end frame, and submit the reassembled buffer data to the BMS application layer protocol stack after all verifications pass.

Images