Display development methods and related devices for embedded systems without GUI libraries

Abstract

This application relates to the field of embedded system technology, and provides a display development method and related devices for embedded systems without GUI libraries. The display area is divided into multiple independent blocks, and attribute information is configured for each block. The attribute information of each block is registered to a preset embedded software display framework. The display queue is read cyclically to obtain blocks to be displayed. Based on the comparison result between the current interface number and the interface affiliation identifier, blocks belonging to the current interface or shared across interfaces are filtered out. According to the type identifier of the filtered blocks, corresponding display processing operations are performed. The reading, filtering, and display processing operations are repeated until there are no blocks to be displayed in the display queue. This technical solution achieves engineering decoupling between UI and business logic, improving the development efficiency, maintainability, and code reusability of embedded GUIs.

Description

Technical Field

[0001] This application relates to the field of embedded system technology, and more specifically, to a display development method and related equipment for embedded systems without GUI libraries. Background Technology

[0002] In the field of embedded system development, the implementation of graphical user interfaces (GUIs) typically relies on general-purpose GUI libraries such as LVGL and emWin. However, these GUI libraries consume significant amounts of RAM and Flash resources, making them difficult to run on memory-constrained low-end microcontrollers. They also suffer from licensing limitations and complex porting issues. When embedded systems cannot or are unsuitable for using GUI libraries, developers often need to manually organize menus and interface logic, leading to low development efficiency.

[0003] Furthermore, existing embedded UI development practices commonly suffer from a high degree of intertwining between business logic and UI display code. Any adjustment to the interface layout can affect the business logic code, and changes to the business logic also require UI developers to participate in modifications. This makes it difficult for UI developers and business logic developers to work in parallel, resulting in poor code reusability and maintainability, and extending the product development cycle. Summary of the Invention

[0004] This application provides a method and related equipment for developing embedded system displays without GUI libraries, which can at least partially solve the problem of low efficiency in embedded system display development.

[0005] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0006] According to one aspect of this application, a display development method for embedded systems without a GUI library is provided, comprising: dividing the display area into multiple independent blocks and configuring attribute information for each block; the attribute information includes block coordinates, block size, type identifier, callback function pointer, and interface affiliation identifier; registering the attribute information of each block to a preset embedded software display framework, and cyclically reading the display queue to obtain blocks to be displayed; filtering out blocks belonging to the current interface or shared across interfaces based on the comparison result between the current interface number and the interface affiliation identifier; performing corresponding display processing operations based on the type identifier of the filtered blocks; the display processing operations include at least one of the following: if the type identifier is a drawing type requiring buffer allocation, then a temporary buffer is allocated, a callback function is called for drawing, and the buffer content is transmitted to the screen; if the type identifier is a screen clearing type, then screen clearing is performed; if the type identifier is an image type, then an image is decoded and displayed; if the type identifier is a pure function type, then only the callback function is called; repeating the reading, filtering, and display processing operations until there are no blocks to be displayed in the display queue.

[0007] In this application, based on the aforementioned scheme, the step of performing the corresponding display processing operation according to the type identifier of the filtered block includes: if the type identifier of the filtered block is a drawing type that requires buffer allocation, then the rendering of the entire block is decomposed into multiple small-area renderings according to the single rendering height, step increment, and number of renderings in the block attributes; each rendering allocates only a buffer corresponding to the single rendering height and block width, and after the rendering is completed, the buffer content is transferred to the corresponding position on the screen; the above process is repeated until the rendering of the entire block is completed.

[0008] In this application, based on the aforementioned scheme, it further includes: a predefined theme color array, wherein each row of the theme color array corresponds to a theme number and each column corresponds to a color type; a global current theme variable is set; when a screen clearing operation or a drawing operation that requires clearing the buffer is performed, the corresponding color value is obtained from the theme color array according to the value of the global current theme variable and filled; when the theme is switched, only the value of the global current theme variable is modified.

[0009] In this application, based on the aforementioned scheme, the interface attribution identifier includes a first identifier value and a second identifier value. The first identifier value is used to identify that the block belongs only to a specific interface with the same value, and the second identifier value is used to identify that the block is a cross-interface shared block. The step of filtering out blocks belonging to the current interface or cross-interface shared blocks based on the comparison result between the current interface number and the interface attribution identifier includes: when the interface attribution identifier of the block to be displayed is equal to the current interface number or equal to the second identifier value, it is determined that the block passes the filtering and is displayed; otherwise, the block is skipped.

[0010] In this application, based on the aforementioned scheme, the type identifier includes a pure function type value; when the type identifier of the block is equal to the pure function type value, no buffer is allocated, no display operation is performed, and only the business logic function pointed to by the callback function pointer associated with the block is called.

[0011] In this application, based on the aforementioned scheme, it further includes: in a bare-metal environment, defining a global variable as a direct memory access completion flag, which is set by an interrupt service routine, and the display framework achieves synchronization by polling and waiting for the flag; in a real-time operating system environment, defining a binary semaphore as a direct memory access synchronization object, which is released by an interrupt service routine, and the display framework achieves synchronization by waiting for the semaphore; the display framework selects the corresponding synchronization method according to the current development environment configuration.

[0012] In this application, based on the aforementioned scheme, the display queue is implemented using an array circular queue or a real-time operating system message queue; the attribute information of each block is registered to the display framework through a static structure array or a dynamic linked list.

[0013] According to one aspect of this application, a display development device for embedded systems without a GUI library is provided, comprising: The configuration module is used to divide the display area into multiple independent blocks and configure attribute information for each block; the attribute information includes block coordinates, block size, type identifier, callback function pointer, and interface ownership identifier; The reading module is used to register the attribute information of each block to the display framework of the preset embedded software, and to read the display queue in a loop to obtain the blocks to be displayed. The filtering module is used to filter out blocks belonging to the current interface or shared across interfaces based on the comparison result between the current interface number and the interface belonging identifier. The processing module is used to perform corresponding display processing operations based on the type identifier of the filtered blocks; the display processing operation includes at least one of the following: if the type identifier is a drawing type that requires buffer allocation, then a temporary buffer is allocated, a callback function is called to draw, and the buffer content is transmitted to the screen; if the type identifier is a screen clearing type, then screen clearing is performed; if the type identifier is an image type, then the image is decoded and displayed; if the type identifier is a pure function type, then only the callback function is called; The iteration module is used to repeat the reading, filtering, and display processing operations until there are no more blocks to be displayed in the display queue.

[0014] According to one aspect of this application, a computer-readable medium is provided having a computer program stored thereon, which, when executed by a processor, implements the display development method for embedded systems without GUI libraries as described in the above embodiments.

[0015] According to one aspect of this application, an electronic device is provided, comprising: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement the display development method for embedded systems without GUI libraries as described in the above embodiments.

[0016] According to one aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the display development method for embedded systems without a GUI library provided in the various alternative implementations described above.

[0017] The main differences and technical effects of the technical solution of this application compared with the prior art are as follows: Traditional solutions suffer from memory constraints and complex porting due to reliance on GUI libraries, resulting in extremely low development efficiency and maintenance difficulties. This new solution directly manipulates the frame buffer for pixel-level drawing, eliminating the need for any third-party GUI libraries. By dividing the screen into independent blocks and configuring coordinates, size, type identifiers, callback function pointers, and interface ownership identifiers, the display framework cyclically reads the asynchronous queue and processes data by type (drawing types allocate temporary buffers, draw via callback, and release after transmission; screen clearing types directly fill; image types decode and write directly; pure function types only execute callbacks). This allows for precise control over the peak memory usage of the entire display system and significantly reduces code size. Compared to solutions relying on general-purpose GUI libraries like LVGL, this technology can run on low-end microcontrollers with only a few KB of RAM, while avoiding GUI library licensing restrictions and porting workloads, making it irreplaceable in resource-constrained scenarios.

