A dynamic pet background display method and device, electronic equipment and storage medium

Abstract

The application provides a display method and device of a dynamic pet background, electronic equipment and a storage medium. The method comprises: in response to a picture generation operation, generating a target pet preset format action sequence, the action sequence comprising a standby action sequence and an event action sequence; storing each action sequence in an action folder in an MCU, and storing the association between each action sequence and a triggering event; when no triggering event of the vehicle is detected, reading and randomly playing the standby action sequence from the action folder corresponding to the standby action sequence according to the association; and when a triggering event of the vehicle is detected, reading and playing the corresponding event action sequence from the action folder corresponding to the triggering event according to the association. The application can realize the dynamic pet background display driven by the vehicle event on the MCU with scarce resources, and improve the interactivity and user experience of the instrument.

Description

Technical Field

[0001] This application relates to the field of image processing technology, and more specifically, to a method, apparatus, electronic device, and storage medium for displaying dynamic pet backgrounds. Background Technology

[0002] With the intelligent development of vehicles such as two-wheeled electric vehicles, users have higher requirements for the interactive experience of LCD instrument panels. In addition to displaying basic vehicle status data such as speed and battery level, users expect the instrument panel to present personalized dynamic pet backgrounds to enhance the vehicle's technological feel and fun.

[0003] Currently, in common LCD instrument panels, the different actions of pets (such as standby actions and event actions) are usually stored in a scattered manner. This makes it difficult to switch between actions based on vehicle status during playback, resulting in monotonous animation and an inability to distinguish between normal and special event states. Furthermore, existing instrument panels cannot establish a correlation between vehicle-triggered events (such as acceleration, braking, and turning) and pet actions. When a specific event occurs in the vehicle, the pet background does not react accordingly, resulting in poor interactivity and a poor user experience. Simultaneously, in environments with limited MCU resources, existing technology does not provide a method to simultaneously store multiple sets of standby and event actions and to quickly read and play the corresponding actions based on event detection results. This causes the system to repeatedly play a single animation when there are no events, and to fail to respond promptly when events occur, resulting in abrupt animation transitions or even stuttering. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide a method, apparatus, electronic device and storage medium for displaying dynamic pet backgrounds to overcome the problems in the prior art.

[0005] In a first aspect, embodiments of this application provide a method for displaying a dynamic pet background, the method comprising: In response to the image generation operation, a sequence of candidate actions in a preset format for the target pet is generated; the sequence of candidate actions includes multiple frames of images showing the action, and includes a standby action sequence and an event action sequence. In response to the information storage operation, each of the candidate action sequences is stored in an action folder in the MCU, and the association between each candidate action sequence and the triggering event is stored in the MCU; When no vehicle triggering event is detected, the standby action sequence is read from the action folder corresponding to the standby action sequence and played randomly according to the association relationship; When the vehicle's trigger event is detected, the event action sequence corresponding to the trigger event is read from the action folder corresponding to the trigger event and played according to the association relationship.

[0006] In some technical solutions of this application, when the preset format is PNG, the above method plays the video in the following way: Decode the pixel data of any first frame image. The pixel data decoded from the first frame image is blended with the background image corresponding to the first frame image using a blending formula to form a first buffer frame and store it in the background cache. When the frame rate timer is triggered and the LCD screen is in the refresh idle area, the cache pointer is switched and the first buffer frame is used as the display cache for display. While displaying the first buffered frame, the pixel data of the second frame image decoded using the mixing formula is layer-blended with the background image corresponding to the second frame image to form a second buffered frame, which is stored in the background cache. When the next frame rate timer is triggered and the LCD screen refresh is idle, the cache pointer is switched, and the second buffered frame is used as the display cache for display.

[0007] In some technical solutions of this application, the above method also includes: Based on the target pet and the stored candidate action sequence, determine the upgrade status of the target pet and send the upgrade status to the mobile terminal so that the mobile terminal can determine the pet to be upgraded and the action sequence to be upgraded based on the upgrade status. Receive the action data packet header sent by the mobile terminal; wherein the action data packet header includes a first identifier of the pet to be upgraded and a second identifier of the action sequence to be upgraded; The third identifier of the target pet and the fourth identifier of the candidate action sequence are verified based on the first identifier and the second identifier, respectively, to obtain the verification result; Based on the verification results, update the action folder and replace the target pet.

[0008] In some technical solutions of this application, the upgrade status of the target pet includes standby status, resume status, and replacement status; the step of determining the upgrade status of the target pet based on the target pet and the stored candidate action sequence includes: When the target pet already possesses all the action sequences to be upgraded on the mobile device, it is in the standby state; When the target pet already exists but lacks the mobile portion of the action sequence to be upgraded, it is in the resume state; When the pet to be upgraded on the mobile device is different from the target pet, and the pet to be upgraded does not exist in the current storage, it is in the replacement state.

[0009] In some technical solutions of this application, the above-mentioned verification of the third identifier of the target pet and the fourth identifier of the candidate action sequence based on the first identifier and the second identifier respectively, to obtain the verification result, includes: If the first identifier is the same as the third identifier, and the second identifier is different from the fourth identifier, then the verification result is that the missing action of the target pet needs to be supplemented. If the first identifier is different from the third identifier, the verification result is that the target pet needs to be replaced with the pet to be upgraded. If the first identifier is the same as the third identifier, and the second identifier is the same as any of the stored fourth identifiers, then an error message is returned to the mobile device, and no update is performed.

