Vehicle-mounted hex program file rewriting method and related equipment

Abstract

The invention relates to the technical field of automotive electronics, and discloses a vehicle-mounted hex program file rewriting method and related equipment.The method comprises the steps that according to ECU addresses of the to-be-rewritten amount in a protocol table, the to-be-rewritten amount is ranked, and a bisection method is used for rapidly rewriting a single hex program file; creating a thread pool, constructing a task queue in the thread pool, and storing a plurality of to-be-processed hex program file tasks in the task queue; and a plurality of to-be-processed hex program file tasks complete rapid rewriting of batch hex program files according to a rapid rewriting mode of a single hex program file in combination with a multi-thread concurrent technology. According to the method, the to-be-rewritten amount is sorted according to the ECU address of the to-be-rewritten amount in the protocol table, and the part needing to be rewritten is quickly positioned by using the dichotomy, so that the rewriting efficiency of a single hex program file is improved. And creating a thread pool and processing batch hex program files by using a multi-thread concurrent technology to realize parallel processing and shorten the overall rewriting time.

Description

Technical Field

[0001] The present invention relates to the field of automotive electronics technology, and specifically to a method for rewriting in-vehicle hex program files and related devices. Background Art

[0002] In the field of automotive calibration and control system development, in view of the diversification of different vehicle models, working conditions or customer requirements, the optimization of control algorithm parameters is a crucial and continuous complex task. These key parameters are usually encapsulated in hex program files with complex structures and are not easily directly accessible, which requires developers to rely on specific parsing tools to effectively read and modify them.

[0003] Traditionally, developers mainly rely on tools such as CANape CDM to individually adjust the variable parameters in hex program files. However, this method not only has high equipment costs but also low operating efficiency, greatly limiting the speed and flexibility of the development process. Especially when a large number of parameters need to be adjusted or modified, its limitations are particularly prominent.

[0004] With the continuous progress of automotive software development technology, many automobile manufacturers have begun to adopt the Autosar hierarchical architecture to improve the modularity and reusability of software development. Under this architecture, application layer software is usually developed through modeling tools such as Simulink, while the underlying software is implemented using the C language. Finally, these software modules are integrated and generated into Hex program files through compilation tools such as Hightec for use in vehicle control systems.

[0005] However, this traditional development method also faces significant efficiency bottlenecks. Especially in the software release stage, due to the long time-consuming for compiling and rewriting programs (the average time-consuming for compiling a program is about 20 minutes, and it takes 30 minutes to rewrite a program once), when frequent or batch modification of Hex program files is required, the overall development efficiency will drop significantly. For example, in a scenario where 20 hex program files need to be rewritten in batch, the total rewriting time may exceed 2 hours, which is undoubtedly a huge challenge for quickly responding to market demands and shortening the product launch cycle.

[0006] To address this challenge, the industry has tried some improvement solutions. Among them, the hex program file rewriting program based on MFC (Microsoft Foundation Class) is a typical example. This program has successfully shortened the rewriting time of a single hex program file to 5 minutes by optimizing the rewriting process, which has improved the development efficiency to a certain extent. However, with the increasing complexity and customization requirements of automotive control systems, even this improved solution is difficult to meet the needs of frequent or large-scale rewriting of Hex program files.

[0007] Therefore, developing a more efficient, flexible and cost-controlled hex program file parsing and rewriting technology has become a key issue that needs to be urgently solved in the current field of automotive calibration and control system development. Summary of the invention

[0008] The object of the present invention is to provide a vehicle-mounted hex program file rewriting method and related equipment to solve the technical problem of how to improve the rewriting efficiency of single and batch hex program files.

[0009] The present invention is achieved through the following technical solutions: In a first aspect, the present invention provides a method for rewriting a vehicle-mounted hex program file, comprising: Sort the amount to be rewritten according to the ECU address of the amount to be rewritten in the protocol table, and use the binary method to quickly rewrite a single hex program file; A thread pool is created, and a task queue is constructed in the thread pool, wherein the task queue stores a number of hex program file tasks to be processed; the number of hex program file tasks to be processed completes the rapid rewriting of batch hex program files based on the rapid rewriting method of a single hex program file combined with multi-threaded concurrent technology.

[0010] Preferably, in the step of sorting the amounts to be rewritten according to the ECU addresses of the amounts to be rewritten in the protocol table, and quickly rewriting a single hex program file using a binary search method, the specific process is as follows: S1, read the name of the value calibration quantity to be rewritten and the value to be rewritten from the protocol table; S2, correspond the name of the value calibration quantity to be rewritten to the matching variable name in A2L, and obtain the 32-bit ECU absolute address of the variable name to be rewritten and the variable data type; S3, locating the block segment to which the variable belongs through the 32-bit ECU absolute address of the variable name to be rewritten, wherein the locating method is that the 32-bit ECU absolute address of the variable name to be rewritten is greater than or equal to the starting address of the block segment and less than or equal to the ending address of the block segment; S4, sort the address of each variable, and according to the block segment to which the located variable belongs, use the start index row of the sorted block segment as the left boundary of the binary search, and use the end index of the block segment as the right boundary of the binary search; after performing several binary searches according to the left and right boundaries of the binary search, determine the specific record row number where the variable to be rewritten is located; when the condition for terminating the search is met, the 32-bit ECU absolute address of the variable name to be rewritten is greater than or equal to the start index of the current binary search row record, and less than or equal to the end index of the current binary search row record; S5. Combine the value to be rewritten with the data type to convert it into a hexadecimal value, and then convert it into the corresponding hexadecimal string. Record the rewritten content and the corresponding address in bytes. Use the binary search method to obtain the record rewrite line of record, and perform loop-by-byte rewriting until the loop ends, completing the rapid rewriting of a single hex program file.