[0018] On the other hand, existing embedded UI development practices commonly suffer from a high degree of intertwining between business logic and UI display code, leading to difficulties in parallel UI development and poor code reusability. This technical solution achieves asynchronous communication between the business logic layer and the display framework through a display queue: the business logic only needs to push the block identifiers that need updating into the queue and can continue execution without waiting for rendering to complete; the display framework independently reads the queue in a loop and automatically filters out blocks belonging to the current interface or shared across interfaces based on the comparison result between the current interface number and the block ownership identifier, and then performs the corresponding display processing according to the type identifier. This design allows UI developers to focus only on the coordinate positions of each block and the rendering code within the callback functions, while business logic developers only need to focus on data acquisition and processing; the two types of personnel can work completely in parallel. Compared to the traditional menu organization method that binds functional attributes, data sources, and interaction logic to the node structure, this technical solution achieves true engineering decoupling between UI and business logic, significantly improving the development efficiency, maintainability, and code reusability of embedded GUIs.

[0019] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0020] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0021] Figure 1 The flowchart illustrating a display development method for an embedded system without a GUI library is shown in one embodiment of this application.

[0022] Figure 2 The flowchart illustrating the execution of a display processing operation based on a type identifier is shown in one embodiment of this application.

[0023] Figure 3 The illustration shows a schematic diagram of a display development apparatus for an embedded system without a GUI library, according to one embodiment of this application.

[0024] Figure 4 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0025] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0026] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0027] It should be noted that the data acquisition or information collection in this embodiment is performed after authorization by the user or the object of collection, and its process and purpose strictly follow the relevant regulations.

[0028] The block diagrams shown in the attached figures are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, or in one or more hardware modules composed of smart chips, smart integrated circuits, or application-specific integrated circuits (ASICs), or in different network and / or processor devices and / or microcontroller devices.

[0029] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0030] The implementation details of the technical solution of this application are described below: Figure 1 A flowchart illustrating a display development method for an embedded system without a GUI library according to an embodiment of this application is shown. (Refer to...) Figure 1 As shown, this display development method for embedded systems without GUI libraries includes at least steps S110 to S150, which are described in detail below: S110, the display area is divided into multiple independent blocks, and attribute information is configured for each block; the attribute information includes block coordinates, block size, type identifier, callback function pointer and interface ownership identifier.

[0031] In the system initialization phase of this embodiment, the resolution parameters of the current physical screen are first obtained, including the total number of pixels in the horizontal direction and the total number of pixels in the vertical direction. Based on these parameters, according to the interface layout scheme predefined in the product design, the entire display area is logically divided into several independent display blocks that do not overlap or allow partial overlap. Each block corresponds to a specific display function area, such as a parameter value display area, a status icon area, a button response area, etc.

[0032] The partitioning is accomplished through declarative configuration data. The display framework does not actively determine the partitioning method, but rather provides an array of partition description structures. Each element in this array fully defines all the attributes of an independent display partition. Internally, these attributes are organized into a contiguous memory data structure for the display scheduler to read at runtime.

[0033] It should be noted that the display framework is a lightweight embedded software middleware layer defined in this application's technical solution. It is completely independent of any third-party graphical user interface library and achieves pixel-level rendering by directly manipulating the frame buffer. The display framework consists of a pre-configured array of block attributes and runtime scheduling logic. It is responsible for managing the registration and traversal of display blocks, maintaining the asynchronous display queue between the business logic layer and the display layer, filtering the blocks to be displayed according to the current interface number, and automatically performing differentiated display processing operations such as buffer allocation, callback function calls, pixel transfer, or screen clearing based on the type identifier of each block. This achieves engineering decoupling between the UI and business logic and efficient interface rendering in resource-constrained environments.

[0034] For each block, the required configuration attributes should include at least the following: block coordinates, block size, type identifier, callback function pointer, and interface ownership identifier.

[0035] The block coordinates include its positioning information on the screen, namely the x and y coordinates of the top-left pixel of the block, as well as the block's width in the horizontal direction and its height in the vertical direction. These coordinates and size values ​​are all in pixels and determine the actual area occupied by the block on the screen. During subsequent rendering, these values ​​can be used to calculate the range of pixels that need to be manipulated.

[0036] The type identifier of a block is a pre-defined integer value that tells the current block which rendering behavior should be used. Different type values ​​correspond to completely different processing logic, such as whether a temporary buffer needs to be allocated, whether the background needs to be cleared before drawing, whether to display the image directly, or whether to only execute the callback function without performing any pixel operations. The type branch processing module jumps to the corresponding execution path based on this identifier.

[0037] In this embodiment, the type identifier includes a pure function type value. When the type identifier of a block is equal to this pure function type value, no buffer is allocated, no display operation is performed, and only the business logic function pointed to by the callback function pointer associated with the block is called.

[0038] Specifically, when the type identifier read from the block attribute by the display framework equals the preset pure function type value, the display framework recognizes that the block does not participate in any screen display-related operations. At this time, the display framework will not call the memory management interface to allocate any temporary buffer, nor will it execute display functions such as screen clearing, pixel transfer, or image decoding. The only action is to directly retrieve the callback function pointer from the block attribute structure and call the business logic function it points to. This callback function is used to execute background tasks decoupled from the interface display, such as data synchronization, state updates, timer resets, or sensor triggers. After the callback function completes execution, control immediately returns to the display framework, and the processing of the block ends, without any screen pixel changes or frame buffer resources being consumed. This allows scheduling capabilities to be extended to non-display domains. For example, background tasks (data synchronization, timed checks, state rotation, etc.) can be registered in the system as blocks and uniformly scheduled and executed by the display queue, further deepening the decoupling between display code and business logic, while eliminating the need for an additional task manager.

[0039] The callback function pointer associated with a block points to a function of business logic. This function contains specific drawing instructions or business processing instructions for the current block. When the display framework processes this block, it determines whether and when to call the callback function based on the block type. The callback function allows for complete customization of the final display content of the block, while the framework is only responsible for providing the buffer, the timing of the call, and the transmission mechanism.

[0040] The interface ownership identifier for a block is used to manage multiple interfaces. Each block can be assigned a specific interface number, indicating that the block will only be displayed when the interface corresponding to that number is active. In addition, a special shared identifier value is reserved. When the interface ownership identifier of a block equals this shared value, the block does not belong to any specific interface but is displayed on all interfaces, applicable to global components such as status bars and title bars. When the display scheduler performs interface filtering, it reads the currently active interface number and compares it with the interface ownership identifier of each block to determine whether to skip that block.

[0041] In addition to the core attributes mentioned above, the block configuration can also include control parameters related to multi-rendering in the specific implementation, such as the height of a single render, the step increment, and the total number of renders required, as well as theme color reference parameters for theme switching. These parameters are all stored in the same block structure and configured together with other block attributes.

[0042] After configuration, the display framework registers these block attribute information into its internal management data structure. The registration process essentially involves recording the starting address and length of static configuration data (usually stored in read-only memory) into the framework's global variables, allowing the main loop to iterate through all blocks. Once registered, each block possesses complete "identity information," enabling the system to independently render, update, and transmit each block in subsequent scheduling loops based on this information.