[0010] In some technical solutions of this application, when it is necessary to supplement the missing actions of the target pet, the sequence of actions to be upgraded transmitted by the mobile terminal is received and parsed to obtain pixel data. The pixel data is stored in a backup folder, and a CRC check is performed on the pixel data after the data is received. After the pixel data verification is successful, the backup folder is renamed to the action folder; After all the action sequences to be upgraded and the associated relationships have been transmitted and verified, delete the original action folder of the target pet and the information file storing the associated relationships, and switch to the updated current pet for display.

[0011] In some technical solutions of this application, the above-mentioned multi-frame images are in PNG format and are stored using a 4-bit palette index mode. Secondly, embodiments of this application provide a display device for a dynamic pet background, the device comprising: The generation module is used to generate a sequence of candidate actions in a preset format for the target pet in response to the image generation operation; the sequence of candidate actions includes multiple frames of images that complete the action, and the sequence of candidate actions includes a standby action sequence and an event action sequence. A storage module is used to, in response to an information storage operation, store each of the candidate action sequences in an action folder in the MCU, and store the association between each candidate action sequence and the triggering event in the MCU; The first playback module is used to read and randomly play the standby action sequence from the action folder corresponding to the standby action sequence according to the association relationship when no vehicle triggering event is detected. The second playback module is used to read and play the sequence of events corresponding to the trigger event from the action folder corresponding to the trigger event according to the association relationship when the trigger event of the vehicle is detected.

[0012] Thirdly, embodiments of this application provide an electronic device, a processor, a memory, and a bus. The memory stores machine instructions executed by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine instructions are executed by the processor, the steps of the above-described dynamic pet background display method are performed.

[0013] Fourthly, embodiments of this application provide a computer storage medium storing a computer program, which, when run by a processor, executes the steps of the above-described dynamic pet background display method.

[0014] The technical solutions provided by the embodiments of this application may include the following beneficial effects: This application's method includes, in response to an image generation operation, generating a sequence of candidate actions in a preset format for a target pet; the sequence of candidate actions includes multiple frames of images showing the action, and includes a standby action sequence and an event action sequence; in response to an information storage operation, storing each of the candidate action sequences in an action folder within an MCU, and storing the association between each candidate action sequence and a triggering event in the MCU; when no vehicle triggering event is detected, reading and randomly playing the standby action sequence from the action folder corresponding to the standby action sequence according to the association; when a vehicle triggering event is detected, reading and playing the event action sequence corresponding to the triggering event from the action folder corresponding to the triggering event according to the association.

[0015] This application stores the standby action sequence and event action sequence of a dynamic pet in separate action folders on a resource-constrained MCU, and establishes an association between each action sequence and vehicle trigger events. This allows the vehicle's infotainment system to randomly play standby action sequences based on the association when no trigger event is detected, enriching the display diversity in static scenes. When trigger events such as acceleration or braking are detected, the corresponding event action sequence can be read and played immediately, achieving real-time interaction between the pet background and vehicle status. This avoids the shortcomings of existing technologies, such as monotonous animation and inability to respond to vehicle events. At the same time, the folder-based and association-based organization method reduces the MCU's parsing overhead during playback, improving the system's response speed and smoothness. It realizes dynamic and interactive pet background display on a resource-constrained embedded platform, enhancing the user experience and the intelligence level of the instrument panel.

[0016] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A flowchart illustrating a method for displaying a dynamic pet background according to an embodiment of this application is shown; Figure 2 A schematic diagram of a cache pointer provided in an embodiment of this application is shown; Figure 3 A schematic diagram of a display device for a dynamic pet background provided in an embodiment of this application is shown; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0020] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0021] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0022] With the intelligent development of vehicles such as two-wheeled electric vehicles, users have higher requirements for the interactive experience of LCD instrument panels. In addition to displaying basic vehicle status data such as speed and battery level, users expect the instrument panel to present personalized dynamic pet backgrounds to enhance the vehicle's technological feel and fun.

[0023] Currently, in common LCD instrument panels, the different actions of pets (such as standby actions and event actions) are usually stored in a scattered manner. This makes it difficult to switch between actions based on vehicle status during playback, resulting in monotonous animation and an inability to distinguish between normal and special event states. Furthermore, existing instrument panels cannot establish a correlation between vehicle-triggered events (such as acceleration, braking, and turning) and pet actions. When a specific event occurs in the vehicle, the pet background does not react accordingly, resulting in poor interactivity and a poor user experience. Simultaneously, in environments with limited MCU resources, existing technology does not provide a method to simultaneously store multiple sets of standby and event actions and to quickly read and play the corresponding actions based on event detection results. This causes the system to repeatedly play a single animation when there are no events, and to fail to respond promptly when events occur, resulting in abrupt animation transitions or even stuttering.

[0024] Based on this, embodiments of this application provide a method, apparatus, electronic device, and storage medium for displaying dynamic pet backgrounds, which are described below through embodiments.

