Data refresh display method, device, equipment and readable storage medium

Abstract

A data refreshing display method, device and equipment and readable storage medium, the data refreshing display method comprises: receiving to-be-refreshed data by an instrument on-chip system; writing the to-be-refreshed data into a high-priority queue or a low-priority queue; if it is found that data enters the high-priority queue, scheduling a high-priority refreshing thread, reading the data in the high-priority queue and writing the data into a display frame buffer, and refreshing the instrument screen by using the data in the display frame buffer; and scheduling a low-priority refreshing thread at a preset period, reading the data in the low-priority queue and writing the data into the display frame buffer, and refreshing the instrument screen by using the data in the display frame buffer. According to the application, the high-priority refreshing thread is used to respond to the high-priority data in real time, so that the real-time display of the instrument screen is ensured; and the low-priority refreshing thread is used to respond to the low-priority data at the preset period, so that the display lag of the instrument screen is reduced.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a data refresh display method, apparatus, device, and readable storage medium. Background Technology

[0002] With the development of automotive electronics technology, the in-vehicle instrument SOC (System on Chip, also known as a system-on-a-chip, refers to a dedicated target integrated circuit that includes a complete system and embedded software content) needs to process a large amount of data such as multiple CAN signals, interface rendering, button response, and power level management at the same time. The SOC refreshes and displays the data that needs to be updated on the instrument screen.

[0003] However, current car dashboard screens are prone to "lag" when displaying a large amount of data. Summary of the Invention

[0004] This application provides a data refresh display method, apparatus, device, and readable storage medium, aiming to solve the technical problem that current automotive instrument panel screens are prone to "lag" when the amount of data to be refreshed is large.

[0005] In a first aspect, embodiments of this application provide a data refresh and display method, the data refresh and display method comprising: The system on the instrument panel receives the data to be updated; Identify the category of the data to be refreshed, and determine whether the data to be refreshed is high-priority or low-priority based on the category; Write the data to be refreshed into the corresponding high-priority queue or low-priority queue; If data is detected entering the high-priority queue, the high-priority refresh thread is scheduled to read the data from the high-priority queue and write it to the display frame buffer. The data in the display frame buffer is then used to refresh the display instrument screen. The low-priority refresh thread is scheduled at a preset period to read data from the low-priority queue and write it to the display frame buffer. The data in the display frame buffer is then used to refresh the display instrument screen.

[0006] Optionally, writing the data to be refreshed into a high-priority queue or a low-priority queue includes: If the data to be refreshed does not overlap with the data in the historical frame buffer, the data to be refreshed will be written to either the high-priority queue or the low-priority queue.

[0007] Optionally, reading data from the low-priority queue and writing it to the display frame buffer includes: Traverse and identify jittery data in the low-priority queue, and remove jittery data from the low-priority queue; Write the data from the removed low-priority queue into the display frame buffer.

[0008] Optionally, the step of traversing and identifying jittery data in the low-priority queue includes: For the current data in the low-priority queue being traversed, if the absolute value of the difference between the current data and the data from the previous traversal is less than the threshold for a preset number of consecutive times, then the current data is determined to be jittery data.

[0009] Optionally, before writing to the display frame buffer, the following steps are included: A high-priority refresh thread or a low-priority refresh thread acquires the mutex lock of the display frame buffer; After writing to the display frame buffer, the following is included: After writing is complete, release the mutex lock on the display frame buffer.

[0010] Optionally, determining whether the data to be refreshed is high-priority or low-priority data based on the data category includes: If the data to be refreshed is a power level signal or a button signal, then the data to be refreshed is determined to be high-priority data. If the data to be refreshed is vehicle status data, diagnostic data, or statistical data, then the data to be refreshed is determined to be low-priority data.

[0011] Optionally, determining whether the data to be refreshed is high-priority or low-priority data based on the data category includes: Based on the data category to be refreshed and a preset mapping table, the data to be refreshed is determined to be either high-priority data or low-priority data. The preset mapping table includes the correspondence between the data category to be refreshed, high-priority data, and low-priority data.