[0043] This partitioning and configuration method breaks down the entire screen's display content into multiple loosely coupled independent units. The display logic of each unit is encapsulated in its callback function, and the system is only responsible for sequentially calling these callback functions according to the configured coordinates, type, and attribution rules, and sending the generated pixel data to the corresponding position on the physical screen. This step lays the data structure foundation for subsequent parallel development, independent debugging, and efficient rendering.

[0044] The above process, by breaking down the entire screen into logically independent blocks, each with complete self-descriptive attributes, eliminates the need for the display framework to understand the overall structure of the interface. Block coordinates and dimensions define the physical boundaries of rendering, callback function pointers decouple the specific drawing logic from the framework, and interface ownership identifiers provide a basis for managing multiple interfaces. This division directly leads to parallelism in interface development: different blocks can be developed independently, there are no code dependencies between blocks, and modifying the display content of one block will not affect other blocks, significantly reducing the collaborative complexity of large embedded interface projects.

[0045] S120 registers the attribute information of each block to the display framework of the preset embedded software and reads the display queue in a loop to obtain the blocks to be displayed.

[0046] In this embodiment, the system locates predefined block configuration data stored in read-only memory. This configuration data is essentially a continuous array, and each element in the array is a structure that fully describes all the attributes of an independent display block, including the block's starting coordinates on the screen, width, height, type identifier, callback function pointer, interface ownership identifier, and multi-stage rendering control parameters, etc.

[0047] The display framework obtains the starting memory address of the array and its length (i.e., the total number of blocks), storing this information in its internal management variables. The registration process does not copy the specific content of the block attributes; instead, it establishes a reference to the original configuration data to avoid unnecessary memory overhead. Once registration is complete, the display framework possesses complete descriptive information for all display blocks in the entire system, enabling it to traverse these blocks in subsequent scheduling loops and determine which blocks need to be processed based on runtime conditions.

[0048] After registration is complete, the display framework enters the main scheduling loop, which is a continuously running infinite loop. One of its core tasks is to read the block identifiers to be displayed from the display queue.

[0049] The display queue serves as the data channel between the display framework and the business logic layer. During operation, when the data corresponding to a certain block changes (e.g., sensor values ​​are updated, user key presses trigger interface transitions, timers expire and require clock display refresh), the business logic code does not directly call the display rendering function. Instead, it uses a standardized interface provided by the display framework to write the identifier of the block that needs updating into the display queue. This queue is typically implemented as a circular buffer or a real-time operating system message queue to ensure thread safety in a multi-tasking environment.

[0050] In one embodiment of this application, the display queue is implemented using an array circular queue or a real-time operating system message queue; the attribute information of each block is registered in the display framework through a static structure array or a dynamic linked list.

[0051] Specifically, in the display implementation process, the display queue, as the data channel between the business logic layer and the display scheduling layer, can adopt two different data structures: In a bare-metal or simple task environment, the display queue is usually implemented as an array circular queue, that is, using a contiguous memory space and two integer indices pointing to the head and tail of the queue respectively, and using modulo operations to achieve circular read and write, ensuring the determinism and low overhead of queue operations; In a real-time operating system environment, the message queue object provided by the operating system can be used directly, and the kernel is responsible for managing the storage, synchronization and task wake-up of the queue, without the need to maintain the boundary logic of the circular buffer. Meanwhile, two registration methods are offered for the attribute information of each display block: For scenarios where the interface layout remains fixed after system startup, a static structure array method is used for registration. This involves storing the attribute structures of all blocks as a contiguous array in read-only memory. The display framework directly traverses and accesses the array using its starting address and length, eliminating the need for dynamic memory allocation. For complex scenarios requiring dynamic addition and deletion of blocks at runtime, a dynamic linked list method is used. Each block's attribute structure contains a pointer to the next block. The display framework processes all registered blocks sequentially by traversing the head node of the linked list, thus gaining the ability to flexibly adjust the interface composition at runtime. These two queue implementation methods and two registration methods can be freely combined according to actual project needs, enabling the display framework to run efficiently on both resource-constrained simple devices and complex systems requiring dynamic interfaces.

[0052] The framework offers two implementations: an array-based circular queue and a real-time operating system message queue. The former is suitable for bare-metal and resource-constrained scenarios (requiring only contiguous memory and indexes, high determinism, and no dynamic allocation), while the latter is suitable for multi-tasking systems (supporting blocking, timeouts, and priority inheritance). Block registration offers two methods: a static structure array and a dynamic linked list. The former stores attributes in contiguous read-only memory, offering fast access and zero runtime overhead, while the latter supports dynamic addition and deletion of blocks at runtime, enabling configurable UI functionality and over-the-air upgrades. The flexible combination of these two queue types and registration methods extends the framework's applicability from microcontrollers with only a few KB of memory to complex application processors.

[0053] In each iteration of the main loop, the first step is to check if the display queue is empty. If the queue is empty, the loop waits or executes other low-priority tasks (depending on system configuration); if the queue is not empty, a block identifier is retrieved from the head of the queue. This identifier is an integer value that uniquely corresponds to a specific display block defined during the registration phase.

[0054] After reading the block identifier, the display framework uses that identifier to index the block attribute array and quickly locates the complete attribute structure of the corresponding block. At this point, the display framework has obtained all the information of the "block to be displayed", including the block's coordinate range, size, type, callback function, etc.

[0055] It's worth noting that the display queue may contain multiple block identifiers awaiting display simultaneously. The main loop processes each identifier sequentially in a first-in, first-out (FIFO) manner until the queue is empty. This design allows the business logic layer to trigger UI updates asynchronously without waiting for rendering to complete; the display framework independently handles the rendering and transmission of each block according to the queue order, thus achieving complete decoupling between display scheduling and business logic.

[0056] Furthermore, in a bare-metal environment, the display queue read operations are performed sequentially within the main loop, without task switching. In a real-time operating system environment, the display framework typically runs as an independent task, suspending itself when the queue is empty and being awakened by the business logic task when new data is available. Regardless of the environment, the core logic of the display framework reading the display queue and retrieving the blocks to be displayed remains consistent, ensuring the framework's portability.

[0057] Through the aforementioned registration and queue reading mechanism, the display framework can dynamically respond to UI update requests from the business logic layer, scheduling each independent block as needed, preparing for subsequent UI filtering and type branching. Incorporating statically configured block attributes into the framework's management scope allows it to access all block information in a unified manner. The display queue, acting as an asynchronous channel between the business logic layer and the display scheduling layer, decouples requests from processing: business logic only needs to push the block identifiers that need updating into the queue and can continue execution without waiting for rendering to complete. The display framework independently and cyclically reads the queue, processing requests in order, ensuring the orderliness and non-blocking nature of UI update requests and preventing a decrease in real-time performance caused by business logic waiting for display operations.

[0058] S130, based on the comparison result between the current interface number and the interface ownership identifier, filter out the blocks belonging to the current interface or shared across interfaces.

[0059] In one embodiment of this application, in the main scheduling loop, after successfully reading the identifier of a block to be displayed from the display queue and locating the complete attribute structure of the block, the display framework performs an interface filtering step to determine whether the currently read block should be displayed, thereby avoiding rendering content that does not belong to the interface in an inactive interface, while ensuring that blocks shared across interfaces can be displayed normally in any interface.

[0060] The display framework maintains a global variable that records the current active interface number. This number is updated by the business logic layer through a standardized interface when an interface switch occurs. For example, when a user presses a physical button or a navigation button on a touchscreen, the business logic code modifies the current interface number to the target interface number and triggers a refresh of the corresponding interface.