[0025] Figure 1 The diagram illustrates a flowchart of a method for displaying a dynamic pet background according to an embodiment of this application, wherein the method includes steps S101-S104; specifically: S101. In response to the image generation operation, generate a candidate action sequence in a preset format for the target pet; the candidate action sequence includes multiple frames of images that complete the action, and the candidate action sequence includes a standby action sequence and an event action sequence; S102. In response to the information storage operation, each of the candidate action sequences is stored in an action folder in the MCU, and the association between each candidate action sequence and the triggering event is stored in the MCU. S103. When no vehicle triggering event is detected, the standby action sequence is read from the action folder corresponding to the standby action sequence and played randomly according to the association relationship. S104. When the triggering event of the vehicle is detected, the event action sequence corresponding to the triggering event is read from the action folder corresponding to the triggering event and played according to the association relationship.

[0026] By storing the standby action sequence and event action sequence of the dynamic pet in separate action folders on a resource-constrained MCU, and establishing an association between each action sequence and vehicle trigger events, the vehicle's infotainment system can randomly play standby action sequences based on the association when no trigger event is detected. This enriches the display diversity in static scenes on the instrument panel. When trigger events such as acceleration or braking are detected, the corresponding event action sequence can be read and played immediately, realizing real-time interaction between the pet background and vehicle status. This avoids the shortcomings of existing technologies, such as monotonous animations and inability to respond to vehicle events. At the same time, the folder-based and association-based organization method reduces the MCU's parsing overhead during playback, improves the system's response speed and smoothness, and realizes dynamic and interactive pet background display on a resource-constrained embedded platform, enhancing the user experience and the intelligence level of the instrument panel.