[0012] Secondly, embodiments of this application provide a data refresh display device, the data refresh display device comprising: The receiving module is used by the system on the instrument chip to receive data to be refreshed; The identification module is used to identify the category of the data to be refreshed and determine whether the data to be refreshed is high-priority data or low-priority data based on the category. The write module is used to write the data to be refreshed into the corresponding high-priority queue or low-priority queue. The high-priority scheduling module is used to schedule a high-priority refresh thread if data is detected entering the high-priority queue. The thread reads the data from the high-priority queue and writes it to the display frame buffer, and then uses the data in the display frame buffer to refresh the display instrument screen. The low-priority scheduling module is used to schedule low-priority refresh threads at a preset period, read data from the low-priority queue and write it to the display frame buffer, and use the data in the display frame buffer to refresh the display instrument screen.

[0013] Thirdly, embodiments of this application provide a data refresh display device, which includes a processor, a memory, and a data refresh display program stored in the memory and executable by the processor. When the data refresh display program is executed by the processor, it implements the steps of the data refresh display method described above.

[0014] Fourthly, embodiments of this application provide a readable storage medium storing a data refresh display program, wherein when the data refresh display program is executed by a processor, it implements the steps of the data refresh display method as described above.

[0015] The beneficial effects of the technical solutions provided in this application include: In this embodiment, the instrument cluster system receives data to be refreshed; identifies the type of data to be refreshed, and determines whether the data to be refreshed is high-priority or low-priority data based on the type; writes the data to be refreshed into the corresponding high-priority queue or low-priority queue; if data is detected entering the high-priority queue, a high-priority refresh thread is scheduled to read the data in the high-priority queue and write it into the display frame buffer, and uses the data in the display frame buffer to refresh the instrument cluster screen; a low-priority refresh thread is scheduled at a preset period to read the data in the low-priority queue and write it into the display frame buffer, and uses the data in the display frame buffer to refresh the instrument cluster screen. Through this embodiment, high-priority data such as power level and buttons are processed using a high-priority queue and high-priority refresh threads for real-time response and scheduling, ensuring no delay and no omissions, and guaranteeing real-time display of the instrument cluster screen; for other types of low-priority data (such as various vehicle status quantities, diagnostic data, and statistical data), low-priority refresh threads are used to schedule responses at a preset period (such as 10 milliseconds) through a timer, which can reduce memory usage and system load, and reduce display stuttering on the instrument cluster screen. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating one embodiment of the data refresh display method of this application; Figure 2 This is another flowchart illustrating an embodiment of the data refresh display method of this application; Figure 3 For this application Figure 1 A detailed flowchart of step S20; Figure 4This is a schematic diagram of the functional modules of an embodiment of the data refresh display device of this application; Figure 5 This is a schematic diagram of the hardware structure of the data refresh display device involved in the embodiments of this application. Detailed Implementation

[0017] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0019] In a first aspect, embodiments of this application provide a data refresh display method.

[0020] In one embodiment, reference is made to Figure 1 , Figure 1 This is a flowchart illustrating one embodiment of the data refresh display method of this application, as shown below. Figure 1 As shown, the data refresh display methods include: Step S10: The system on the instrument panel receives the data to be refreshed.

[0021] In this embodiment, the System-on-Chip (SOC) of the vehicle instrument cluster serves as the core processing unit. It establishes communication connections with vehicle nodes such as the Vehicle Controller (VCU) and Battery Management System (BMS) via vehicle network communication interfaces (such as CAN bus, LIN bus, or Ethernet). The SOC monitors the message signals on the bus in real time and parses the received raw signals into specific data to be updated. This ensures the real-time nature and reliability of the data source, providing a basic input for subsequent data classification and processing, enabling the instrument cluster to accurately perceive the overall vehicle status.

[0022] Step S20: Identify the category of data to be refreshed, and determine whether the data to be refreshed is high-priority data or low-priority data based on the category of data to be refreshed.

[0023] In this embodiment, the in-vehicle instrument cluster (SOC) has a pre-set data classification strategy or priority mapping table. When data to be refreshed is received, the system extracts the identifier or type field of the data and matches it with the pre-set strategy. The underlying logic is that different data have different degrees of impact on driving safety and user experience. By classifying and identifying the data to be refreshed, a basis is provided for subsequent differentiated processing. This distinguishes critical signals from ordinary status signals from the source, avoiding resource competition caused by a "one-size-fits-all" approach to all data, and preparing for zero-latency response to critical signals.

[0024] Step S30: Write the data to be refreshed into the high-priority queue or the low-priority queue.