[0011] Further, in the step of locating the block segment to which the variable belongs through the 32-bit ECU absolute address of the variable to be rewritten, the specific process is as follows: S31. Read the content of the hex program file to be flashed generated by each controller line by line, where each line includes a record type, address information, and data content; S32. Distinguish according to the field of the record type in each line to obtain the distinction results of different types of records. Among them, 04 in the distinction results of different types of records represents a new segment base address, and the subsequent address is the offset address of this segment; 02 represents a high address; 00 represents a data record, including the offset address and content of the data; 01 represents the end-of-file marker; S33. Record the segment base address according to the distinction results of different types of records. When reading a 04 record, extract the base address of the current segment and represent it as a hexadecimal string; S34. Divide according to the segment base address to obtain the start address and end address recorded in each line; S35. When reading 01, set the end address of the current block to the end address of the last record, and save the final block to the storage block set. Each block records the start address, end address, block length, and the record index range involved in the block.

[0012] Further, in S34, divide according to the segment base address to obtain the start address and end address recorded in each line. For the data record type 00, the start address is the sum of the current segment base address and the offset address in the record, obtaining the absolute start address of the current record; The calculation formula for the end address is as follows: End address = Start address + Record data length - 1 When reading a 04 record, extract the new segment base address, and calculate the absolute address of the next data record based on this new segment base address; Compare the new segment base address with the end address of the previous segment, calculate the absolute start address of the current record - the end address of the previous record, and determine whether it is equal to 1. If it is equal to 1, it indicates that the two segments are continuous and are merged into the same block as the previous segment. Otherwise, a new block is created, the end address of the previous segment is saved as the end of the previous block, and the new segment base address is used as the start address of the current block; during the process of traversing the records, store the end address of the previous record.

[0013] Further, the specific process in S4 is as follows: S41. Sort the addresses where each variable is located using the quicksort algorithm. S42. Set the starting address and ending address after sorting as the initial boundaries for the binary search. The left boundary corresponds to the starting position to be searched, and the right boundary corresponds to the ending position. Calculate the middle position for each iteration and obtain the record at the middle position. The formula for calculating the middle position is as follows: Middle position = left boundary + (right boundary - left boundary) / 2; S43. Check the target condition. Compare the target address with the address range of the current record. If the target address is equal to the address of the current record, find the target record, stop the search, and modify the record. If the target address is less than the starting address of the current record, the target address is in the left half. Update the right boundary, right boundary = middle position – 1. If the target address is greater than the ending address of the current record, it means the target address is in the right half. Update the left boundary, left boundary = middle position + 1. S44. Repeat narrowing the range. After adjusting the left and right boundaries each time, recalculate the middle position and check the condition until the target record is found or the search range is empty, i.e., left boundary > right boundary. If the search range is empty, the target address is not in the current record set. S45. When the target record is found, calculate the offset of the target address relative to the starting address of the record. Locate the position of the modified content in the record according to the offset, and update the record information. Generate a complete record using the updated data. S46. After finding the target record and completing the modification, exit the loop.

[0014] Furthermore, in S41, the specific process of sorting the addresses where each variable is located using the quicksort algorithm is as follows: S411. Compare and sort according to the numerical size, sorting in ascending order according to the numerical size. S412. If the previous address is greater than the next address during sorting, swap the two. Finally, all addresses are sorted in ascending order.

[0015] Preferably, create a thread pool and build a task queue within the thread pool. The task queue stores several hex program file tasks to be processed. In the step of quickly rewriting a batch of hex program files by combining the quick rewriting method of a single hex program file with multi-threaded concurrent technology, the specific process is as follows: L1. Initialize the thread pool, create a thread pool object, dynamically allocate an appropriate number of threads according to the number of CPU cores to balance resource utilization and execution efficiency. Define a task queue, which is used to store the hex program file rewriting tasks to be processed. Lock the thread pool object to protect the security of the task queue, and use a condition variable to implement the event of notifying other threads to wait after unlocking. L2. Decompose the batch of hex program file rewriting tasks into multiple independent tasks. Each task is responsible for processing one hex program file and put the tasks into the task queue. When operating on the task queue, lock it to ensure thread safety. In each task, it is necessary to load the target hex program file, use the binary search method to find the target address in the storage block, perform the operations of adding, deleting, modifying, and querying the stored content corresponding to the address, and save the modified hex program file. L3. Add all the decomposed tasks to the task queue of the thread pool. The thread pool automatically schedules idle threads to process the tasks in the queue, ensuring thread safety during the task allocation process. Locks can be used to avoid duplicate submission or omission of tasks. L4. The threads in the thread pool execute the rewriting tasks concurrently, running independently without interfering with each other. Read the path of a hex program file to be processed in the task queue. Unlock and release the resources to allow other threads to access the task queue. Complete the loading, binary search, and rewriting operations of the hex program file. After the task is completed, reacquire the lock, update the task status, unlock and notify the waiting threads to continue processing through the notification mechanism. Use the condition variable to notify other waiting threads that the resource or task status has been updated. After a single thread obtains the hex program file rewriting task, complete the rewriting of the current hex program file. L5. Obtain the execution results of each task through a callback function or a Future object, record the successful and failed files. If some tasks fail, record the error information and provide a retry mechanism. L6. After all tasks are completed, shut down the thread pool and release the occupied system resources to ensure that all threads in the thread pool have been correctly executed.

[0016] In the second aspect, the present invention also provides a vehicle-mounted hex program file rewriting system, including: A program file rewriting processing module, which is used to sort the quantities to be rewritten according to the ECU addresses of the quantities to be rewritten in the protocol table, and perform rapid rewriting on a single hex program file by using the binary search method. The program file batch rewriting processing module is used to create a thread pool and construct a task queue within the thread pool. The task queue stores several hex program file tasks to be processed. The several hex program file tasks to be processed are combined with the multi-threaded concurrent technology according to the fast rewriting method of a single hex program file to complete the fast rewriting of the batch hex program files.