[0027] The following describes some embodiments of this application in detail. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0028] This application provides a method for displaying dynamic pet backgrounds, applied to in-vehicle infotainment systems. The in-vehicle infotainment system typically includes an MCU (microcontroller), an LCD screen, and a communication module (such as Bluetooth, CAN, or RS-485 bus). The system can interact with mobile devices (such as a user's smartphone) via Bluetooth. This method aims to implement event-driven dynamic pet animation display on a resource-constrained MCU and supports upgrading pet materials via a mobile device.

[0029] First, in response to the image generation operation, a sequence of potential actions for the target pet in a preset format is generated. This image generation operation is typically performed on a personal computer by designers using video editing software, such as Adobe After Effects, to render and export each individual action of the pet character. The target pet refers to the specific pet image that the user expects to display on the vehicle's LCD instrument panel, such as a cartoon cat or a cartoon dog. The preset format refers to the image file format pre-defined to accommodate subsequent decoding and display on the microcontroller (MCU). This preset format can be any bitmap format that supports alpha channels. PNG format is preferred because it supports lossless compression and alpha transparency, facilitating blending with background layers.

[0030] In an optional implementation, the preset format is a custom file format containing a global color lookup table. Its generation process further utilizes color quantization and region cropping techniques: the full-screen pixel-size pet action video is converted into multiple PNG format initial images at a preset frame rate; an octree color quantization algorithm is used to reduce the colors of the initial images to a finite color set with a preset color depth, generating a global color lookup table; and a Floyd-Steinberg error diffusion jitter algorithm is used to generate palette index values ​​for each pixel based on the global color lookup table; by scanning the alpha channel of each frame, transparent pixels are determined using a preset transparency threshold; a connected component analysis algorithm is used to determine the minimum bounding rectangle of opaque pixels as the cropping region; and the cropping offset coordinates and cropped size of each frame are recorded; the cropping offset coordinates, size, and pixel color index of each processed frame are organized with the magic number identifier, version number, global color lookup table, and total number of frames according to a preset binary structure to form the candidate action sequence.

[0031] In practice, the process begins by converting the full-screen pixel-size pet action video into multiple PNG format images at a preset frame rate. Then, an octree color quantization algorithm is used to reduce the number of colors in the original 24-bit true-color images from millions to a limited color set suitable for MCU platform display. This color depth can be flexibly selected based on the pet's color characteristics; for example, 8 bits correspond to 256 colors, 6 bits to 64 colors, or lower bit depth indexed colors. A global color lookup table is generated, recording the ARGB8888 format color corresponding to each index value. Next, the Floyd-Steinberg error diffusion dithering algorithm is used to calculate a palette index value for each pixel based on this global color lookup table, maintaining a smooth visual transition within the limited color set.

[0032] After color quantization, the alpha channel of each frame is scanned to determine transparent pixels using a preset transparency threshold, which can be set to an alpha value less than 5. A connected component analysis algorithm is then run to find the smallest bounding rectangle formed by all opaque pixels. This rectangular area is used as the effective image area after cropping, and the pixel offset coordinates (x and y) of the top-left corner of this rectangle relative to the original image, as well as the width (w) and height (h) of the cropped image, are recorded.

[0033] After the above processing, all frame data is organized into a compact binary file. The file structure includes, in sequence: a magic number identifier (4 bytes, a fixed value); a version number (4 bytes, used to distinguish different screen pixel sizes); the number of color bits in the global color lookup table (1 byte); a reserved field; the global color lookup table, stored contiguously in ARGB8888 format, with the number of entries determined by the number of color bits; and the total number of frames in the current file (2 bytes). For each frame, the following are stored consecutively: pixel offset x (2 bytes); pixel offset y (2 bytes); image width w (2 bytes); image height h (2 bytes); and finally, the pixel color index sequence for that frame, with a length equal to the width multiplied by the height in bytes. For ease of use by designers, the entire process can be integrated into an offline toolchain. Designers only need to provide a full-screen PNG frame sequence containing an alpha channel, and the tool can perform color quantization, region cropping, generation of proprietary formats, and output files with a single click.

[0034] Each candidate action sequence corresponds to all the frames required for the pet to complete a specific action. For example, a complete entrance action might require thirty consecutive frames of images showing the pet walking from off-screen to the center of the frame, while a standby action might require twenty frames of images showing the pet looking left and right. The candidate action sequence includes multiple frames of images showing the action, arranged chronologically, with each frame representing the pet's posture at a particular moment. Depending on the function and application scenario of the action, the candidate action sequence includes at least a standby action sequence and an event action sequence. A standby action sequence refers to the pet's daily, repetitive actions when there are no special events in the vehicle, such as stretching, yawning, or looking left and right. To increase interest, multiple different standby action sequences are usually designed for the system to randomly select and play. An event action sequence refers to the pet's corresponding reaction actions when a specific triggering event occurs in the vehicle. These triggering events include rapid acceleration, emergency braking, left turn, right turn, or vehicle shutdown. Corresponding event actions include the pet leaning forward when braking, or the pet leaning to the left when turning left. By classifying the candidate action sequences into two categories, standby actions and event actions, a foundation is laid for subsequent real-time animation switching based on vehicle status.

[0035] In response to the information storage operation, this application stores each of the candidate action sequences in an action folder within a microcontroller (MCU), and stores the association between each candidate action sequence and the triggering event within the MCU. The information storage operation refers to the process of transferring the pet materials obtained from the image generation operation to the file system of the vehicle-mounted MCU. This file system can be any file system suitable for an embedded environment, preferably a lightweight embedded file system such as LittleFS or SPIFFS. Specifically, this application uses the LittleFS file system. Each candidate action sequence is stored in an action folder within the MCU, meaning each action corresponds to an independent folder.

[0036] To achieve unified resource management, the vehicle-mounted system creates a root folder for the current target pet. This root folder's name is typically associated with the target pet's ID or identifier. Within this root folder, a subfolder named after the action ID is created for each candidate action sequence. This subfolder is the action folder, containing the multi-frame image files corresponding to that action. For example, if the target pet's ID is P1, and the action ID for the standby action sequence is act1, then all standby action frame images are stored in the act1 subfolder under the P1 root folder; if the action ID for the event action sequence is act2, then its frame images are stored in the act2 subfolder.

[0037] Meanwhile, this application also stores the association between each candidate action sequence and the triggering event in the MCU. The triggering event refers to a specific state change that can be detected during vehicle operation, such as acceleration, braking, left turn, right turn, or shutdown. The association refers to the mapping rule between action numbers and vehicle events, i.e., which event corresponds to which action sequence. This association can be represented as a mapping table from event to action number. Preferably, this application records this mapping relationship in a separate information file, such as an info.bin file. In a specific implementation, the info.bin file is stored in the root folder of the target pet alongside all action folders, and the file content includes at least the number of actions, the number of sequence frames for each action, and the binding relationship between vehicle events and action numbers. By storing the candidate action sequences in a structured action folder and storing the association relationship separately, the MCU can quickly locate the image resource of the specified action without traversing the entire file system during runtime, and efficiently find the corresponding action number based on the triggering event, thereby providing low-latency data support for subsequent real-time switching playback.

[0038] In an optional implementation, this application uses PNG format images. Standard PNG supports multiple color modes, including true color, grayscale, and indexed color. Specifically, this application further employs a 4-bit palette index mode to store PNG images, meaning each pixel is represented by a 4-bit index value, supporting up to 16 different colors. Since pet cartoon characters are typically composed of large areas of continuous and similar colors, 16 colors are sufficient to reproduce the pet's visual effect. Compared to 24-bit true color PNG images, the 4-bit index mode can reduce the storage space of a single frame image to about one-sixth of the original, thereby significantly reducing the Flash memory usage within the MCU and enabling resource-constrained MCUs to accommodate multiple pet action sequences and more animation frames. Simultaneously, this storage mode is also faster during decoding on the MCU, eliminating the need to handle complex color transformations and improving the smoothness of animation playback.

[0039] During operation of the in-vehicle infotainment system, this application determines which type of action sequence to play based on whether a trigger event occurs in the vehicle. Specifically, when no trigger event is detected, the system reads and randomly plays the standby action sequence from the action folder corresponding to the standby action sequence, based on the aforementioned association. The trigger event refers to a specific perceptible state change during vehicle operation, including any abnormal or command signals collected via the vehicle bus or sensors, such as common driving operations like acceleration, braking, left turn, right turn, power on, and power off. In a specific implementation, for example, if the brake pedal is detected being pressed via the CAN bus or a backward acceleration exceeding a threshold is detected by an acceleration sensor, it is determined to be a braking event. When the system confirms through polling or interruption that no preset trigger event has occurred, i.e., the vehicle is in a constant speed, stationary, or stable operating state, the in-vehicle infotainment system enters standby display mode.

[0040] Based on the association relationships, the vehicle-mounted system first retrieves the action folder corresponding to the standby action sequence. These association relationships are pre-stored in an information file, such as info.bin, which defines the mapping between standby actions and specific action numbers. Typically, multiple different standby actions correspond to multiple different action folders. The vehicle-mounted system randomly selects one of these standby action folders and then reads multiple frames of PNG images from that folder. The random playback refers to the system randomly selecting the next standby action from the entire set of standby actions after each complete playback of a standby action, rather than looping in a fixed order.

[0041] For example, if the system is designed with three standby actions: "looking left and right," "stretching," and "yawning," it might first play "looking left and right" after powering on, then randomly select "yawning," then randomly select "stretching," and so on. This random mechanism avoids repetition and enhances the liveliness of the dynamic pet and the user's visual enjoyment.

[0042] After reading the image, the vehicle's infotainment system continuously plays the standby action sequence through decoding and display driver. During playback, the system continuously monitors vehicle events. Once a trigger event is detected, the current standby action is immediately interrupted, and the corresponding event action is played in turn, thus achieving real-time interaction between the pet background and the vehicle status. Through the above method, this application ensures the fun and diversity of the instrument panel display when no event occurs, while reserving a quick switching channel for event response.

[0043] In an optional implementation of this application, when the preset format is PNG, smooth animation playback is achieved through the following method: First, the first frame image in any action sequence is decoded to obtain the pixel data of that frame image. Decoding refers to converting a compressed PNG image into a raw pixel array that can be directly displayed on the LCD screen, for example, using the lightweight LoadPNG decoding library executed on the MCU. After obtaining the pixel data, a blending formula is used to blend the decoded pixel data of the first frame image with the background image at the corresponding position of the first frame image to form a first buffer frame, which is then stored in the background buffer. The blending formula refers to a pixel blending algorithm with an alpha channel, which allows the pet image to be transparently superimposed on the instrument background. The background buffer is a temporary storage area allocated in the MCU memory to store images that have not yet been displayed. When the frame rate timer is triggered and the LCD screen is in a refresh idle area, the buffer pointer is switched, and the first buffer frame is displayed as the display buffer. The frame rate timer is used to control the playback speed of the animation, for example, triggering thirty times per second; the refresh idle area refers to the line blanking or vertical blanking time period during the progressive scan of the LCD screen, and switching the display buffer at this time can avoid screen tearing.

[0044] While displaying the first buffered frame, the second frame image is decoded to obtain pixel data. A blending formula is used to blend the decoded pixel data of the second frame image with its corresponding background image to form a second buffered frame, which is then stored in the background cache. When the next frame rate timer is triggered and the LCD screen is again in a refresh idle area, the cache pointer is switched, and the second buffered frame is used as the display cache for display. Figure 2As shown. This process repeats continuously, with the decoding and mixing operations running in parallel with the display refresh process. This ensures that each frame is prepared in the background before switching to the display, thus achieving continuous and smooth animation on a resource-constrained MCU and avoiding stuttering and screen tearing.

[0045] In an optional embodiment of this application, when the preset format is a custom file format, the animation is played in the following manner: the global color lookup table is read from the FLASH memory into RAM; the offset coordinates and dimensions of each frame are read sequentially, the pixel colors are obtained by looking up the table and drawn to the graphics memory; the image information of the next frame is prefetched while waiting for the frame synchronization signal, and the graphics memory pointer is switched and the next frame is drawn when the frame synchronization signal is triggered; the animation is played through a double buffering and preloading mechanism, and the custom file format is adapted to the graphics accelerator in the MCU to complete the index mapping and pixel filling through hardware acceleration.

[0046] In practical implementation, when the MCU decodes and plays the custom format file, it first reads the global color lookup table from the FLASH memory and temporarily stores it in RAM. After playback begins, it reads the offset coordinates, width, and height of the first frame, retrieves the pixel color from the lookup table according to the index, and draws it into the screen's graphics memory. While waiting for the LCD screen frame synchronization signal, it prefetches the image information of the second frame. When the frame synchronization signal is triggered, it immediately switches the graphics memory pointer, switching the graphics memory to the display memory, and then draws the prefetched second frame image into the new graphics memory. This double buffering and preloading mechanism achieves smooth, tear-free animation playback. This color lookup table-based image organization method is particularly well-suited for graphics accelerator IPs in MCUs, such as the DMA2D of the STM32, GD32, or MH2457 series. By leveraging hardware acceleration to complete index mapping and pixel filling, it significantly improves display smoothness and reduces software decoding complexity.

[0047] In an optional implementation, this application also supports remote upgrading of pet materials. The upgrade process specifically includes the following steps.

[0048] First, the vehicle-mounted system determines the upgrade status of the target pet based on the currently stored target pet and the already stored candidate action sequences, and sends this upgrade status to the mobile device. The mobile device then uses this upgrade status to determine the pet and action sequences to be upgraded. The target pet refers to the pet image currently displayed on the vehicle-mounted system, and the already stored candidate action sequences refer to the pet's existing action folder and its frame images. The upgrade status reflects the difference between the current pet and the new pet materials planned to be pushed to the mobile device. This application specifically divides the upgrade status into standby state, resume state, and replacement state.

[0049] In specific implementation details, when the target pet already possesses all the action sequences to be upgraded and pushed by the mobile device, the upgrade status is standby, indicating that no update is required. When the target pet exists but lacks some of the action sequences to be upgraded by the mobile device, the upgrade status is resume, indicating that only the missing actions need to be added. When the upgrade pet to be pushed by the mobile device is different from the current target pet, and the new pet does not exist in the vehicle's storage, the upgrade status is replacement, indicating that the current pet needs to be completely replaced with a brand new pet. The vehicle's system sends this upgrade status to the mobile device via Bluetooth or other wireless communication methods. The mobile device then determines the subsequent transmission strategy accordingly; for example, in the resume state, only the missing action data packets are sent, while in the replacement state, the complete new pet data packets are sent.

[0050] Secondly, the vehicle-mounted system receives the action data packet header sent by the mobile terminal. This action data packet header contains a first identifier of the pet to be upgraded and a second identifier of the action sequence to be upgraded. The first identifier is a number or name used to uniquely identify the pet, such as "P2"; the second identifier is a number used to uniquely identify the action sequence, such as "act4". The vehicle-mounted system then verifies the third identifier of the current target pet and the fourth identifier of the stored candidate action sequences based on the first and second identifiers, thereby obtaining the verification result. The third identifier is the current pet's identity identifier, and the fourth identifier is the set of numbers for each currently stored action sequence.

[0051] The verification process involves comparing the pet and actions requested by the mobile device with existing resources on the vehicle's infotainment system. Specifically, the following logic applies: if the first identifier matches the third identifier, and the second identifier differs from all stored fourth identifiers, the verification result indicates that the missing actions for the target pet need to be added; if the first identifier differs from the third identifier, the verification result indicates that the target pet needs to be replaced with the pet to be upgraded; if the first identifier matches the third identifier, and the second identifier matches any stored fourth identifier, an error message is returned to the mobile device, and no update is performed. This verification mechanism effectively prevents the duplicate transmission of existing actions and avoids error overwriting.

[0052] Finally, the vehicle-mounted system performs the corresponding action folder update or target pet replacement operation based on the above verification results. For cases requiring missing actions, the vehicle-mounted system receives the action sequence data packet to be upgraded from the mobile device, stores the data in a temporary backup folder, and after verification, renames the backup folder to the official action folder, thus adding the new actions to the current pet's action set. For cases requiring a completely new pet, the vehicle-mounted system receives the complete data packet of the new pet, creates a new root folder and action folder, deletes all resources of the old pet after verification, and switches to display the new pet. Through the above upgrade process, this application implements a reliable and resumable remote upgrade function for pet materials on resource-constrained MCUs.

[0053] In an optional implementation, when it is necessary to supplement the missing actions of the target pet, this application performs the following upgrade process. First, the vehicle-mounted system receives the action sequence to be upgraded transmitted from the mobile terminal and parses the received data to obtain the pixel data of each frame image in the action sequence. The action sequence to be upgraded is usually transmitted in the form of a packaged file, such as a tar format data packet, which contains all sequence frame images of a certain missing action and related descriptive information. During the receiving process, the vehicle-mounted system receives and parses the data packet, extracts the original encoded data of each frame image from the data packet, and then converts it into pixel data that can be displayed on the LCD screen through a decoding operation.

[0054] Next, the vehicle-mounted system stores the parsed pixel data into a backup folder. This backup folder is a temporary storage area, typically named in association with but distinct from the official action folder, for example, by adding a "_bak" suffix to the official folder name. By using the backup folder, the vehicle-mounted system avoids directly modifying or overwriting the existing action folder during reception, thus preventing damage to existing resources due to transmission interruptions or data errors. After reception is complete, the vehicle-mounted system performs a CRC check on the entire sequence of actions to be upgraded. CRC, or Cyclic Redundancy Check, is a commonly used method for detecting data transmission errors. The mobile terminal includes a pre-calculated CRC value when sending data packets; after receiving all data, the vehicle-mounted system calculates its local CRC value using the same algorithm and compares the two values.

[0055] If the CRC check is successful, it indicates that the received data is complete and error-free. The vehicle's infotainment system then renames the backup folder to the official action folder. This renaming operation is atomic, meaning it's completed instantly, making the new action content effective immediately. Subsequently, the infotainment system continues to receive and process any missing action sequences and updated associations. Once all action sequences to be upgraded and the information files carrying associations have been transmitted and passed CRC check, the infotainment system deletes the target pet's original action folder and the information files storing associations. This deletes the old version of the action content and the old association files, while the new version is already usable after the renaming operation. Finally, the infotainment system switches the display, showing the updated current pet on the LCD instrument panel. Throughout the entire process, the original pet content is retained and plays normally until the upgrade is complete. Old data is only deleted after all new data has been verified and the backup folder has been renamed, thus ensuring the safety and reliability of the upgrade process. Even if an anomaly occurs during the upgrade, the infotainment system can still revert to the original pet for display.

[0056] In an optional implementation, in addition to enabling remote upgrades, this method also introduces a version management strategy for pet assets. The vehicle-mounted file system is designed with a pre-planned upper limit on the number of pet asset sets that can be stored, based on the remaining space, for example, a maximum of three complete pet asset sets. When a user downloads new pet assets via their mobile device and successfully verifies them, the system determines the number of pet assets currently stored: if the number is less than the upper limit, only the currently displayed pet icon is switched to the latest pet icon, while the old assets are retained; if the upper limit has been reached, the oldest pet asset set is deleted to free up space, and then the new pet asset is written to the file system, after which the displayed pet icon is switched. Through this rolling replacement mechanism, storage space is always kept under control.

[0057] Furthermore, if a user wants to revert to a previously saved version after using a new pet for a period of time, the system directly provides an interface to switch the pet's identifier, eliminating the need for re-downloading. As long as the target pet's assets are still stored in the file system, the vehicle's infotainment system can instantly switch displays, enabling flexible rollback between multiple versions and greatly improving the convenience and fault tolerance of asset management.

[0058] Figure 3 This illustration shows a structural schematic diagram of a dynamic pet background display device provided in an embodiment of this application. The device includes: The generation module is used to generate a sequence of candidate actions in a preset format for the target pet in response to the image generation operation; the sequence of candidate actions includes multiple frames of images that complete the action, and the sequence of candidate actions includes a standby action sequence and an event action sequence. A storage module is used to, in response to an information storage operation, store each of the candidate action sequences in an action folder in the MCU, and store the association between each candidate action sequence and the triggering event in the MCU; The first playback module is used to read and randomly play the standby action sequence from the action folder corresponding to the standby action sequence according to the association relationship when no vehicle triggering event is detected. The second playback module is used to read and play the sequence of events corresponding to the trigger event from the action folder corresponding to the trigger event according to the association relationship when the trigger event of the vehicle is detected.

[0059] When the preset format is PNG, it can be played in the following way: Decode the pixel data of any first frame image. The pixel data decoded from the first frame image is blended with the background image corresponding to the first frame image using a blending formula to form a first buffer frame and store it in the background cache. When the frame rate timer is triggered and the LCD screen is in the refresh idle area, the cache pointer is switched and the first buffer frame is used as the display cache for display. While displaying the first buffered frame, the pixel data of the second frame image decoded using the mixing formula is layer-blended with the background image corresponding to the second frame image to form a second buffered frame, which is stored in the background cache. When the next frame rate timer is triggered and the LCD screen refresh is idle, the cache pointer is switched, and the second buffered frame is used as the display cache for display.

[0060] The upgrade module is used to determine the upgrade status of the target pet based on the target pet and the stored candidate action sequence, and send the upgrade status to the mobile terminal so that the mobile terminal can determine the pet to be upgraded and the action sequence to be upgraded based on the upgrade status. Receive the action data packet header sent by the mobile terminal; wherein the action data packet header includes a first identifier of the pet to be upgraded and a second identifier of the action sequence to be upgraded; The third identifier of the target pet and the fourth identifier of the candidate action sequence are verified based on the first identifier and the second identifier, respectively, to obtain the verification result; Based on the verification results, update the action folder and replace the target pet.

[0061] The upgrade status of the target pet includes standby status, resume status, and replacement status; determining the upgrade status of the target pet based on the target pet and the stored candidate action sequence includes: When the target pet already possesses all the action sequences to be upgraded on the mobile device, it is in the standby state; When the target pet already exists but lacks the mobile portion of the action sequence to be upgraded, it is in the resume state; When the pet to be upgraded on the mobile device is different from the target pet, and the pet to be upgraded does not exist in the current storage, it is in the replacement state.

[0062] The step of verifying the third identifier of the target pet and the fourth identifier of the candidate action sequence based on the first and second identifiers respectively, and obtaining the verification result, includes: If the first identifier is the same as the third identifier, and the second identifier is different from the fourth identifier, then the verification result is that the missing action of the target pet needs to be supplemented. If the first identifier is different from the third identifier, the verification result is that the target pet needs to be replaced with the pet to be upgraded. If the first identifier is the same as the third identifier, and the second identifier is the same as any of the stored fourth identifiers, then an error message is returned to the mobile device, and no update is performed.

[0063] When it is necessary to supplement the missing actions of the target pet, the sequence of actions to be upgraded transmitted from the mobile terminal is received and parsed to obtain pixel data; The pixel data is stored in a backup folder, and a CRC check is performed on the pixel data after the data is received. After the pixel data verification is successful, the backup folder is renamed to the action folder; After all the action sequences to be upgraded and the associated relationships have been transmitted and verified, delete the original action folder of the target pet and the information file storing the associated relationships, and switch to the updated current pet for display.

[0064] The multi-frame images are in PNG format and are stored using a 4-bit palette index mode. like Figure 4 As shown, this application provides an electronic device for executing the dynamic pet background display method of this application. The device includes a memory, a processor, a bus, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the dynamic pet background display method described above.

[0065] Specifically, the aforementioned memory and processor can be general-purpose memory and processor, without any specific limitations. When the processor runs the computer program stored in the memory, it can execute the aforementioned method for displaying dynamic pet backgrounds.

[0066] Corresponding to the dynamic pet background display method in this application, this application embodiment also provides a computer storage medium storing a computer program, which is executed by a processor to perform the steps of the above-described dynamic pet background display method.

[0067] Specifically, the storage medium can be a general-purpose storage medium, such as a removable disk or hard disk. When the computer program on the storage medium is run, it can execute the above-mentioned method for displaying dynamic pet backgrounds.

[0068] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. The system embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and there may be other division methods in actual implementation. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the coupling or direct coupling or communication connection shown or discussed may be through some communication interface; the indirect coupling or communication connection between systems or units may be electrical, mechanical, or other forms.

[0069] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0070] In addition, the functional units in the embodiments provided in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0071] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0072] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0073] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application. All should be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.