[0025] In this embodiment, the system maintains two independent data queues: a high-priority queue and a low-priority queue. Based on the identification result in step S20, data is routed to the corresponding queue. This dual-queue isolation mechanism physically prevents low-priority data from occupying the high-priority data channel. Even if a large influx of low-priority data (such as statistical data) causes queue congestion, it will not block data writing to the high-priority queue (such as power level signals), thus ensuring the smooth flow of critical signal channels and effectively preventing system lag caused by queue congestion.

[0026] Step S40: If data is detected entering the high-priority queue, the high-priority refresh thread is scheduled to read the data in the high-priority queue and write it into the display frame buffer. The data in the display frame buffer is then used to refresh the display instrument screen.

[0027] In this embodiment, the high-priority queue adopts an event-driven mechanism. Once new data is written, an interrupt or semaphore is immediately triggered, waking up the high-priority refresh thread that is in a waiting state. This thread has the highest scheduling priority in the system and can preempt CPU resources to execute immediately. By replacing "polling and waiting" with "instant response," it ensures that critical data is processed as soon as it is generated. For safety-related functions such as power gear switching and emergency button operation, it can achieve millisecond or even microsecond-level response, achieving zero delay and no omissions, greatly improving driving safety and the immediacy of interaction.

[0028] Step S50: Schedule a low-priority refresh thread at a preset period, read data from the low-priority queue and write it to the display frame buffer, and use the data in the display frame buffer to refresh the display instrument screen.

[0029] In this embodiment, the low-priority refresh thread is triggered by a system timer with a preset period of, for example, 10 milliseconds. After the thread is awakened, it reads data from the low-priority queue in batches for processing. Merging high-frequency, scattered low-priority data updates into low-frequency, batch processing tasks can significantly reduce the frequency of screen refreshes and the number of CPU context switches, avoiding frame drops and stuttering caused by frequent refreshes of the instrument screen's user interface, reducing the overall system load, and ensuring the smooth operation of the instrument.

[0030] In this embodiment, refer to Figure 2 , Figure 2 This is another flowchart illustrating an embodiment of the data refresh display method of this application, as shown below. Figure 2As shown, the System-on-a-Chip (SOC) of the vehicle instrument cluster receives CAN bus data (including data reported by BMS, VCU, etc.) through a data receiving thread. This thread filters unchanged data, prioritizes it, and then uses high-priority and low-priority refresh threads to process the high-priority and low-priority queues using different strategies, ultimately refreshing the data displayed on the instrument screen. By classifying and identifying the data to be refreshed, critical signals are distinguished from ordinary status signals at the source, avoiding resource contention caused by a "one-size-fits-all" approach to all data processing, thus preparing for zero-latency response to critical signals. The dual-queue isolation mechanism of high-priority and low-priority queues physically prevents low-priority data from occupying the high-priority data channel. Even if a large influx of low-priority data causes queue congestion, it will not block data writing to the high-priority queue, ensuring the smooth flow of critical signal channels and effectively preventing system lag caused by queue congestion. The high-priority queue uses an event-driven mechanism; once new data is written, an interrupt or semaphore is immediately triggered, waking up the waiting high-priority refresh thread. High-priority refresh threads have the highest scheduling priority in the system, enabling them to preempt CPU resources and execute immediately. By replacing polling with "instant response," they ensure that critical data is processed as soon as it is generated. For safety-related functions such as power gear switching and emergency button operations, they can achieve millisecond or even microsecond-level responses, ensuring zero delay and no omissions, greatly improving driving safety and the immediacy of interaction. Low-priority refresh threads are triggered by a system timer. After being awakened, these threads batch-read data from the low-priority queue for processing. This merges high-frequency, scattered low-priority data updates into low-frequency, batch processing tasks, significantly reducing the frequency of screen refreshes and the number of CPU context switches. This avoids frame drops and stuttering caused by frequent user interface refreshes on the instrument panel screen, reducing the overall system load and ensuring smooth instrument panel operation. This architecture of separating high and low priority processing optimizes system resource allocation. High-priority threads ensure speed, while low-priority threads ensure stability. The combination of both satisfies the real-time requirements of critical safety signals while maintaining the smoothness of regular data display, solving the technical challenge of balancing real-time performance and stability in existing technologies.

[0031] Further, in one embodiment, step S30 includes: If the data to be refreshed does not overlap with the data in the historical frame buffer, the data to be refreshed will be written to either the high-priority queue or the low-priority queue.