[0017] In a third aspect, the present invention also provides a mobile terminal, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the steps of the vehicle-mounted hex program file rewriting method as described above are implemented.

[0018] In a fourth aspect, the present invention also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the vehicle-mounted hex program file rewriting method as described above are implemented.

[0019] Compared with the prior art, the present invention has the following beneficial technical effects: The present invention provides a vehicle-mounted hex program file rewriting method. By sorting the quantities to be rewritten according to the ECU addresses of the quantities to be rewritten in the protocol table and using the binary method to quickly locate the parts to be rewritten, the time for searching and rewriting can be significantly reduced, thereby improving the rewriting efficiency of a single hex program file. Creating a thread pool and using multi-threaded concurrent technology to process batch hex program files can make full use of the computing power of multi-core processors to achieve parallel processing, further shortening the overall rewriting time. The design of the thread pool and the task queue enables the system to efficiently manage multiple hex program file rewriting tasks, avoiding the overhead caused by frequent creation and destruction of threads, and improving the overall processing capacity and response speed of the system.

[0020] Further, reading the name of the value calibration quantity to be rewritten and the value to be rewritten from the protocol table provides a clear target for subsequent rewriting operations. Matching the name of the value calibration quantity to be rewritten with the variable name in the A2L file obtains the 32-bit ECU absolute address and data type of the variable to be rewritten. By comparing the address of the variable to be rewritten with the start and end addresses of the block segment, the block segment to which the variable belongs is quickly located, providing a range for subsequent binary search. Sorting and performing binary search on the block segment greatly improve the efficiency of finding the position of the variable to be rewritten in a large amount of data. Through precise address matching and data type conversion, the accuracy of the rewriting operation is ensured, reducing rewriting failures or system exceptions caused by incorrect addresses or data type mismatches.

[0021] Furthermore, by dynamically allocating the number of threads, the number of threads can be optimized according to the system resources and task load conditions, thereby balancing resource utilization and execution efficiency. The thread pool automatically schedules idle threads to process tasks in the queue, avoiding the overhead of thread creation and destruction and improving the efficiency of task processing. Threads execute rewrite tasks concurrently, making full use of the computing power of multi-core processors and significantly shortening the rewrite time of batch hex program files. Brief Description of the Drawings

[0022] Figure 1 It is a flowchart of the method for rewriting the in-vehicle hex program file in an embodiment of the present invention; Figure 2 It is a flowchart of rewriting a single hex program file in an embodiment of the present invention; Figure 3 It is a detailed analysis diagram of addressing and rewriting in an embodiment of the present invention; Figure 4 It is a schematic diagram of using a thread pool for batch hex program files in an embodiment of the present invention; Figure 5 It is a schematic diagram of the generation process of hex program compilation in an embodiment of the present invention; Figure 6 It is a schematic diagram of the hex program file under a text editor in an embodiment of the present invention; Figure 7 It is a schematic diagram of the structure of the hex Record program file in an embodiment of the present invention; Figure 8 It is a schematic diagram of the hex Block Item division method in an embodiment of the present invention; Figure 9 It is a schematic diagram of the process of dividing hex Record into Blocks in an embodiment of the present invention; Figure 10 It is a schematic diagram of the parsing process of hex Block Itern in an embodiment of the present invention; Figure 11 It is a schematic diagram of hex value rewriting in an embodiment of the present invention; Figure 12 It is a schematic diagram of hex axis rewriting in an embodiment of the present invention; Figure 13 It is a schematic diagram of hex CURVE rewriting in an embodiment of the present invention; Figure 14 It is a schematic diagram of hex MAP rewriting in an embodiment of the present invention; Figure 15 It is a schematic diagram of the principle structure of the in-vehicle hex program file rewriting system in an embodiment of the present invention; In the figure: 1. Program file rewriting processing module; 2. Program file batch rewriting processing module. Detailed Embodiment

[0023] In order to enable those skilled in the art to better understand the solution of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the scope of protection of the present invention.

[0024] The purpose of the present invention is to provide a method and related device for rewriting in-vehicle hex program files, so as to solve the technical problem of how to improve the rewriting efficiency of single and batch hex program files. The present invention introduces the dichotomy method and the thread pool technology, and combines the producer-consumer model, which significantly improves the rewriting efficiency of hex program files. Specifically, the dichotomy method is used to optimize the algorithm process of rewriting hex program files, and the rewriting task of a single file can be completed within 0.5 seconds; the thread pool technology makes full use of the parallel capabilities of multi-core processors to achieve efficient batch processing of multiple files. In practical applications, through the combination of these two technologies, the batch rewriting of 20 hex program files can be completed within 5 seconds, and the efficiency improvement shows an exponential growth. The high-efficiency program compilation and hex program file rewriting technology provided by this patent can not only significantly shorten the compilation and rewriting time of single files, but also show excellent efficiency in batch processing scenarios. By using computer programs to replace manual and cumbersome operations in programming and rewriting tools (such as CANape), the program release cycle is greatly shortened, and the software development efficiency is significantly improved.