Claims

1. A method for displaying a dynamic pet background, characterized in that, The method, applied to the vehicle's infotainment system, includes: In response to the image generation operation, a sequence of candidate actions in a preset format for the target pet is generated; the sequence of candidate actions includes multiple frames of images showing the action, and includes a standby action sequence and an event action sequence. In response to the information storage operation, each of the candidate action sequences is stored in an action folder in the MCU, and the association between each candidate action sequence and the triggering event is stored in the MCU; When no vehicle triggering event is detected, the standby action sequence is read from the action folder corresponding to the standby action sequence and played randomly according to the association relationship; When the vehicle's trigger event is detected, the event action sequence corresponding to the trigger event is read from the action folder corresponding to the trigger event and played according to the association relationship.

2. The method according to claim 1, characterized in that, When the preset format is PNG, the method plays the video in the following manner: Decode any first frame image to obtain pixel data. The pixel data decoded from the first frame image is blended with the background image corresponding to the first frame image using a blending formula to form the first buffer frame and store it in the background cache. When the frame rate timer is triggered and the LCD screen is in the refresh idle area, the buffer pointer is switched, and the first buffered frame is used as the display buffer for display. While displaying the first cached frame, the pixel data decoded by the second frame image using the mixing formula is layer-blended with the background image corresponding to the second frame image to form the second cached frame and stored in the background cache. When the next frame rate timer is triggered and the LCD screen refresh is idle, the buffer pointer is switched, and the second buffered frame is used as the display buffer for display.