[0032] In this embodiment, before writing data to the queue, the system compares the current data to be refreshed with the historical data already stored in the historical frame buffer. If the two contents match, it means that the instrument display status does not need to be changed, and the data to be refreshed is discarded directly without being written to the queue. Only when the two contents do not match is the data to be refreshed written to the corresponding high-priority queue or low-priority queue. By eliminating redundant transmission and processing of invalid data, the amount of data entering the refresh queue can be significantly reduced, memory usage and bus load can be reduced, invalid refreshes caused by duplicate data can be avoided, and the operating efficiency of the system can be further improved.

[0033] Further, in one embodiment, reading data from the low-priority queue and writing it to the display frame buffer includes: Traverse and identify jittery data in the low-priority queue, and remove jittery data from the low-priority queue; Write the data from the removed low-priority queue into the display frame buffer.

[0034] In this embodiment, a data cleaning step is added when low-priority threads process data. Due to sensor signal interference or communication fluctuations, low-priority data may contain jittery data with values ​​jumping back and forth within a short period of time. The system identifies and removes this jittery data by traversing the low-priority queue, thereby preventing frequent jumps and flickering of values ​​(such as vehicle speed and RPM) on the instrument screen, improving the visual stability of the display and user experience. At the same time, it can avoid jittery data triggering unnecessary screen rendering operations, further improving the system's operating efficiency.

[0035] Furthermore, in one embodiment, the step of traversing and identifying jittery data in the low-priority queue includes: For the current data in the low-priority queue being traversed, if the absolute value of the difference between the current data and the data from the previous traversal is less than the threshold for a preset number of consecutive times, then the current data is determined to be jittery data.

[0036] In this embodiment, jitter determination employs a dual condition of "multiple consecutive comparisons + threshold judgment." Specifically, if the absolute value of the difference between the current data and the previous data is less than a set threshold (e.g., extremely small numerical fluctuations), and this state occurs consecutively a preset number of times (e.g., 3 times), then the current data is determined to be jittery data. By distinguishing between normal numerical changes and abnormal signal noise, minute signal noise can be accurately identified and filtered out, while retaining true numerical changes, ensuring the accuracy of the filtering algorithm and avoiding the accidental deletion of valid data or the omission of jittery data.

[0037] Further, in one embodiment, before writing to the display frame buffer, the following steps are included: A high-priority refresh thread or a low-priority refresh thread acquires the mutex lock of the display frame buffer; After writing to the display frame buffer, the following is included: After writing is complete, release the mutex lock on the display frame buffer.

[0038] In this embodiment, since high-priority threads and low-priority threads may access the same display frame buffer area, a mutex lock mechanism is introduced to prevent display errors or program crashes caused by data races. The lock is acquired before a write operation and unlocked afterward. This mutex mechanism ensures that only one thread can modify the frame buffer data at any given time, guaranteeing the atomicity and integrity of data writes and avoiding screen tearing, display artifacts, or data inconsistencies caused by concurrent access from multiple threads, thus improving the system's robustness.

[0039] Furthermore, in one embodiment, reference is made to Figure 3 , Figure 3 For this application Figure 1 A detailed flowchart of step S20 is shown below. Figure 3 As shown, determining whether the data to be refreshed is high-priority or low-priority data based on the data category includes: Step S201: If the data to be refreshed is a power level signal or a button signal, then the data to be refreshed is determined to be high-priority data. In step S202, if the data to be refreshed is vehicle status data, diagnostic data, or statistical data, then the data to be refreshed is determined to be low-priority data.

[0040] In this embodiment, data is coded and categorized based on its functional attributes. Power level and button inputs are directly related to vehicle start / stop and user control, and are considered safety-critical data that needs to be processed and displayed on the screen promptly. Vehicle status parameters, diagnostic information, and statistical data do not require mandatory display of instantaneous changes; only that the status display is generally accurate and reflects reality. System resources are allocated according to functional safety levels to ensure that, when system resources are limited, priority is given to ensuring the normal operation of functions related to driving safety and core control, complying with the safety design principles of automotive-grade systems.

[0041] Further, in one embodiment, determining whether the data to be refreshed is high-priority data or low-priority data based on the category of the data to be refreshed includes: Based on the data category to be refreshed and a preset mapping table, the data to be refreshed is determined to be either high-priority data or low-priority data. The preset mapping table includes the correspondence between the data category to be refreshed, high-priority data, and low-priority data.