[0061] The display framework first reads the interface affiliation identifier of the currently pending block from its attribute structure. This identifier is an integer value pre-assigned to the block, used to declare which logical interface the block belongs to. Simultaneously, the display framework also reads the currently active interface number stored in the system's global variables.

[0062] Then, the display frame compares the block's interface ownership identifier with the currently active interface number. The comparison result can result in three outcomes: 1. The interface ownership identifier of the block is exactly the same as the number of the currently active interface. This means that the block is part of the currently active interface and should be displayed. The display framework will determine that the block passes the filter and continue to execute subsequent type branch processing and rendering operations.

[0063] 2. The interface ownership identifier of a block is not equal to the current active interface number, but rather to a pre-agreed, special shared identifier value. This shared identifier value is reserved by the system to mark common blocks that do not belong to any specific interface but need to be displayed on all interfaces, such as the status bar, title bar, bottom navigation bar, and global tooltip icon. When the interface ownership identifier of a block equals this shared identifier value, regardless of the current active interface number, the display framework will determine that the block has passed the filter and allow it to be displayed. This design eliminates the need to redefine common interface elements in the configuration of each interface; they only need to be configured once to take effect in all interfaces.

[0064] 3. If the interface ownership identifier of a block is neither equal to the current active interface number nor equal to the shared identifier value, the display framework determines that the block does not belong to the current active interface and is not a cross-interface shared block. Therefore, the block should not be displayed. The display framework will skip the block, not perform any rendering or transfer operations, and immediately release any temporary resources associated with the block (if they have been allocated), then return to the main scheduling loop to continue processing the next block identifier in the display queue.

[0065] It's important to note that the interface filtering step is performed before any resource-intensive operations such as allocating buffers and calling callback functions. This design ensures that filtered-out blocks do not consume any memory resources or waste CPU time on meaningless rendering, thereby improving the overall system efficiency.

[0066] Furthermore, when the business logic layer modifies the current interface number, the display framework does not automatically refresh all blocks. Instead, the business logic code proactively writes the identifiers of each block to be displayed under the new interface into the display queue, or triggers a full-screen refresh command, as needed. During subsequent queue processing, the display framework automatically selects the blocks belonging to the new interface for display through the aforementioned filtering mechanism, while ignoring blocks from the old interface. This ensures that the interface switching logic is entirely controlled by the business layer, with the display framework only responsible for executing according to the filtering rules, maintaining clear boundaries between modules.

[0067] Through the comparison and filtering mechanisms described above, the display framework can accurately present the appropriate content for each active interface, while automatically reusing common blocks across interfaces without any additional configuration or code duplication. This step is crucial for achieving multi-interface management, reducing memory consumption, and simplifying interface development logic. The filtering mechanism allows the display framework to automatically identify which blocks should be displayed on the current active interface without requiring explicit enabling or disabling of each block in the business logic. Common blocks across interfaces (such as the status bar) are always filtered through a special identifier, achieving a single configuration and global reuse effect. The filtering operation is performed before resource allocation; skipped blocks do not consume any memory or computing resources, thus effectively reducing unnecessary rendering overhead and simplifying the software logic for interface switching in multi-interface systems.

[0068] In one embodiment of this application, step S130, based on the comparison result between the current interface number and the interface ownership identifier, filters out blocks belonging to the current interface or shared across interfaces, including: The interface attribution identifier includes a first identifier value and a second identifier value. The first identifier value is used to identify that the block belongs only to a specific interface with the same value, and the second identifier value is used to identify that the block is a cross-interface shared block. When the interface ownership identifier of the block to be displayed is equal to the current interface number or equal to the second identifier value, the block is determined to pass the filter and is displayed; otherwise, the block is skipped.

[0069] In the interface filtering step, each block's attribute structure contains an integer field called the interface ownership identifier. This field can take two different types of values: The first type is a regular interface number value, called the first identifier value, used to declare that the block belongs only to a specific logical interface with the same number. For example, the block with interface number 5 will only be displayed when the currently active interface number is also 5. The second type is a pre-agreed special value, called the second identifier value. This value will not be used as a regular interface number in any interface list; it is specifically used to mark cross-interface shared blocks that do not belong to any specific interface and need to be displayed across all interfaces, such as the global status bar or title bar. When performing filtering, the display framework reads both the currently active interface number and the interface ownership identifier of the block to be processed, and then performs two equality checks.

[0070] During execution, the display framework first determines whether the interface ownership identifier of the block to be displayed is equal to the number of the currently active interface. If they are equal, the block belongs to the currently active interface, passes the filter, and is displayed. If they are not equal, it further determines whether the interface ownership identifier of the block is equal to a preset second identifier value (i.e., a special value for cross-interface shared blocks). If they are equal, the block is a cross-interface shared block, and regardless of the current active interface number, it passes the filter and is displayed. If both determinations are false, meaning the block's interface ownership identifier is neither the current interface number nor a shared block special value, the display framework determines that the block does not belong to the current interface and is not globally shared. It skips the block, does not allocate any resources to it, and does not perform any rendering or transmission operations, immediately proceeding to the processing flow of the next block. This dual-determination mechanism ensures the independence of the displayed content between interfaces while enabling cross-interface reuse of common components, eliminating the need for repeated definition in each interface configuration.

[0071] In the above process, the interface ownership identifier adopts a dual-value design of ordinary interface number (first identifier value) and preset special shared value (second identifier value). Ordinary blocks are only displayed when the ownership identifier is equal to the current active interface number, which naturally supports the isolation of multiple interfaces and allows blocks from different interfaces to share the same screen area without conflict. The second identifier value enables common components such as the status bar to automatically pass through the filtering of all interfaces, realizing single configuration and global reuse. The filtering logic only requires two integer comparisons and is executed before rendering. Skipped blocks do not occupy any resources, and interface switching only requires modifying the current interface number variable. The logic is extremely simple and efficient.

[0072] S140, based on the type identifier of the filtered block, perform the corresponding display processing operation; the display processing operation includes at least one of the following: if the type identifier is a drawing type that requires buffer allocation, allocate a temporary buffer, call a callback function to draw, and transfer the buffer content to the screen; if the type identifier is a screen clearing type, perform screen clearing; if the type identifier is an image type, decode and display the image; if the type identifier is a pure function type, only call the callback function.

[0073] In this embodiment, after a display block passes the interface filtering step, the display framework further reads the type identifier field in the block's attribute structure. This identifier is a pre-defined integer used to indicate what display processing behavior the current block should adopt. Based on the value of this identifier, the display framework jumps to the corresponding processing branch and performs differentiated operations. The execution process is described below according to the four main branch types.

[0074] For drawing blocks that require buffer allocation, and for blocks whose type identifier indicates "Normal Drawing," "Draw After Clearing," or "Draw After Theme Color Clearing," the display framework first calls the memory management interface to request a temporary buffer. The size of this buffer is determined by the block's width and single-render height, and is used to temporarily store the pixel data to be displayed in memory. If memory allocation fails (e.g., insufficient available memory), the display framework records the error status and skips the block.

[0075] After successful allocation, the display frame determines whether to clear the buffer based on the type identifier. If the type requires clearing before drawing, the display frame fills the entire buffer with the specified color (a fixed color or the color corresponding to the current theme); if clearing is not required, the original random data in the buffer is retained.

[0076] Subsequently, the display framework invokes the callback function associated with the block through the callback function pointer in the block's properties. The callback function contains specific drawing instructions for the current block. When the callback function is invoked, the display framework passes the allocated buffer's starting address, along with parameters such as the block's width and height, to the callback function. During the callback function's execution, pixel drawing functions are used to write various graphic elements (such as text, numbers, progress bars, waveforms, etc.) into the buffer. At this point, the data in the buffer becomes the pixel array that will ultimately be displayed on the screen.