[0025] The following further describes the present invention in detail with reference to the accompanying drawings: Embodiment 1 See Figure 1 , in an embodiment of the present invention, a method for rewriting in-vehicle hex program files is provided, including: Step 1, sort the quantities to be rewritten according to the ECU addresses of the quantities to be rewritten in the protocol table, and quickly rewrite a single hex program file by using the dichotomy method; Specifically, according to Figure 2 shown, the specific process is as follows: S1, read the name of the value calibration quantity to be rewritten and the value to be rewritten from the protocol table; S2, match the name of the value calibration quantity to be rewritten with the variable name in A2L to obtain the 32-bit ECU absolute address and variable data type of the variable to be rewritten; S3. Locate the block segment to which the variable belongs through the 32-bit ECU absolute address of the variable name to be rewritten. The location method is that the 32-bit ECU absolute address of the variable name to be rewritten is greater than or equal to the starting address of the block segment and less than or equal to the ending address of the block segment; Among them, the specific process is as follows: S31. Read the content of the hex program file to be flashed generated by each controller line by line. Each line includes a record type, address information, and data content; S32. Distinguish according to the field of the record type in each line to obtain the distinction results of different types of records. Among them, in the distinction results of different types of records, 04 indicates a new segment base address, and the subsequent address is the offset address of this segment; 02 indicates a high address; 00 indicates a data record, including the offset address and content of the data; 01 indicates the end-of-file marker; S33. Record the segment base address according to the distinction results of different types of records. When reading a 04 record, extract the base address of the current segment and represent it as a hexadecimal string; S34. Obtain the starting address and ending address recorded in each line according to the division of the segment base address; Among them, as Figure 9 and Figure 10 shown, obtain the starting address and ending address recorded in each line according to the division of the segment base address. For the data record type 00, the starting address is the sum of the current segment base address and the offset address in the record, obtaining the absolute starting address of the current record; The calculation formula for the ending address is as follows: Ending address = Starting address + Record data length - 1 When reading a 04 record, extract the new segment base address, and calculate the absolute address of the next data record based on this new segment base address; Compare the new segment base address with the ending address of the previous segment, calculate the absolute starting address of the current record - the ending address of the previous record, and judge whether it is equal to 1. If it is equal to 1, it indicates that the two segments are continuous and are merged into the same block as the previous segment. Otherwise, a new block is created, the ending address of the previous segment is saved as the end of the previous block, and the new segment base address is used as the starting address of the current block; during the process of traversing the records, store the ending address of the previous record.

[0026] S35. When reading 01, set the ending address of the current block to the ending address of the last record, and save the final block to the storage block set. Each block records the starting address, ending address, block length, and the record index range involved in the block.

[0027] S4. Sort the addresses where each variable is located. Based on the block segment to which the located variable belongs, use the starting index row of the sorted block segment as the left boundary of the binary search, and the ending index of the block segment as the right boundary of the binary search. After performing several binary searches based on the left and right boundaries of the binary search, determine the specific record row where the variable to be rewritten is located. When the condition for terminating the search is met, the 32-bit ECU absolute address of the variable to be rewritten is greater than or equal to the starting index of the current binary search row record and less than or equal to the ending index of the current binary search row record, as Figure 3 shown; Specifically, the specific process is as follows: S41. Use the quicksort algorithm to sort the addresses where each variable is located; Among them, the specific process of using the quicksort algorithm to sort the addresses where each variable is located is as follows: S411. Perform a comparison and sort according to the numerical size, and sort in ascending order according to the numerical size; S412. If the previous address is greater than the next address during the sorting, swap the two, and finally complete the sorting of all addresses in ascending order.

[0028] S42. Set the starting address and ending address after sorting as the initial boundaries of the binary search. The left boundary corresponds to the starting position to be searched, and the right boundary corresponds to the ending position. Calculate the middle position of each iteration and obtain the record at the middle position. The calculation formula for the middle position is as follows: Middle position = left boundary + (right boundary - left boundary) / 2; S43. Check the target condition, compare the target address with the address range of the current record. If the target address is equal to the address of the current record, find the target record, stop the search, and modify the record. If the target address is less than the starting address of the current record, the target address is in the left half, update the right boundary, right boundary = middle position - 1; If the target address is greater than the ending address of the current record, it means the target address is in the right half, update the left boundary, left boundary = middle position + 1; S44. Repeat shrinking the range. After adjusting the left and right boundaries each time, recalculate the middle position and check the condition until the target record is found or the search range is empty, that is, the left boundary > the right boundary. If the search range is empty, the target address is not in the current record set; S45. When the target record is found, calculate the offset of the target address relative to the starting address of the record, locate the position of the modified content in the record according to the offset, and update the record information. Generate a complete record using the updated data; S46. After finding the target record and completing the modification, exit the loop.

[0029] S5. Convert the value to be rewritten into a hexadecimal value according to the data type, and convert it into the corresponding hexadecimal string. Record the rewritten content and the corresponding address in bytes. Use the binary search method to obtain the rewritten line of record, and perform byte-by-byte rewriting in a loop until the loop ends, completing the rapid rewriting of a single hex program file.

[0030] Step 2. Create a thread pool and construct a task queue within the thread pool. The task queue stores several hex program file tasks to be processed; several hex program file tasks to be processed complete the rapid rewriting of batch hex program files by combining the rapid rewriting method of a single hex program file and multi-threaded concurrent technology.

[0031] Specifically, according to Figure 4 as shown, the specific process is as follows: L1. Initialize the thread pool, create a thread pool object, dynamically allocate an appropriate number of threads according to the number of CPU cores to balance resource utilization and execution efficiency, define a task queue, which is used to store the hex program file rewriting tasks to be processed; lock the thread pool object to protect the security of the task queue, and use a condition variable to implement the event of notifying other threads to wait after unlocking; L2. Decompose the batch hex program file rewriting tasks into multiple independent tasks. Each task is responsible for processing a hex program file and puts the task into the task queue. When operating on the task queue, lock it to ensure thread safety. Among them, each task needs to load the target hex program file, use the binary search method to find the target address in the storage block, perform operations such as adding, deleting, modifying, and querying the storage content corresponding to the address, and save the modified hex program file; L3. Add all the decomposed tasks to the thread pool task queue. The thread pool automatically schedules idle threads to process the tasks in the queue, ensuring thread safety during the task allocation process. Locks can be used to avoid duplicate submission or omission of tasks; L4. The threads in the thread pool concurrently execute the rewriting tasks, running independently without interfering with each other, reading the path of a hex program file to be processed in the task queue; unlocking and releasing resources to allow other threads to access the task queue; completing the loading, binary search, and rewriting operations of the hex program file; after the task is completed, re-acquire the lock, update the task status, unlock and notify the waiting threads to continue processing through the notification mechanism, use the condition variable to notify other waiting threads that the resource or task status has been updated. After a single thread obtains the hex program file rewriting task, complete the rewriting of the current hex program file.