[0042] In this embodiment, the data priority determination logic is implemented through a configurable mapping table, which is stored, for example, in non-volatile memory and supports later updates. By decoupling the data priority determination logic from the code through the mapping table, the system's flexibility and maintainability are improved. When vehicle configuration changes or new signal types are added, there is no need to recompile the code; only the mapping table needs to be updated to adjust the priority strategy, reducing development and maintenance costs and making it suitable for reuse across multiple vehicle platforms.

[0043] Secondly, embodiments of this application also provide a data refresh display device.

[0044] In one embodiment, reference is made to Figure 4 , Figure 4 This is a functional module diagram of an embodiment of the data refresh display device of this application, as shown below. Figure 4 As shown, the data refresh display device includes: Receiver module 10 is used for the instrument chip system to receive data to be refreshed; The identification module 20 is used to identify the category of the data to be refreshed and determine whether the data to be refreshed is high-priority data or low-priority data based on the category of the data to be refreshed. The writing module 30 is used to write the data to be refreshed into a high-priority queue or a low-priority queue. The high-priority scheduling module 40 is used to schedule a high-priority refresh thread if data is detected entering the high-priority queue, read the data in the high-priority queue and write it into the display frame buffer, and use the data in the display frame buffer to refresh the display instrument screen. The low-priority scheduling module 50 is used to schedule low-priority refresh threads at a preset period, read data from the low-priority queue and write it to the display frame buffer, and use the data in the display frame buffer to refresh the display instrument screen.

[0045] Furthermore, in one embodiment, the writing module 30 is used for: If the data to be refreshed does not overlap with the data in the historical frame buffer, the data to be refreshed will be written to either the high-priority queue or the low-priority queue.

[0046] Furthermore, in one embodiment, the low-priority scheduling module 50 includes: The traversal unit is used to traverse and identify jittery data in the low-priority queue and remove jittery data from the low-priority queue. The removal unit is used to write the removed low-priority queue data into the display frame buffer.

[0047] Furthermore, in one embodiment, the traversal unit is used for: For the current data in the low-priority queue being traversed, if the absolute value of the difference between the current data and the data from the previous traversal is less than the threshold for a preset number of consecutive times, then the current data is determined to be jittery data.

[0048] Furthermore, in one embodiment, the data refresh display device further includes an acquisition module, used for: A high-priority refresh thread or a low-priority refresh thread acquires the mutex lock of the display frame buffer; The data refresh display device also includes a release module for: After writing is complete, release the mutex lock on the display frame buffer.

[0049] Furthermore, in one embodiment, the identification module 20 is used for: If the data to be refreshed is a power level signal or a button signal, then the data to be refreshed is determined to be high-priority data. If the data to be refreshed is vehicle status data, diagnostic data, or statistical data, then the data to be refreshed is determined to be low-priority data.

[0050] Furthermore, in one embodiment, the identification module 20 is used for: Based on the data category to be refreshed and a preset mapping table, the data to be refreshed is determined to be either high-priority data or low-priority data. The preset mapping table includes the correspondence between the data category to be refreshed, high-priority data, and low-priority data.

[0051] The functions of each module in the above-mentioned data refresh display device correspond to the steps in the above-mentioned data refresh display method embodiment, and their functions and implementation processes will not be described in detail here.

[0052] Thirdly, embodiments of this application provide a data refresh display device.

[0053] Reference Figure 5 , Figure 5 This is a schematic diagram of the hardware structure of the data refresh display device involved in the embodiments of this application. In the embodiments of this application, the data refresh display device may include a processor, a memory, a communication interface, and a communication bus.

[0054] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.

[0055] Communication interfaces include input / output (I / O) interfaces, physical interfaces, and logical interfaces used for interconnecting internal components of the data refresh display device, as well as interfaces used for interconnecting the data refresh display device with other devices (such as other computing devices or user equipment). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user equipment can be displays, keyboards, etc.

[0056] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0057] The processor can be a general-purpose processor, which can call the data refresh display program stored in the memory and execute the data refresh display method provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the data refresh display program is called can be referred to in the various embodiments of the data refresh display method of this application, and will not be repeated here.