[0077] After the callback function completes execution, the display framework calls the screen transfer interface to send the pixel data in the buffer to the starting coordinates of the corresponding block on the physical screen. The transfer process is typically handled in the background by the direct memory access controller to free up the central processing unit to perform other tasks. The display framework employs different synchronization mechanisms to wait for the transfer to complete, depending on the current operating environment (bare metal or real-time operating system).

[0078] In a bare-metal environment, the display frame polls a global flag maintained by the direct memory access interrupt service routine (DMR) until the flag is set, indicating that the transfer is complete. In a real-time operating system environment, the display frame waits for a binary semaphore, which is released by the DMR. Regardless of the method used, the display frame blocks at this point to ensure that subsequent operations are performed only after the transfer is complete, thus preventing the buffer from being prematurely released or overwritten.

[0079] After the transfer is complete, the display framework calls the memory management interface to release the previously allocated temporary buffer, returning the memory to the system for use by other blocks. At this point, a drawing block that required buffer allocation has been processed.

[0080] For blocks whose type identifier is "Clear Screen" or "Theme Color Clear Screen," the display frame does not allocate any buffer. The operation target for such blocks is the entire screen or a specified area of ​​the screen. The display frame first determines the color value to use for clearing the screen based on the type identifier: if the type is fixed color clear screen, a predefined fixed color value is used; if the type is theme color clear screen, the background color value corresponding to the current theme number is read from the current theme color array.

[0081] Once the color is determined, the display framework calls the underlying screen clearing interface. This interface receives the coordinates and size parameters of the target area, as well as the color value, and either directly manipulates the frame buffer or fills the entire area with the specified color via the direct memory access controller. Similar to drawing blocks, the screen clearing operation also uses direct memory access to accelerate transmission and employs the same synchronization mechanism to wait for transmission to complete.

[0082] After the screen clearing operation is completed, the display frame does not involve the allocation and release of buffers, and the processing of this block ends directly.

[0083] For image blocks whose type identifier is "direct image pasting", the display frame also does not allocate a temporary buffer. These blocks are used to directly decode images pre-stored in read-only memory or external storage media and display them at a specified location on the screen.

[0084] The display framework first reads image-related parameter information from the block attributes. This parameter can be a fixed image resource identifier or a special indicator value. If the parameter is a fixed image identifier, the display framework directly locates the corresponding image data based on the identifier; if the parameter is a special indicator value, the display framework calls the block's callback function to dynamically obtain the image identifier. This method allows the business logic to decide which image to display at runtime.

[0085] After obtaining the image identifier, the display framework calls the image decoding and display interface. This interface is responsible for reading the image's raw encoded data (such as bitmap, run-length encoded, or compressed format), decoding it into pixel format, and writing it pixel by pixel into the specified coordinate area of ​​the screen frame buffer via direct memory access or the central processing unit. The entire process does not require a temporary buffer; the image data flows directly to the screen, thus saving additional memory overhead.

[0086] Once the image is displayed, the display frame ends the processing of that block.

[0087] For pure function blocks whose type identifier is "Do not draw the function," the display framework does not perform any display-related operations, including not allocating buffers, not clearing the screen, and not transmitting pixel data. These blocks do not occupy any screen area, and their coordinate and size attributes are completely ignored in this branch. The only action is to directly call the callback function associated with the block through the callback function pointer in the block's attributes. This callback function is used to execute tasks unrelated to the interface display but requiring synchronization with the display schedule, such as background data synchronization, timer resets, state machine rotations, and sensor-triggered data acquisition.

[0088] Once the callback function completes execution, the display framework immediately terminates processing for that block without performing any subsequent display-related operations. This design allows the display framework to manage not only visible elements on the screen but also to handle invisible business logic callbacks, further enhancing the framework's versatility and decoupling capabilities.

[0089] After branch processing, regardless of which branch is entered, once the display processing operation of that block is completed, the display frame updates its internal processing count, moves the pointer to the next block to be processed, and then returns to the main scheduling loop to continue reading the next block identifier in the display queue, repeating the above interface filtering and type branch processing process until the display queue is completely cleared.

[0090] The above process, through a type-identified branching design, binds rendering behavior to chunk attributes, enabling the framework to handle various differentiated display needs in a unified manner. For drawing operations requiring buffer allocation, the allocation and release of temporary buffers only occur during chunk processing, keeping peak memory usage controllable. Callback function calls allow for complete customization of the specific drawing content; the framework is only responsible for buffer management and transmission. Screen-clearing operations require no buffer, directly filling the screen for maximum efficiency. Image operations are directly decoded to the screen, skipping the buffer and saving memory copying. Pure function operations do not produce any screen changes but can be included in the same scheduling loop, allowing the display framework to handle background tasks and expanding its application boundaries. This differentiated processing of different types ensures that each operation utilizes the optimal hardware resource utilization.

[0091] like Figure 2 As shown, in one embodiment of this application, in step S140, a corresponding display processing operation is performed based on the type identifier of the filtered block, including: S210, if the type of the filtered block is identified as a drawing type that requires buffer allocation, then the rendering of the entire block is decomposed into multiple small-area renderings based on the single rendering height, step increment and number of renderings in the block attributes. S220, each rendering allocates only a buffer corresponding to the single rendering height and block width, and after rendering is completed, the buffer content is transferred to the corresponding position on the screen; S230, repeat the above process until the rendering of the entire block is complete.

[0092] When the type identifier of the block to be displayed is determined to be a drawing type requiring buffer allocation, such as normal drawing, drawing after clearing, or drawing after clearing the theme color, and the total vertical height of the block is large, the display frame will not allocate a complete frame buffer for the entire block at once. Instead, it will initiate a phased rendering process. The display frame first reads the pre-configured single-render height, step increment, and total number of phased renderings required from the block's attributes. Based on these parameters, the display frame logically divides the entire block from top to bottom into multiple continuous strip-shaped sub-regions. The height of each sub-region is equal to the single-render height, and the starting vertical coordinates between adjacent sub-regions increase by the step increment. Subsequently, the display frame enters an inner loop, the number of which is equal to the preset total number of phased renderings.

[0093] In each loop iteration, the display framework requests a temporary buffer from the memory management interface based on the fixed width of the strip and the single rendering height. This buffer is exactly the size of all the pixel data for a strip sub-region. After successful allocation, the display framework decides whether to clear the buffer with a fixed color or the current theme color based on the specific sub-type of the strip. Then, it calls the strip's callback function, passing the starting coordinates of the current sub-region and the buffer address to the callback function, which then draws the necessary graphic content for that sub-region within the buffer. After drawing, the display framework calls the screen transfer interface to send the pixel data in the buffer to the starting coordinates of the corresponding sub-region on the screen, and waits for direct memory access or CPU transfer to complete synchronization. After the transfer is complete, the display framework immediately releases the temporary buffer, freeing up memory for the next loop. The inner loop processes each strip sub-region sequentially, with each sub-region independently allocated, drawn, transferred, and released, until all sub-regions are processed, thus completing the full rendering of the entire strip without increasing peak memory usage per iteration.