[0032] L5. Obtain the execution results of each task through a callback function or a Future object, record the files of successes and failures. If some tasks fail, record the error information and provide a retry mechanism.

[0033] L6. After all tasks are completed, shut down the thread pool and release the occupied system resources to ensure that all threads in the thread pool have been executed correctly.

[0034] In the single hex program file rewriting algorithm of this embodiment, read the quantity to be rewritten from the Excel technical protocol. Utilize the property that the addresses in the hex program file increase from top to bottom to sort the addresses of the quantities to be rewritten from small to large. Divide the hex into block Items, and determine the block to which the first rewritten quantity after sorting belongs. When rewriting the first quantity, perform a binary search with the left boundary being the starting record where the block is located and the right boundary being the ending record of the block. Quickly complete the rewriting of the current quantity through binary search and record the position of the rewritten record. When rewriting the next quantity, due to the increasing addresses after sorting combined with the property of increasing addresses in the hex program file, the left boundary of the binary search for the next quantity is the record position where the previous quantity was rewritten, rather than the starting record position of the block, and the right boundary of the binary search is still the ending record of the block. Complete the rewriting of all quantities to be rewritten according to the above principle, and the entire rewriting process shows a trend of narrowing binary search intervals. Save the rewritten hex program file.

[0035] In this embodiment, for the batch rewriting of hex program files, the process of batch rewriting hex program files can combine the thread pool mechanism and the producer-consumer model to improve the processing efficiency. The principle is as Figure 4 shown. The specific implementation process is as follows: First, initialize the configuration file to obtain the list of paths of hex program files for batch processing and the rewriting rules (such as address ranges, modification values, etc.). Then, create a thread pool, set a reasonable number of threads to make full use of multi-core CPU resources, and at the same time construct a task queue (such as BlockingQueue) to store the tasks of hex program files to be processed.

[0036] After initialization, the producer is responsible for encapsulating each hex program file path and its corresponding rewriting rule into a task object and putting them into the task queue in sequence, continuously filling new tasks. At the same time, the consumer (the working thread in the thread pool) obtains the task objects (including the hex program file path and its rewriting rule) from the task queue and performs the rewriting operations in sequence. The specific rewriting steps are the same as those for processing a single hex program file, but a synchronization mechanism (such as a lock) is required to avoid duplicate submission or omission of tasks.

[0037] After the rewrite task is completed, the consumer thread will mark the task as completed and return the processing result. After the producer fills all tasks into the queue, the producer thread stops working. The thread pool will be closed after all tasks are executed, and relevant resources will be released.

[0038] This method effectively combines the concurrent processing ability of the thread pool and the task scheduling mechanism of the producer-consumer model, which can significantly improve the efficiency of batch rewriting of hex program files, while ensuring the correctness of tasks and the reasonable utilization of resources.

[0039] In this embodiment, according to Figure 5 as shown, a single hex program file is compiled and generated, and the hex program file is opened through a text editor, where the content of the hex program file is as Figure 6 shown, and it can be seen from Figure 6 that the content of the hex program file is arranged line by line in sequence. According to the definition of the hex program file, each line is regarded as a Record. Figure 6 There are 4 lines of content in , that is, 4 Records. Taking the first line Record in Figure 6 as an example, the hex program file structure is as Figure 7 shown; the symbols and data contained in each line Record are defined as a field according to different functions or meanings. It includes 6 fields: Record identifier, length (Record Length), load address (Record Load Address), type (Record Type), data or information (Record Info or Data), and checksum (Record Checksum).

[0040] Record identifier: Each Record starts with ":". Length: It represents the 5th field of this line Record, that is, how many bytes the data or information consists of. Load address: It represents the position in memory where the data or information of this Record is located. Type: Represents the meaning of data or information, containing the base address or data. When it is 0x00, it represents data; when it is 0x01, it represents the end of the entire hex program file; when it is 0x02, it can be used for both 16-bit and 32-bit formats, but is mainly used for 16-bit, representing the high 8 bits; when it is 0x03, it can be used for both 16-bit and 32-bit formats, but is mainly used by 16-bit, indicating the starting execution address of this line of the hex program file; when it is 0x04, it allows a maximum of 32-bit addressing, representing the high 16 bits, and the actual address is obtained by combining the offset address of the next Record with the base address of this line; when it is 0x05, for the 32-bit format, it represents the starting execution address of the hex program file content.

[0041] Checksum: Through the checksum, it can be known whether the current Record information has been tampered with. Its calculation starts from the second field and ends at the fifth field.

[0042] According to Figure 8 As shown, the Record type of the first line of this hex program file is 0x04, the type of the last line is 0x01, and there are multiple 0x04 types in the entire file, which respectively record different linear addresses. When encountering a new 0x04 RecordType, calculate the new segment base address, and at the same time record the absolute address of the previous line of Reocrd. Calculate the absolute address of the next line of Reord Type according to the offset address corresponding to the next line Record Type 0x00. Compare whether the addresses are continuous. If the addresses are continuous, it is the same Block Item, otherwise it is a new Block Item.