3. The method according to claim 1, characterized in that, The method further includes: Based on the target pet and the stored candidate action sequence, determine the upgrade status of the target pet and send the upgrade status to the mobile terminal so that the mobile terminal can determine the pet to be upgraded and the action sequence to be upgraded based on the upgrade status. Receive the action data packet header sent by the mobile terminal; wherein the action data packet header includes a first identifier of the pet to be upgraded and a second identifier of the action sequence to be upgraded; The third identifier of the target pet and the fourth identifier of the candidate action sequence are verified based on the first identifier and the second identifier, respectively, to obtain the verification result; Based on the verification results, update the action folder and replace the target pet.

4. The method according to claim 3, characterized in that, The upgrade status of the target pet includes standby status, resume status, and replacement status; determining the upgrade status of the target pet based on the target pet and the stored candidate action sequence includes: When the target pet already possesses all the action sequences to be upgraded on the mobile device, it is in the standby state; When the target pet already exists but lacks the mobile portion of the action sequence to be upgraded, it is in the resume state; When the pet to be upgraded on the mobile device is different from the target pet, and the pet to be upgraded does not exist in the current storage, it is in the replacement state.

5. The method according to claim 4, characterized in that, The step of verifying the third identifier of the target pet and the fourth identifier of the candidate action sequence based on the first and second identifiers respectively, and obtaining the verification result, includes: If the first identifier is the same as the third identifier, and the second identifier is different from the fourth identifier, then the verification result is that the missing action of the target pet needs to be supplemented. If the first identifier is different from the third identifier, the verification result is that the target pet needs to be replaced with the pet to be upgraded. If the first identifier is the same as the third identifier, and the second identifier is the same as any of the stored fourth identifiers, then an error message is returned to the mobile device, and no update is performed.