[0094] The above process, for drawing blocks that require buffers, decomposes large-area rendering into multiple small-area renderings by using single-render height, step increment, and number of renders. Each time, only a temporary buffer equivalent to the area of ​​the sub-region is allocated, and the buffer is transferred and released immediately after completion. This reduces the peak memory usage per transaction from the total area of ​​the block to the area of ​​the sub-region. As a result, large-area complex interface rendering can be completed on a microcontroller with only a few KB of memory. At the same time, the pipeline mode of allocation-drawing-transfer-release realizes time-division multiplexing of memory resources.

[0095] S150, repeat the reading, filtering and display processing operations until there are no blocks to be displayed in the display queue.

[0096] In the preceding steps, the display framework has completed the interface filtering and type branching processing for a block to be displayed. At this point, the display framework enters the loop scheduling phase, whose core task is to continuously consume the remaining block identifiers in the display queue until the queue is empty. This process is implemented through the iterative control structure of the main scheduling loop.

[0097] The display framework maintains an internal processing state machine. After processing the current block, this machine does not immediately exit or wait for external events, but instead actively jumps back to the beginning of the scheduling loop. In each iteration of the loop, the display framework first checks the current state of the display queue. The queue is a first-in, first-out (FIFO) data structure, internally maintaining head and tail pointers, as well as the number of valid elements in the current queue.

[0098] If the display queue is not empty, meaning there are still unprocessed block identifiers, the display frame retrieves a block identifier from the head of the queue. This retrieval operation involves moving the head pointer forward and decrementing the queue's valid count. Then, the display frame uses this block identifier to perform an index lookup in the block attribute array to locate the corresponding block's complete attribute structure. The index lookup process is deterministic: since the block attribute array is fixed during the registration phase, there is a one-to-one correspondence between each block identifier and its array index. Therefore, the display frame can directly calculate the memory address from the identifier value without needing to perform a traversal search.

[0099] After locating the block attribute, the display framework re-executes the interface filtering step, which compares the current active interface number with the interface ownership identifier of the block to determine whether the block belongs to the current active interface or is a cross-interface shared block. If the filtering fails, the display framework skips the block directly, does not perform any rendering operations, and immediately enters the next loop iteration to continue processing the next identifier in the queue.

[0100] If the filtering passes, the display framework enters the type branch processing step. This step performs the corresponding display processing operation based on the block's type identifier: for drawing blocks that require buffer allocation, a temporary buffer is allocated, a callback function is called to draw, the buffer content is transferred to the screen, and the buffer is released after the transfer is complete; for screen clearing blocks, screen clearing is performed directly; for image blocks, the image is decoded and displayed; for pure function blocks, only the callback function is called without performing any display operations.

[0101] Once all display processing operations for that block are completed, the display framework returns to the beginning of the scheduling loop, checks if the display queue is still not empty, and repeats the complete process of reading, filtering, and display processing.

[0102] This loop continues until the number of valid elements in the display queue becomes zero. At this point, the display queue is empty. After detecting that the queue is empty, the system behavior depends on the system's operating environment: In a bare-metal environment, the display framework typically runs in an infinite loop. When the queue is empty, the display framework does not block or wait, but immediately begins the next loop iteration, checking the queue status again. Because the queue is empty, the display framework may detect an empty queue multiple times consecutively, thus consuming CPU resources to perform idle polling. To reduce power consumption or free up processor resources for other background tasks, a short delay or a jump to a low-power mode can be inserted when the queue is empty, allowing the business logic layer to write a new block identifier to the queue before resuming full-speed polling.

[0103] In a real-time operating system environment, the display framework typically runs as a standalone task. When the queue is empty, the display framework can call the operating system's task suspension function to proactively switch itself to a blocked state and yield processor resources to other ready tasks. When the business logic layer writes a new block identifier to the display queue, the queue changes from empty to non-empty, and the operating system wakes up the display framework task through internal mechanisms (such as semaphores or event flags), allowing it to continue reading and processing blocks from the queue. This approach avoids empty polling and improves the overall system efficiency.

[0104] Regardless of the environment, the display framework strictly guarantees that each block identifier in the display queue is processed only once. The processing order follows the first-in, first-out (FIFO) principle, meaning that the order in which the business logic layer writes to the queue is exactly the same as the order in which the display framework processes the blocks. This sequentiality ensures the correct timing of interface updates and avoids out-of-order issues where later-requested blocks are displayed before earlier-requested blocks are overwritten.

[0105] Once the display queue is cleared, the batch of UI update operations triggered by the business logic layer is considered complete. The display framework re-enters standby mode, waiting for the business logic layer to write a new block identifier to the queue again, thus restarting the aforementioned cyclic scheduling process. Through this continuous cyclical, on-demand processing design, the display framework achieves efficient scheduling of multiple independent blocks, ensuring real-time UI response and rational utilization of system resources.

[0106] The above process ensures that all requests in the display queue are responded to one by one through a cyclic scheduling mechanism, without any omissions. Because the processing order matches the request order, the interface updates have a predictable timing, avoiding visual confusion caused by out-of-order display. When the queue is empty, the framework can enter an idle or low-power waiting state without consuming additional processing power. This repetitive process unifies batch processing and asynchronous response of display tasks, enabling the display framework to efficiently handle sudden multi-block update scenarios.

[0107] In one embodiment of this application, it further includes: A predefined theme color array, wherein each row of the theme color array corresponds to a theme number and each column corresponds to a color type; Sets the global current topic variable; When performing a screen clearing operation or a drawing operation that requires clearing the buffer, the corresponding color value is obtained from the theme color array based on the value of the global current theme variable and then filled. When switching themes, only the value of the global current theme variable is modified.

[0108] During system initialization, the display framework pre-defines a two-dimensional theme color array in read-only memory. The first dimension index of this array represents a different theme number, and the second dimension index represents the color type required for various display elements under that theme (e.g., background color, text color, border color, highlight color, etc.). Each color value is stored in integer form suitable for the screen hardware format (e.g., combinations of red, green, and blue components). Simultaneously, the display framework maintains a global variable in random access memory, called the current theme variable, to record the theme number currently in use by the system. This variable is set to the default theme number at system startup and can be modified by the business logic layer at runtime.

[0109] When the display framework processes a block identified as a screen clearing operation (e.g., fixed color screen clearing or theme color screen clearing) or a drawing operation requiring buffer clearing (e.g., drawing after clearing or drawing after theme color clearing), it first reads the value of the current theme variable. Using this value as the first-dimensional index, it searches the theme color array for the corresponding color type column and retrieves the required specific color value. For screen clearing operations, the display framework directly uses this color value to fill the entire screen or a specified area; for drawing operations requiring buffer clearing, the display framework allocates a temporary buffer, fills the entire buffer with this color value, and then calls the callback function for subsequent drawing. When the business logic layer needs to switch the interface theme, it only needs to modify the value of the current theme variable to the target theme number, without updating the color configuration of each display block individually. Afterward, any newly executed screen clearing or buffer clearing operation will automatically read the color value corresponding to the new theme from the theme color array, thus achieving one-click dynamic switching of the entire interface theme without restarting the system or rebuilding the display framework.

[0110] The above process uses a predefined two-dimensional theme color array (row index: theme number, column index: color type) combined with a global current theme variable to centrally store all color configurations and separate them from business logic. Each time the screen is cleared or the buffer is cleared, the color value corresponding to the current theme is dynamically read and filled, so that the same set of display code automatically produces different visual effects under different themes. Theme switching only requires modifying the global variable value, and a single assignment can complete the global theme update without traversing and modifying each display element. The switching time is constant and can be triggered at any time without causing interface lag.