[0043] In this embodiment, when reading the Record on the 1027th line, the type of this line is 0x04, indicating that the new segment base address is 0x8003. According to the offset address of the next line, the starting absolute address of the 1028th line can be obtained as 0x80030000. The termination absolute address of the previous line of this segment base address line, that is, the 1026th line, is 0x8002FFFF. It can be found that the termination address of the 1026th line and the starting address of the 1028th line are continuous, so they belong to the same Block. Similarly, it can be obtained that the termination address of the previous line and the starting address of the next line of the Record on the 43678th line are not continuous, so it is a new Block.

[0044] Among them, as Figure 8 shown, the hex Block Item division process is as follows: X1, read hex Record line by line into the string. Extract the starting identifier, length, load address, type, data or information, and checksum of each line of Record through string splitting.

[0045] X2, if the Record type is 02 or 04, extract the data of this line. Define the high 16 bits of the 32-bit chip as the data content, that is, the segment base address. The Record after this line calculates the start address and end address of the Record through the segment base address and its own offset address and hex length.

[0046] X3, start reading from the first line of the hex program file. When the Record type is 02 or 04 for the first time, the line number is recorded as the starting index of the Block Item.

[0047] X4, continue reading, and when a new Record type of 02 or 04 is encountered next time, record the end address of the previous line and the start address of the next line.

[0048] X5, if the difference between the start address and the end address obtained in the above step is greater than 1, the row number of the previous row of Record is recorded as the end index. If it is equal to 1, it means that the row of Record belongs to the same Block Item as the previous row.

[0049] X6, when the Record type is 01, it means that the hex program file has been read, and the record index line number of the previous line is recorded as the end index line number of Block. And the last Block is saved. At this point, all the Blocks of the hex program file have been parsed.

[0050] X7, in order to facilitate the next step to quickly locate the hex line that needs to be operated, each Block block is sorted in ascending order according to its address.

[0051] according to Figure 11 As shown, in this embodiment, the hex value rewriting needs to match the value to be rewritten from Excel according to the variable name of the amount to be rewritten, and obtain the absolute address of the amount to be rewritten from A2L. Then, according to the above-mentioned Block division process, find the Block to which the Record belongs. Subsequently, the starting index and the ending index of the Block are used as the left and right boundaries of the binary method, and the binary method is used to continuously change the left and right boundaries to quickly obtain the specific Record row number where the amount to be rewritten is located. In order to facilitate rewriting, it is also necessary to convert the Excel value into hexadecimal data. Finally, recalculate the checksum of the row to ensure that the Record of the row is successfully rewritten. The processes of this embodiment are all suitable for the hex axis rewriting process, such as Figure 12 As shown, the hex CURVE rewriting process is as follows: Figure 13 As shown in the figure, the hex MAP rewriting process is as follows: Figure 14 shown.

[0052] In summary, in terms of program compilation and generation, this embodiment adopts a one-key hex compilation technology, which can quickly generate the flash hex program files required for each controller, compressing the original compilation time of 5 minutes to about 0.1 seconds. In terms of program rewriting, a one-key hex rewriting technology is introduced, which can quickly complete the rewriting operation of the hex program files of each controller. First, the addresses of the storage blocks are sorted from low to high, and the target address of the storage block in the hex program file is accurately located by the dichotomy method, shortening the time-consuming of the single-file rewriting process from 30 minutes to less than 1 second. In addition, combined with the multi-threaded concurrent technology, efficient batch hex program file rewriting is realized, further improving the overall processing efficiency. This embodiment has been applied in an enterprise project at the present stage to realize the rapid compilation and rewriting of single hex and batch hex program files in this project. Using the traditional method to compile and rewrite a program takes one hour, and the number of generated programs released within a working day is limited. Using a brute-force loop program to compile and rewrite a program takes 5 minutes. Using this technology, the hex can be compiled, generated and rewritten in about 0.1 seconds, and the rewriting process is accurate and error-free, saving a lot of time and effectively improving work efficiency.

[0053] Embodiment 2 According to Figure 15 As shown, the present invention also provides a vehicle-mounted hex program file rewriting system, including: A program file rewriting processing module 1, configured to sort the quantities to be rewritten according to the ECU addresses of the quantities to be rewritten in the protocol table, and quickly rewrite a single hex program file by using the dichotomy method; A program file batch rewriting processing module 2, configured to create a thread pool and construct a task queue in the thread pool, where the task queue stores several hex program file tasks to be processed; several hex program file tasks to be processed are quickly rewritten in batches according to the quick rewriting method of a single hex program file in combination with the multi-threaded concurrent technology.

[0054] Embodiment 3 The present invention also provides a mobile terminal, including a memory, a processor, and a computer program stored in the memory and executable on the processor, such as a vehicle-mounted hex program file rewriting program.

[0055] When the processor executes the computer program, the steps of the above-mentioned vehicle-mounted hex program file rewriting method are implemented, for example: Sort the quantities to be rewritten according to the ECU addresses of the quantities to be rewritten in the protocol table, and quickly rewrite a single hex program file by using the dichotomy method; Create a thread pool and build a task queue within the thread pool. The task queue stores a number of hex program file tasks to be processed; a number of hex program file tasks to be processed are quickly rewritten in batches based on the quick rewriting method of a single hex program file combined with multi-threaded concurrency technology.

[0056] Alternatively, when the processor executes the computer program, it implements the functions of each module in the above system. For example: The program file rewriting processing module 1 is used to sort the quantities to be rewritten according to the ECU addresses of the quantities to be rewritten in the protocol table, and quickly rewrite a single hex program file by using the binary search method. The program file batch rewriting processing module 2 is used to create a thread pool and build a task queue within the thread pool. The task queue stores a number of hex program file tasks to be processed; a number of hex program file tasks to be processed are quickly rewritten in batches based on the quick rewriting method of a single hex program file combined with multi-threaded concurrency technology.