6. The method according to claim 4, characterized in that, When it is necessary to supplement the missing actions of the target pet, the sequence of actions to be upgraded transmitted from the mobile terminal is received and parsed to obtain pixel data; The pixel data is stored in a backup folder, and a CRC check is performed on the pixel data after the data is received. After the pixel data verification is successful, the backup folder is renamed to the action folder; After all the action sequences to be upgraded and the associated relationships have been transmitted and verified, delete the original action folder of the target pet and the information file storing the associated relationships, and switch to the updated current pet for display.

7. The method according to claim 1, characterized in that, The multi-frame images are in PNG format and are stored using a 4-bit palette index mode.

8. A display device for a dynamic pet background, characterized in that, The device includes: The generation module is used to generate a sequence of candidate actions in a preset format for the target pet in response to the image generation operation; the sequence of candidate actions includes multiple frames of images that complete the action, and the sequence of candidate actions includes a standby action sequence and an event action sequence. A storage module is used to, in response to an information storage operation, store each of the candidate action sequences in an action folder in the MCU, and store the association between each candidate action sequence and the triggering event in the MCU; The first playback module is used to read and randomly play the standby action sequence from the action folder corresponding to the standby action sequence according to the association relationship when no vehicle triggering event is detected. The second playback module is used to read and play the sequence of events corresponding to the trigger event from the action folder corresponding to the trigger event according to the association relationship when the trigger event of the vehicle is detected.

9. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine instructions that the processor executes. When the electronic device is running, the processor communicates with the memory via the bus. When the machine instructions are executed by the processor, they perform the steps of the dynamic pet background display method as described in any one of claims 1 to 7.

10. A computer storage medium, characterized in that, The computer storage medium stores a computer program that, when executed by a processor, performs the steps of the dynamic pet background display method as described in any one of claims 1 to 7.

Images