[0111] In one embodiment of this application, it further includes: In a bare-metal environment, a global variable is defined as a direct memory access completion flag, which is set by an interrupt service routine. The display frame achieves synchronization by polling and waiting for this flag. In a real-time operating system environment, a binary semaphore is defined as a direct memory access synchronization object. The semaphore is released by the interrupt service routine, and the display frame achieves synchronization by waiting for the semaphore. The display framework selects the corresponding synchronization method based on the current development environment configuration.

[0112] Specifically, in a bare-metal environment, the display framework predefines a global variable as a flag indicating the completion of direct memory access (DMI) data transfer. This flag is initialized to an incomplete state during system startup. When the display framework needs to transfer pixel data from the buffer to the screen, it configures and starts the DMI controller to begin the transfer, simultaneously clearing the global flag. After the DMI controller completes the data transfer in the background, it triggers a transfer completion interrupt, which is then executed. Within this interrupt service routine, the global flag is set to the completed state. After initiating DMI transfer, the display framework immediately enters a polling loop, continuously reading the value of the global flag until it detects that the flag has changed to the completed state. During polling, the CPU is occupied, but no operating system support is required, ensuring that subsequent operations, such as releasing temporary buffers or continuing to process the next block, are performed only after the transfer is complete in a bare-metal single-task environment.

[0113] In a real-time operating system environment, the display framework does not use polling. Instead, it pre-creates a binary semaphore as a synchronization object for direct memory access (DMI) transfers. This semaphore is initially empty. When the display framework initiates a DMI transfer, it does not poll but instead calls the semaphore wait function provided by the real-time operating system, suspending the current display task and relinquishing processor resources. Upon completion of the DMI transfer, an interrupt is triggered, and the interrupt service routine is called. Within this routine, the semaphore release function is invoked, setting the binary semaphore to an active state, thus waking up the previously suspended display task. Once awakened, the display task continues execution, confirms the transfer is complete, and then releases the buffer or performs subsequent processing. During compilation or initialization, the display framework selects between polling using a bare-metal global variable flag or the real-time operating system's binary semaphore wait method through conditional compilation or runtime configuration, allowing the same display framework code to seamlessly adapt to two different development environments.

[0114] The above process achieves unified adaptation between bare-metal and real-time operating system environments through an abstract direct memory access synchronization mechanism: In the bare-metal environment, global flags are defined, interrupt service routines are set, and the display framework polls and waits, achieving lightweight synchronization with zero dependencies; In the real-time operating system environment, binary semaphores are defined, interrupt service routines release semaphores, and the display task blocks and waits, yielding the processor to improve multi-tasking throughput; The display framework automatically selects the corresponding mode according to the compilation configuration, and the same set of source code can run seamlessly in both environments, greatly improving software portability and reusability.

[0115] This application's technical solution achieves logical isolation and parallel development between blocks by dividing the screen into independent blocks and configuring complete attributes such as coordinates, size, type, callback, and interface affiliation. The combination of the registration mechanism and the display queue allows business logic to trigger interface updates asynchronously without waiting for rendering to complete, avoiding blocking. Interface filtering is based on the comparison between the current number and the affiliation identifier, skipping non-current interface blocks before resource allocation, achieving multi-interface isolation and cross-interface reuse at zero cost. Type-driven branching processing allows drawing-type (temporary buffer allocation and release), screen-clearing-type (direct filling), image-type (decoding and direct writing), and pure function-type (only executing callbacks) to each adopt the optimal resource utilization method. Loop scheduling ensures that requests are responded to in order, and can enter idle mode when the queue is empty, realizing the unification of batch processing and asynchronous response of display tasks, and improving the efficiency of embedded system display development.

[0116] The following describes embodiments of the display development apparatus for embedded systems without GUI libraries according to this application, which can be used to execute the display development method for embedded systems without GUI libraries in the above embodiments of this application. It is understood that the display development apparatus for embedded systems without GUI libraries can be a computer program (including program code) running on a computer device. This display development apparatus for embedded systems without GUI libraries can be used to execute the corresponding steps in the method provided in the embodiments of this application. For details not disclosed in the embodiments of the display development apparatus for embedded systems without GUI libraries of this application, please refer to the embodiments of the display development method for embedded systems without GUI libraries described above in this application.

[0117] Figure 3 A block diagram of a display development apparatus for embedded systems without GUI libraries, according to an embodiment of this application, is shown.

[0118] Reference Figure 3 As shown, a display development apparatus for embedded systems without GUI libraries according to an embodiment of this application includes: The configuration module 310 is used to divide the display area into multiple independent blocks and configure attribute information for each block; the attribute information includes block coordinates, block size, type identifier, callback function pointer and interface ownership identifier; The reading module 320 is used to register the attribute information of each block to the display framework of the preset embedded software and read the display queue in a loop to obtain the blocks to be displayed. The filtering module 330 is used to filter out blocks belonging to the current interface or shared across interfaces based on the comparison result between the current interface number and the interface belonging identifier. The processing module 340 is used to perform corresponding display processing operations based on the type identifier of the filtered blocks; the display processing operation includes at least one of the following: if the type identifier is a drawing type that requires buffer allocation, then a temporary buffer is allocated, a callback function is called to draw, and the buffer content is transmitted to the screen; if the type identifier is a screen clearing type, then screen clearing is performed; if the type identifier is an image type, then the image is decoded and displayed; if the type identifier is a pure function type, then only the callback function is called; The iteration module 350 is used to repeat the reading, filtering and display processing operations until there are no blocks to be displayed in the display queue.

[0119] In this application, based on the aforementioned scheme, the step of performing the corresponding display processing operation according to the type identifier of the filtered block includes: if the type identifier of the filtered block is a drawing type that requires buffer allocation, then the rendering of the entire block is decomposed into multiple small-area renderings according to the single rendering height, step increment, and number of renderings in the block attributes; each rendering allocates only a buffer corresponding to the single rendering height and block width, and after the rendering is completed, the buffer content is transferred to the corresponding position on the screen; the above process is repeated until the rendering of the entire block is completed.

[0120] In this application, based on the aforementioned scheme, it further includes: a predefined theme color array, wherein each row of the theme color array corresponds to a theme number and each column corresponds to a color type; a global current theme variable is set; when a screen clearing operation or a drawing operation that requires clearing the buffer is performed, the corresponding color value is obtained from the theme color array according to the value of the global current theme variable and filled; when the theme is switched, only the value of the global current theme variable is modified.

[0121] In this application, based on the aforementioned scheme, the interface attribution identifier includes a first identifier value and a second identifier value. The first identifier value is used to identify that the block belongs only to a specific interface with the same value, and the second identifier value is used to identify that the block is a cross-interface shared block. The step of filtering out blocks belonging to the current interface or cross-interface shared blocks based on the comparison result between the current interface number and the interface attribution identifier includes: when the interface attribution identifier of the block to be displayed is equal to the current interface number or equal to the second identifier value, it is determined that the block passes the filtering and is displayed; otherwise, the block is skipped.

[0122] In this application, based on the aforementioned scheme, the type identifier includes a pure function type value; when the type identifier of the block is equal to the pure function type value, no buffer is allocated, no display operation is performed, and only the business logic function pointed to by the callback function pointer associated with the block is called.

[0123] In this application, based on the aforementioned scheme, it further includes: in a bare-metal environment, defining a global variable as a direct memory access completion flag, which is set by an interrupt service routine, and the display framework achieves synchronization by polling and waiting for the flag; in a real-time operating system environment, defining a binary semaphore as a direct memory access synchronization object, which is released by an interrupt service routine, and the display framework achieves synchronization by waiting for the semaphore; the display framework selects the corresponding synchronization method according to the current development environment configuration.