[0057] Exemplarily, the computer program can be divided into one or more modules / units. The one or more modules / units are stored in the memory and executed by the processor to complete the present invention. The one or more modules / units can be a series of computer program instruction segments capable of performing specific functions, and these instruction segments are used to describe the execution process of the computer program in the mobile terminal.

[0058] For example, the computer program can be divided into the program file rewriting processing module 1 and the program file batch rewriting processing module 2; The specific functions of each module are as follows: The program file rewriting processing module 1 is used to sort the quantities to be rewritten according to the ECU addresses of the quantities to be rewritten in the protocol table, and quickly rewrite a single hex program file by using the binary search method. The program file batch rewriting processing module 2 is used to create a thread pool and build a task queue within the thread pool. The task queue stores a number of hex program file tasks to be processed; a number of hex program file tasks to be processed are quickly rewritten in batches based on the quick rewriting method of a single hex program file combined with multi-threaded concurrency technology.

[0059] The mobile terminal can be a computing device such as a desktop computer, a notebook, a palm computer, and a cloud server. The mobile terminal may include, but is not limited to, a processor and a memory.

[0060] The processor may be a Central Processing Unit (CPU), or may also be other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc. The processor is the control center of the mobile terminal, and connects various parts of the entire mobile terminal through various interfaces and lines.

[0061] The memory can be used to store the computer programs and / or modules. The processor realizes various functions of the mobile terminal by running or executing the computer programs and / or modules stored in the memory, and by calling the data stored in the memory.

[0062] The memory mainly includes a program storage area and a data storage area. Among them, the program storage area can store an operating system, application programs required for at least one function (such as a sound playback function, an image playback function, etc.); the data storage area can store data created according to the use of the mobile phone (such as audio data, phone book, etc.). In addition, the memory may include high-speed random access memory, and may also include non-volatile memory, such as a hard disk, a memory, a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) card, a Flash Card, at least one magnetic disk storage device, a flash memory device, or other volatile solid-state storage devices.

[0063] Embodiment 4 The present invention also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the method for rewriting a vehicle-mounted hex program file are realized.

[0064] If the modules / units integrated in the mobile terminal are implemented in the form of software function units and sold or used as independent products, they can be stored in a computer-readable storage medium.

[0065] Based on such understanding, all or part of the processes in the above method of the present invention can also be completed by instructing relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, the steps of the above aggregation reinforcement learning resource scheduling method can be implemented. Among them, the computer program includes computer program code, and the computer program code can be in the form of source code, object code, executable file or some intermediate form, etc.

[0066] The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disc, computer memory, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), electrical carrier signal, telecommunication signal, and software distribution medium, etc.

[0067] It should be noted that the content included in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the computer-readable medium does not include electrical carrier signals and telecommunication signals.

[0068] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit them. Although the present invention has been described in detail with reference to the above embodiments, those of ordinary skill in the art should understand that: modifications or equivalent replacements can still be made to the specific embodiments of the present invention. Any modification or equivalent replacement without departing from the spirit and scope of the present invention shall be covered by the protection scope of the claims of the present invention.

Claims

1. A method for rewriting an in-vehicle hex program file, characterized in that, Including: Sort the quantities to be rewritten according to the ECU addresses of the quantities to be rewritten in the protocol table, and use the binary search method to quickly rewrite a single hex program file; Create a thread pool and construct a task queue within the thread pool. The task queue stores several hex program file tasks to be processed; several hex program file tasks to be processed are combined with the multi-threaded concurrency technology according to the quick rewrite method of a single hex program file to complete the quick rewrite of a batch of hex program files.

2. The vehicle-mounted hex program file rewriting method according to claim 1, characterized in that In the step of sorting the quantities to be rewritten according to the ECU addresses of the quantities to be rewritten in the protocol table and using the binary search method to quickly rewrite a single hex program file, the specific process is as follows: S1. Read the name of the value calibration quantity to be rewritten and the value to be rewritten from the protocol table; S2. Match the name of the value calibration quantity to be rewritten with the variable name in A2L to obtain the 32-bit ECU absolute address and variable data type of the variable to be rewritten; S3. Locate the block segment to which the variable belongs through the 32-bit ECU absolute address of the variable to be rewritten. The positioning method is that the 32-bit ECU absolute address of the variable to be rewritten is greater than or equal to the start address of the block segment and less than or equal to the end address of the block segment; S4. Sort the addresses where each variable is located. According to the located block segment to which the variable belongs, use the start index row of the sorted block segment as the left boundary of the binary search method, and use the end index of the block segment as the right boundary of the binary search method; after several binary searches according to the left and right boundaries of the binary search method, determine the specific record line where the variable to be rewritten is located; when the condition for terminating the search is met, the 32-bit ECU absolute address of the variable to be rewritten is greater than or equal to the start index of the current binary search row record and less than or equal to the end index of the current binary search row record; S5. Convert the value to be rewritten into a hexadecimal value in combination with the data type, and convert it into the corresponding hexadecimal string. Record the rewritten content and the corresponding address in bytes, use the binary search method to obtain the record rewrite row, and perform loop-by-byte rewriting until the loop ends to complete the quick rewrite of a single hex program file.

3. The method for rewriting an in-vehicle hex program file according to claim 2, wherein In the step of locating the block segment to which the variable belongs through the 32-bit ECU absolute address of the variable to be rewritten, the specific process is as follows: S31. Read the content of the hex program file to be flashed generated by each controller line by line, where each line includes a record type, address information, and data content; S32. Distinguish according to the field of the record type in each line to obtain the distinction results of different types of records. Among them, 04 in the distinction results of different types of records represents a new segment base address, and the subsequent address is the offset address of this segment; 02 represents a high address; 00 represents a data record, including the offset address and content of the data; 01 represents a file end marker; S33. Record the segment base address according to the distinction results of different types of records. When reading a 04 record, extract the base address of the current segment and represent it as a hexadecimal string; S34. Obtain the start address and end address recorded in each row according to the segment base address; S35. When 01 is read, set the end address of the current block to the end address of the last record, and save the final block to the storage block set. Each block records the start address, end address, block length, and the record index range involved in the block.