[0058] Those skilled in the art will understand that Figure 5 The hardware structure shown does not constitute a limitation of this application and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0059] Fourthly, embodiments of this application also provide a readable storage medium.

[0060] The present application has a data refresh display program stored on a readable storage medium, wherein when the data refresh display program is executed by a processor, it implements the steps of the data refresh display method described above.

[0061] The method implemented when the data refresh display program is executed can be referred to in various embodiments of the data refresh display method of this application, and will not be repeated here.

[0062] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0063] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0064] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0065] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0066] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0067] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0068] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A data refresh display method, characterized in that, include: The system on the instrument panel receives data to be updated. Identify the category of the data to be refreshed, and determine whether the data to be refreshed is high-priority or low-priority based on the category; Write the data to be refreshed into the corresponding high-priority queue or low-priority queue; If data is detected entering the high-priority queue, the high-priority refresh thread is scheduled to read the data from the high-priority queue and write it to the display frame buffer. The data in the display frame buffer is then used to refresh the display instrument screen. The low-priority refresh thread is scheduled at a preset period to read data from the low-priority queue and write it to the display frame buffer. The data in the display frame buffer is then used to refresh the display instrument screen.

2. The data refresh display method as described in claim 1, characterized in that, The step of writing the data to be refreshed into a high-priority queue or a low-priority queue includes: If the data to be refreshed does not overlap with the data in the historical frame buffer, the data to be refreshed will be written to the corresponding high-priority queue or low-priority queue.

3. The data refresh display method as described in claim 1, characterized in that, The step of reading data from the low-priority queue and writing it to the display frame buffer includes: Traverse and identify jittery data in the low-priority queue, and remove jittery data from the low-priority queue; Write the data from the removed low-priority queue into the display frame buffer.

4. The data refresh display method as described in claim 3, characterized in that, The process of traversing and identifying jittery data in the low-priority queue includes: For the current data in the low-priority queue being traversed, if the absolute value of the difference between the current data and the data from the previous traversal is less than the threshold for a preset number of consecutive times, then the current data is determined to be jittery data.

5. The data refresh display method as described in claim 1, characterized in that, Before writing to the display frame buffer, the following is included: A high-priority refresh thread or a low-priority refresh thread acquires the mutex lock of the display frame buffer; After writing to the display frame buffer, the following is included: After writing is complete, release the mutex lock on the display frame buffer.

6. The data refresh display method as described in claim 1, characterized in that, The step of determining whether the data to be refreshed is high-priority or low-priority data based on the category of the data to be refreshed includes: If the data to be refreshed is a power level signal or a button signal, then the data to be refreshed is determined to be high-priority data. If the data to be refreshed is vehicle status data, diagnostic data, or statistical data, then the data to be refreshed is determined to be low-priority data.

7. The data refresh display method as described in claim 1, characterized in that, The step of determining whether the data to be refreshed is high-priority or low-priority data based on the category of the data to be refreshed includes: Based on the data category to be refreshed and a preset mapping table, the data to be refreshed is determined to be either high-priority data or low-priority data. The preset mapping table includes the correspondence between the data category to be refreshed, high-priority data, and low-priority data.

8. A data refresh display device, characterized in that, include: The receiving module is used by the system on the instrument chip to receive data to be refreshed; The identification module is used to identify the category of the data to be refreshed and determine whether the data to be refreshed is high-priority data or low-priority data based on the category. The write module is used to write the data to be refreshed into the corresponding high-priority queue or low-priority queue. The high-priority scheduling module is used to schedule a high-priority refresh thread if data is detected entering the high-priority queue. The thread reads the data from the high-priority queue and writes it to the display frame buffer, and then uses the data in the display frame buffer to refresh the display instrument screen. The low-priority scheduling module is used to schedule low-priority refresh threads at a preset period, read data from the low-priority queue and write it to the display frame buffer, and use the data in the display frame buffer to refresh the display instrument screen.

9. A data refresh display device, characterized in that, The data refresh display device includes a processor, a memory, and a data refresh display program stored in the memory and executable by the processor, wherein when the data refresh display program is executed by the processor, it implements the steps of the data refresh display method as described in any one of claims 1 to 7.

10. A readable storage medium, characterized in that, The readable storage medium stores a data refresh display program, wherein when the data refresh display program is executed by a processor, it implements the steps of the data refresh display method as described in any one of claims 1 to 7.

Images