[0124] In this application, based on the aforementioned scheme, the display queue is implemented using an array circular queue or a real-time operating system message queue; the attribute information of each block is registered to the display framework through a static structure array or a dynamic linked list.

[0125] This application's technical solution achieves logical isolation and parallel development between blocks by dividing the screen into independent blocks and configuring complete attributes such as coordinates, size, type, callback, and interface affiliation. The combination of the registration mechanism and the display queue allows business logic to trigger interface updates asynchronously without waiting for rendering to complete, avoiding blocking. Interface filtering is based on the comparison between the current number and the affiliation identifier, skipping non-current interface blocks before resource allocation, achieving multi-interface isolation and cross-interface reuse at zero cost. Type-driven branching processing allows drawing-type (temporary buffer allocation and release), screen-clearing-type (direct filling), image-type (decoding and direct writing), and pure function-type (only executing callbacks) to each adopt the optimal resource utilization method. Loop scheduling ensures that requests are responded to in order, and can enter idle mode when the queue is empty, realizing the unification of batch processing and asynchronous response of display tasks, and improving the efficiency of embedded system display development.

[0126] Figure 4 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown.

[0127] It should be noted that the computer system of the electronic device in this embodiment is only an example and should not impose any limitations on the function and scope of use of the embodiments of this application.

[0128] In this embodiment, the computer system includes a central processing unit 401, which can perform various appropriate actions and processes based on programs stored in read-only memory 402 or programs loaded from storage section 408 into random access memory 403, such as executing the display development method for embedded systems without GUI libraries described in the above embodiment. The random access memory 403 also stores various programs and data required for system operation, thereby realizing big data storage and big data management. The central processing unit 401, read-only memory 402, and random access memory 403 are interconnected via bus 404. Input / output interface 405 is also connected to bus 404.

[0129] The following components are connected to the input / output interface 405: an input section 406 including a keyboard, mouse, etc.; an output section 407 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 408 including a hard disk, etc.; and a communication section 409 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 409 performs communication processing via a network such as the Internet. A drive 410 is also connected to the input / output interface 405 as needed. A removable medium 411, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 410 as needed so that computer programs read from it can be installed into the storage section 408 as needed.

[0130] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 409, and / or installed from removable medium 411. When the computer program is executed by central processing unit 401, it performs various functions defined in the system of this application.

[0131] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. The transmitted data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0132] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0133] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0134] According to one aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in the various alternative implementations described above.

[0135] In another aspect, this application also provides a computer-readable medium, which may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the electronic device. The computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to implement the display development method for GUI-less embedded systems described in the above embodiments.

[0136] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0137] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the methods according to the embodiments of this application.

[0138] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0139] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for display development in embedded systems without a GUI library, characterized in that, include: The display area is divided into multiple independent blocks, and attribute information is configured for each block; the attribute information includes block coordinates, block size, type identifier, callback function pointer, and interface ownership identifier; By registering the attribute information of each block to the display framework of the preset embedded software, the display queue is read in a loop to obtain the blocks to be displayed; Based on the comparison result between the current interface number and the interface ownership identifier, the blocks belonging to the current interface or shared across interfaces are filtered out. Based on the type identifier of the filtered blocks, perform the corresponding display processing operation; the display processing operation includes at least one of the following: If the type is identified as a drawing type that requires buffer allocation, then a temporary buffer is allocated, a callback function is called to draw, and the contents of the buffer are transferred to the screen. If the type is identified as screen clearing, then screen clearing is performed; If the type identifier is image, then decode and display the image; If the type is identified as a pure function, then only the callback function is called; Repeat the reading, filtering, and display processing operations until there are no more blocks to be displayed in the display queue.

2. The display development method for embedded systems without GUI libraries according to claim 1, characterized in that, Based on the type identifier of the filtered blocks, perform the corresponding display processing operation, including: If the type of the filtered block is identified as a drawing type that requires buffer allocation, then the rendering of the entire block is decomposed into multiple small-area renderings based on the single rendering height, step increment, and number of renderings in the block attributes. Each rendering allocates only a buffer corresponding to the single rendering height and block width, and after rendering is completed, the buffer content is transferred to the corresponding position on the screen; Repeat the above process until the entire block is rendered.

3. The display development method for embedded systems without GUI libraries according to claim 1 or 2, characterized in that, Also includes: A predefined theme color array, wherein each row of the theme color array corresponds to a theme number and each column corresponds to a color type; Sets the global current topic variable; When performing a screen clearing operation or a drawing operation that requires clearing the buffer, the corresponding color value is obtained from the theme color array based on the value of the global current theme variable and then filled. When switching themes, only the value of the global current theme variable is modified.

4. The display development method for embedded systems without GUI libraries according to claim 1, characterized in that, Based on the comparison result between the current interface number and the interface ownership identifier, blocks belonging to the current interface or shared across interfaces are filtered out, including: The interface attribution identifier includes a first identifier value and a second identifier value. The first identifier value is used to identify that the block belongs only to a specific interface with the same value, and the second identifier value is used to identify that the block is a cross-interface shared block. When the interface ownership identifier of the block to be displayed is equal to the current interface number or equal to the second identifier value, the block is determined to have passed the filtering and is displayed.

5. The display development method for embedded systems without GUI libraries according to claim 1, characterized in that, The type identifier includes a pure function type value; when the type identifier of the block is equal to the pure function type value, no buffer is allocated, no display operation is performed, and only the business logic function pointed to by the callback function pointer associated with the block is called.

6. The display development method for embedded systems without GUI libraries according to claim 1, characterized in that, Also includes: In a bare-metal environment, a global variable is defined as a direct memory access completion flag, which is set by an interrupt service routine. The display frame achieves synchronization by polling and waiting for this flag. In a real-time operating system environment, a binary semaphore is defined as a direct memory access synchronization object. The semaphore is released by the interrupt service routine, and the display frame achieves synchronization by waiting for the semaphore. The display framework selects the corresponding synchronization method based on the current development environment configuration.

7. The display development method for embedded systems without GUI libraries according to claim 1, characterized in that, The display queue is implemented using an array circular queue or a real-time operating system message queue; the attribute information of each block is registered to the display framework through a static structure array or a dynamic linked list.

8. A display development device for embedded systems without GUI libraries, characterized in that, include: The configuration module is used to divide the display area into multiple independent blocks and configure attribute information for each block; the attribute information includes block coordinates, block size, type identifier, callback function pointer, and interface ownership identifier; The reading module is used to register the attribute information of each block to the display framework of the preset embedded software, and to read the display queue in a loop to obtain the blocks to be displayed. The filtering module is used to filter out blocks belonging to the current interface or shared across interfaces based on the comparison result between the current interface number and the interface belonging identifier. The processing module is used to perform corresponding display processing operations based on the type identifier of the filtered blocks; the display processing operation includes at least one of the following: if the type identifier is a drawing type that requires buffer allocation, then a temporary buffer is allocated, a callback function is called to draw, and the buffer content is transmitted to the screen; if the type identifier is a screen clearing type, then screen clearing is performed; if the type identifier is an image type, then the image is decoded and displayed; if the type identifier is a pure function type, then only the callback function is called; The iteration module is used to repeat the reading, filtering, and display processing operations until there are no more blocks to be displayed in the display queue.

9. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the display development method for embedded systems without GUI libraries as described in any one of claims 1 to 7.

10. An electronic device, characterized in that, include: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the display development method for embedded systems without GUI libraries as described in any one of claims 1 to 7.

Images