4. A method for rewriting an in-vehicle hex program file according to claim 3, characterized in that, In S34, the start address and end address recorded in each row are obtained according to the segment base address. For the data record type 00, the start address is the sum of the current segment base address and the offset address in the record, obtaining the absolute start address of the current record; The calculation formula for the end address is as follows: End address = Start address + Record data length - 1 When the 04 record is read, extract the new segment base address, and calculate the absolute address of the next data record based on this new segment base address; Compare the new segment base address with the end address of the previous segment, calculate the absolute start address of the current record - the end address of the previous record, and determine whether it is equal to 1. If it is equal to 1, it indicates that the two segments are continuous and are merged into the same block. Otherwise, create a new block, save the end address of the previous segment as the end of the previous block, and use the new segment base address as the start address of the current block; During the process of traversing the records, store the end address of the previous record.

5. A method for rewriting an in-vehicle hex program file according to claim 3, characterized in that, The specific process in S4 is as follows: S41. Use the quicksort algorithm to sort the addresses where each variable is located; S42. Set the start address and end address after sorting as the initial boundaries for the binary search. The left boundary corresponds to the starting position to be searched, and the right boundary corresponds to the ending position. Calculate the middle position for each iteration and obtain the record at the middle position. The calculation formula for the middle position is as follows: Middle position = Left boundary + (Right boundary - Left boundary) / 2; S43. Check the target condition, compare the target address with the address range of the current record. If the target address is equal to the address of the current record, find the target record, stop the search, and modify the record; If the target address is less than the start address of the current record, then the target address is in the left half, update the right boundary, Right boundary = Middle position - 1; If the target address is greater than the end address of the current record, it means the target address is in the right half, update the left boundary, Left boundary = Middle position + 1; S44. Repeat shrinking the range. After adjusting the left boundary and right boundary each time, recalculate the middle position and check the condition until the target record is found or the search range is empty, that is, the left boundary > the right boundary. If the search range is empty, then the target address is not in the current record set; S45. When the target record is found, calculate the offset of the target address relative to the start address of the record, locate the position of the modified content in the record according to the offset, and update the record information. Generate a complete record using the updated data; S46. After finding the target record and completing the modification, exit the loop.

6. The vehicle-mounted hex program file rewriting method according to claim 5, characterized in that In S41, the specific process of using the quicksort algorithm to sort the addresses where each variable is located is as follows: S411. Compare and sort according to the numerical size, and sort in ascending order according to the numerical size; S412. If the previous address is greater than the next address during sorting, swap the two. Eventually, all addresses are sorted in ascending order.

7. A method for rewriting an in-vehicle hex program file according to claim 1, characterized in that Create a thread pool and build a task queue within the thread pool. The task queue stores several hex program file tasks to be processed. In the step of quickly rewriting a batch of hex program files by combining the fast rewriting method of a single hex program file with multi-threaded concurrent technology, the specific process is as follows: L1. Initialize the thread pool, create a thread pool object, dynamically allocate an appropriate number of threads according to the number of CPU cores to balance resource utilization and execution efficiency. Define a task queue, which is used to store the hex program file rewriting tasks to be processed. Lock the thread pool object to protect the security of the task queue, and use a condition variable to implement the event of notifying other threads to wait after unlocking. L2. Decompose the batch hex program file rewriting task into multiple independent tasks. Each task is responsible for processing a hex program file and put the task into the task queue. When operating on the task queue, lock it to ensure thread safety. Among them, each task needs to load the target hex program file, use the binary search method to find the target address in the storage block, perform operations of adding, deleting, modifying, and querying the storage content corresponding to the address, and save the modified hex program file. L3. Add all the decomposed tasks to the thread pool task queue. The thread pool automatically schedules idle threads to process the tasks in the queue to ensure thread safety during task allocation. Locks can be used to avoid duplicate submission or omission of tasks. L4. The threads in the thread pool concurrently execute the rewriting tasks, running independently without interfering with each other. Read the path of a hex program file to be processed in the task queue. Unlock and release resources to allow other threads to access the task queue. Complete the loading, binary search, and rewriting operations of the hex program file. After the task is completed, reacquire the lock, update the task status, unlock and notify the waiting threads to continue processing through a notification mechanism. Use a condition variable to notify other waiting threads that the resource or task status has been updated. After a single thread obtains the hex program file rewriting task, complete the rewriting of the current hex program file. L5. Obtain the execution result of each task through a callback function or Future object, record the successful and failed files. If some tasks fail, record the error information and provide a retry mechanism. L6. After all tasks are completed, shut down the thread pool and release the occupied system resources to ensure that all threads in the thread pool have been correctly executed.

8. A vehicle-mounted hex program file rewriting system, characterized in that, Including: A program file rewriting processing module, which is used to sort the quantity to be rewritten according to the ECU address to be rewritten in the protocol table, and quickly rewrite a single hex program file by using the binary search method. The program file batch rewriting processing module is used to create a thread pool and build a task queue within the thread pool. The task queue stores several hex program file tasks to be processed. Several hex program file tasks to be processed are combined with the multi-threaded concurrent technology according to the fast rewriting method of a single hex program file to complete the fast rewriting of the batch hex program files.

9. A mobile terminal, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the vehicle-mounted hex program file rewriting method according to any one of claims 1-7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the vehicle-mounted hex program file rewriting method according to any one of claims 1-7.

Images