A centralized decision-making master-slave screen interface control method

Abstract

The application relates to a centralized decision-making master-slave screen interface control method, and belongs to the technical field of screen communication control. The method comprises the following steps: a slave side captures a touch event and maintains an event counting semaphore, the semaphore is increased by one every time the event is captured, and event information is stored in a buffer area; a master side monitors the change of the semaphore, actively reads the event information when the semaphore changes, and directly receives a physical key event; the master side serves as a decision node, judges whether switching is allowed according to a global interface state machine and preset rules, and issues a switching instruction when the switching is allowed; the slave side verifies whether the current state meets the switching condition after receiving the instruction, and only executes interface switching when the verification is passed, otherwise, the current interface is maintained and no active jump is initiated. The application completely concentrates the interface switching decision-making right in the master, guarantees the smoothness of high-frequency operation through a semaphore queuing mechanism, and enhances the system robustness through secondary verification of the slave.

Description

Technical Field

[0001] This invention belongs to the field of screen communication control technology, specifically relating to a centralized decision-making master-slave screen interface control method. Background Technology

[0002] With the increasing popularity of smart homes, high-end small appliances, and industrial human-machine interface devices, control panels with displays are becoming mainstream. Users interact with these devices via touchscreens or physical buttons, expecting smooth and accurate interface responses. Currently, in smart control devices with displays, the common control architecture for achieving interface display and external input interaction typically consists of a main control module, a display driver module, a touchscreen module, and a physical button module. The physical button module is directly connected to the GPIO interface of the display driver module or via a separate button MCU; the touchscreen module communicates directly with the display driver module (usually via I2C or SPI interfaces), reporting touch coordinates to the display driver module; the main control module is responsible for the device's business logic processing (such as motor control, heating, etc.) and interacts with the display driver module via serial port or SPI.

[0003] In the above architecture, the display driver module is responsible for all interface logic processing. When the user touches the screen or presses a physical button, the display driver module directly responds and switches the interface of LVGL or other GUI libraries, while sending the user's operation commands to the main control module via serial port, and the main control module executes the corresponding device functions.

[0004] However, as device functions become increasingly complex, especially when multi-level interface transitions, animation effects, and complex state machines are involved, the existing architecture described above reveals the following significant drawbacks: First, the interface status and device status are prone to synchronization issues. The decision-making power for interface switching rests with the display driver module (slave), while the device status is maintained by the master control module (master). When a logical flaw occurs in the slave software's status judgment, the displayed interface is inconsistent with the actual system working status recorded by the master. Furthermore, because the display end and the logic end are separated, this problem is extremely difficult to locate and fix.

[0005] Secondly, multiple input sources lead to logic redundancy and high coupling. Existing solutions need to handle both physical buttons and touchscreens simultaneously, both of which are directly connected to or control the display driver module. This results in the display driver module having to handle a large amount of state judgment work (such as determining the current interface and whether navigation is allowed). If the physical buttons are controlled by a separate MCU, the display driver module also needs to parse the button commands from the host, causing the same set of state logic to be implemented repeatedly in two MCUs, resulting in high development costs and inconsistencies.

[0006] Third, event processing is inefficient and carries the risk of blocking. When a user rapidly and continuously touches the screen, the display driver module needs to respond to each event immediately. If the interface transition is accompanied by complex animations, a large amount of graphics computation will consume MCU resources, causing subsequent events to be unable to be processed in a timely manner, resulting in lag or resource conflicts, or even system crashes.

[0007] Fourth, serial communication lacks reliability. Existing technologies typically use a "request-response" or simple one-way transmission method, lacking retry and state recovery mechanisms. Once communication data is lost, the interface is prone to freezing, resulting in a poor user experience.

[0008] To address the aforementioned problems, this invention aims to provide a centralized decision-making master-slave screen interface control method to fundamentally solve issues such as state synchronization failure, logic redundancy, high-frequency operation lag, and insufficient communication reliability. Summary of the Invention

[0009] To address the aforementioned problems in the existing technology, this invention provides a centralized decision-making master-slave screen interface control method. The objective of this invention can be achieved through the following technical solutions: A centralized decision-making master-slave screen interface control method includes: The slave device captures touch events and maintains an event counter semaphore. Each time a touch event is captured, the semaphore is incremented by one, and the event information is stored in the buffer to overwrite the old data. The above capture, semaphore increment, and buffer write operations are continuously performed during the execution of interface animations or switching on the slave device. The host device directly receives physical button events; the slave device does not make any predictions or decisions regarding whether touch events will trigger interface switching. The host monitors changes in the event counting semaphore. When a change in the semaphore value is detected, the host reads the event information from the slave's buffer. As the sole interface switching decision node, the host independently determines whether switching is allowed for each read event based on the global interface state machine and preset switching rules. If allowed, a switching command is generated and sent to the slave; if not allowed, no command is sent. After receiving the switching instruction from the slave device, it first checks whether the current state meets the switching conditions. If the verification passes, it performs the interface switching. If no instruction is received or the verification fails, the slave device maintains the current interface unchanged and does not actively initiate any interface jump.

[0010] Specifically, the event counting semaphore is maintained by the slave side, and the master side monitors its changes through polling or interruption. When the master side detects that the semaphore value is different from the reference value recorded last time, it triggers an event read operation. After the master side completes an event read, it decrements the semaphore by one or updates it to the currently processed count value.

[0011] Specifically, the cache is a single-element cache that only stores the event information of the most recent touch event. When a new touch event occurs, the latest event information is directly written into the cache to overwrite the old data, and no event queue is maintained. The slave device does not actively clear the cache. After the master device reads the event information in the cache each time, the contents of the cache remain unchanged until the next touch event overwrites it.

[0012] Specifically, the communication link between the host and slave sides uses a UART serial port; the communication frame format includes, in order: a one-byte frame header, a one-byte instruction type, a variable-length data field, and a one-byte checksum; the switching instruction is encapsulated using this frame format, the instruction type field identifies it as an interface switching instruction, and the data field carries the target interface identifier; after the slave side receives the complete frame, it first performs checksum calculation on the data excluding the frame header and compares it with the received checksum, and if the comparison passes, it parses and executes the message.

[0013] Specifically, after the host side issues a switching command, it does not wait for confirmation from the slave side, nor does it retransmit the command. When the slave side fails the checksum or passes the checksum but its current state does not meet the switching conditions, it silently discards the command, does not send any negative response or error feedback, and maintains the original interface unchanged.

[0014] Specifically, the physical buttons are directly connected to one or more GPIO interfaces on the host side. The host side captures button events through rising edge or falling edge interrupts, and button debouncing is performed by the host side. The touch screen is connected to the slave side through an I2C or SPI interface. The slave side obtains touch coordinates through polling or interrupts, and converts the coordinates into a preset touch area ID as event information and stores it in the buffer.

[0015] Specifically, the verification of whether the current state meets the switching conditions includes: determining whether the slave device is currently executing a graphics library animation interface call or an interface switching action; if an animation is playing or a switching is in progress, the currently received switching instruction is rejected and the instruction is discarded.

[0016] Specifically, it also includes: determining whether the currently displayed interface identifier on the slave side allows jumping to the target interface indicated by the switching command; wherein, the slave side has a pre-stored interface jump permission table or a set of rules, recording the set of target interfaces allowed to jump to under each source interface; if the target interface is not in the permission set, execution is refused; if the target interface identifier exceeds the range of interfaces supported by the slave side, execution is refused.

[0017] Specifically, the host side maintains a global interface state machine, which records the current interface identifier and the set of allowed target interfaces for each interface. When a key event is received or touch event information is read, the host side looks up the table based on the current interface identifier and the event content to determine whether switching is allowed. If allowed, the host side updates its recorded current interface identifier to the target interface while sending the switching command.

[0018] Specifically, the operation of continuously capturing touch events on the slave side during the execution of interface animation or switching is a non-blocking operation; the coordinate scanning of the touch screen is located in an interrupt service routine or a high-priority task, and is not blocked or delayed due to the rendering of the graphics library or the delay of the animation; when the slave side is in the waiting delay stage of animation playback, the touch interrupt is still responded to, and the semaphore increment and buffer write operations are still executed.

[0019] Specifically, the event information includes a touch area ID; a static mapping table of touch screen coordinate ranges to area IDs is pre-stored on the slave side, with each area ID corresponding to a rectangular area on the screen; after capturing the touch coordinates, the area ID is obtained by traversal or calculation using a formula; if the coordinates fall in an invalid area, the touch event is ignored, and no semaphore increment or cache writing is performed.

[0020] Specifically, the method is applied to an embedded human-machine interaction device with at least one physical button and a touch screen; the device is any one of a smart home central control screen, a small home appliance control panel, an industrial human-machine interface, or a consumer electronics product with a screen; the host side and the slave side each correspond to two independent microcontrollers, or are integrated on different cores of the same multi-core microcontroller.

[0021] The beneficial effects of this invention are as follows: The interface state and device state are strictly consistent, eliminating any possibility of state misalignment. This invention completely shifts the decision-making power for interface switching to the host, which acts as the sole decision-making node to maintain the global interface state machine. All input events are uniformly judged by the host before issuing instructions, with slave devices only passively executing them. Compared to existing technologies where slave-driven decision-making can easily lead to inconsistencies between the interface and device states, this invention fundamentally eliminates the risk of misalignment, significantly improving system reliability and maintainability.

[0022] This invention unifies the handling of multi-source inputs, simplifying the architecture and reducing code complexity. Physical button presses and touch events are centrally processed by the host, while slave devices are only responsible for data acquisition, rendering, and semaphore maintenance, eliminating the need to maintain interface switching rules. Compared to existing technologies where slave devices need to handle dual input sources and repeatedly maintain state logic with the host, this invention achieves single-point rule maintenance, reducing code coupling and redundancy, and shortening development cycles and maintenance costs.

[0023] The semaphore event mechanism ensures smooth, lag-free high-frequency operations. The slave device records touch events using semaphores and single-element buffers, enabling non-blocking data acquisition even during animations and transitions; the master device processes events sequentially by monitoring semaphore changes. Compared to existing technologies that are prone to graphics library conflicts and interface lag due to high-frequency operations, this invention reliably records and executes events in an orderly manner, significantly improving interaction smoothness and stability.

[0024] One-way reliable communication and secondary verification by the slave device enhance system robustness. Communication between the master and slave devices uses a frame format with checksums, allowing the master to issue commands without waiting for a response; upon receiving a command, the slave device first verifies the data's validity and then checks whether the current state allows for a handover. Compared to existing technologies that suffer from unreliable communication, frequent freezing, or abnormal jumps, this invention effectively avoids illegal handovers with low overhead, improving the system's anti-interference capabilities.

[0025] Improved development maintainability and optimized hardware costs. Interface rules are centralized on the host, allowing upgrades and expansions without modifying the slave device; the slave device does not need to handle complex logic, enabling the use of a lower-cost MCU; the host reuses existing hardware without incurring additional costs. The overall system is easier to debug and mass-produce, offering higher cost-effectiveness and versatility. Attached Figure Description

[0026] To facilitate understanding by those skilled in the art, the present invention will be further described below with reference to the accompanying drawings.

[0027] Figure 1 This is a flowchart of the method of the present invention; Figure 2 This is a diagram of the dual MCU architecture of the present invention; Figure 3 This is a timing diagram of the semaphore mechanism of the present invention; Figure 4 This is a flowchart of the slave secondary verification process of the present invention. Detailed Implementation

[0028] To further illustrate the technical means and effects of the present invention in achieving its intended purpose, the following detailed description of the specific implementation methods, structures, features, and effects of the present invention, in conjunction with the accompanying drawings and preferred embodiments, is provided.

[0029] Please see Figures 1-4 A centralized decision-making master-slave screen interface control method, comprising: The slave device captures touch events and maintains an event counter semaphore. Each time a touch event is captured, the semaphore is incremented by one, and the event information is stored in the buffer to overwrite the old data. The above capture, semaphore increment, and buffer write operations are continuously performed during the execution of interface animations or switching on the slave device. The host device directly receives physical button events; the slave device does not make any predictions or decisions regarding whether touch events will trigger interface switching. The host monitors changes in the event counting semaphore. When a change in the semaphore value is detected, the host reads the event information from the slave's buffer. As the sole interface switching decision node, the host independently determines whether switching is allowed for each read event based on the global interface state machine and preset switching rules. If allowed, a switching command is generated and sent to the slave; if not allowed, no command is sent. After receiving the switching instruction from the slave device, it first checks whether the current state meets the switching conditions. If the verification passes, it performs the interface switching. If no instruction is received or the verification fails, the slave device maintains the current interface unchanged and does not actively initiate any interface jump.

[0030] Specifically, the event counting semaphore is maintained by the slave side, and the master side monitors its changes through polling or interruption. When the master side detects that the semaphore value is different from the reference value recorded last time, it triggers an event read operation. After the master side completes an event read, it decrements the semaphore by one or updates it to the currently processed count value.

[0031] Specifically, the cache is a single-element cache that only stores the event information of the most recent touch event. When a new touch event occurs, the latest event information is directly written into the cache to overwrite the old data, and no event queue is maintained. The slave device does not actively clear the cache. After the master device reads the event information in the cache each time, the contents of the cache remain unchanged until the next touch event overwrites it.

[0032] Specifically, the communication link between the host and slave sides uses a UART serial port; the communication frame format includes, in order: a one-byte frame header, a one-byte instruction type, a variable-length data field, and a one-byte checksum; the switching instruction is encapsulated using this frame format, the instruction type field identifies it as an interface switching instruction, and the data field carries the target interface identifier; after the slave side receives the complete frame, it first performs checksum calculation on the data excluding the frame header and compares it with the received checksum, and if the comparison passes, it parses and executes the message.

[0033] Specifically, after the host side issues a switching command, it does not wait for confirmation from the slave side, nor does it retransmit the command. When the slave side fails the checksum or passes the checksum but its current state does not meet the switching conditions, it silently discards the command, does not send any negative response or error feedback, and maintains the original interface unchanged.

[0034] Specifically, the physical buttons are directly connected to one or more GPIO interfaces on the host side. The host side captures button events through rising edge or falling edge interrupts, and button debouncing is performed by the host side. The touch screen is connected to the slave side through an I2C or SPI interface. The slave side obtains touch coordinates through polling or interrupts, and converts the coordinates into a preset touch area ID as event information and stores it in the buffer.

[0035] Specifically, the verification of whether the current state meets the switching conditions includes: determining whether the slave device is currently executing a graphics library animation interface call or an interface switching action; if an animation is playing or a switching is in progress, the currently received switching instruction is rejected and the instruction is discarded.

[0036] Specifically, it also includes: determining whether the currently displayed interface identifier on the slave side allows jumping to the target interface indicated by the switching command; wherein, the slave side has a pre-stored interface jump permission table or a set of rules, recording the set of target interfaces allowed to jump to under each source interface; if the target interface is not in the permission set, execution is refused; if the target interface identifier exceeds the range of interfaces supported by the slave side, execution is refused.

[0037] Specifically, the host side maintains a global interface state machine, which records the current interface identifier and the set of allowed target interfaces for each interface. When a key event is received or touch event information is read, the host side looks up the table based on the current interface identifier and the event content to determine whether switching is allowed. If allowed, the host side updates its recorded current interface identifier to the target interface while sending the switching command.

[0038] Specifically, the operation of continuously capturing touch events on the slave side during the execution of interface animation or switching is a non-blocking operation; the coordinate scanning of the touch screen is located in an interrupt service routine or a high-priority task, and is not blocked or delayed due to the rendering of the graphics library or the delay of the animation; when the slave side is in the waiting delay stage of animation playback, the touch interrupt is still responded to, and the semaphore increment and buffer write operations are still executed.

[0039] Specifically, the event information includes a touch area ID; a static mapping table of touch screen coordinate ranges to area IDs is pre-stored on the slave side, with each area ID corresponding to a rectangular area on the screen; after capturing the touch coordinates, the area ID is obtained by traversal or calculation using a formula; if the coordinates fall in an invalid area, the touch event is ignored, and no semaphore increment or cache writing is performed.

[0040] Specifically, the method is applied to an embedded human-machine interaction device with at least one physical button and a touch screen; the device is any one of a smart home central control screen, a small home appliance control panel, an industrial human-machine interface, or a consumer electronics product with a screen; the host side and the slave side each correspond to two independent microcontrollers, or are integrated on different cores of the same multi-core microcontroller.

[0041] Example 1 (Dual MCU Master-Slave Architecture) This embodiment uses a smart home appliance control panel with touch display and physical buttons as a specific application scenario, and adopts a dual-MCU master-slave distributed architecture to achieve centralized interface control. It should be noted that this embodiment is only a preferred implementation of the present invention, and is also applicable to other devices with similar requirements, such as smart home central control screens and industrial human-machine interfaces.

[0042] I. System Hardware Configuration and Connection Relationships In this embodiment, the host module uses an AT32F421 microcontroller as the global decision-making core, responsible for device business logic, physical button acquisition, global interface state management, and interface switching decisions. The slave module uses an AT32F403A microcontroller with a built-in graphics acceleration unit and a lightweight LVGL graphics library, responsible for touchscreen data acquisition, interface rendering, animation playback, and instruction execution.

[0043] The hardware connection relationships are as follows: The three physical buttons are connected to the host's GPIO ports, configured to trigger interrupts on the rising edge, and the host performs software debouncing. The button events are directly captured by the host. The capacitive touchscreen connects to the slave device via an I2C bus, and the slave device reads the touch coordinate data in real time via interrupt. The master and slave devices communicate in full-duplex via UART serial port. The communication parameters are configured as follows: baud rate 115200bps, 8 data bits, 1 stop bit, and no parity bit. The communication frame adopts a unified format: it contains a 1-byte frame header, a 1-byte instruction type, a variable-length data field, and a 1-byte checksum.

[0044] II. System Core Data Structure Slave-side data structure: The slave maintains two core data units.

[0045] Event Count Semaphore: An 8-bit unsigned integer variable used to mark the number of touch events. Event information cache: A single-element cache structure used to store the touch area ID and original coordinates obtained from the latest touch event parsing. New events directly overwrite old data; no multi-event queue is maintained. After the slave device reads the cache from the master device, it does not empty the cache; its contents are retained until the next touch event overwrites it.

[0046] Host-side data structure: The host independently maintains a global interface state machine to record the identifier of the currently displayed interface; at the same time, it pre-stores an interface jump rule table, each rule containing the source interface, trigger event number, target interface and jump enabling conditions, which serves as the sole basis for interface switching decisions.

[0047] III. Complete Workflow (1) Touch event capture, semaphore update and cache write When a user touches the display screen, the slave device reads the touch coordinate data via an I2C interrupt. Based on a preset screen area mapping, it converts the coordinates into the corresponding touch area ID. If the coordinates fall outside the preset mapping area, the touch is considered invalid, and the event is ignored without semaphore incrementing or buffer writing. The slave device performs the following processing atomically: Increment the event counter semaphore by 1; Write the ID and coordinates of the touched area to the event information cache, directly overwriting the original data.

[0048] The slave device does not make any predictions or autonomous decisions regarding whether a touch event will trigger an interface switch.

[0049] During the playback of interface animations or the execution of interface switching, the touch interrupt of the slave device remains enabled. The above-mentioned event capture, semaphore update and cache write operations continue to be executed without being blocked or delayed by the graphics rendering process, ensuring that events are not lost under high-frequency and continuous touch operations.

[0050] (2) The host monitors the semaphore and reads the event information. The master monitors the slave's event count semaphore using a fixed-period polling method (an alternative method can be adopted where the slave actively interrupts to notify the master), while maintaining the semaphore reference value read in the previous cycle. When the master detects that the current semaphore value is inconsistent with the reference value, it determines that a new touch event has occurred, immediately reads the latest event information in the slave's buffer via the UART serial port, and updates the reference value to the current semaphore value.

[0051] Since the buffer only retains the latest touch event, the host directly synchronizes the reference value to the current semaphore value. The old events accumulated in the middle are discarded due to buffer overwriting. This is consistent with the interaction logic that only the last operation needs to be responded to in continuous touch scenarios.

[0052] For physical buttons, the host directly captures the button number via GPIO interrupt, without needing to forward it through the slave device, thus ensuring the real-time response of the physical buttons.

[0053] (3) Centralized decision-making and switching instruction issuance by the host As the sole decision-making unit for interface switching in the system, the host, after acquiring key event or touch event information, queries the global interface state machine and the interface transition rule table to independently determine whether the current event allows for an interface switch. If the jump conditions are met, the host encapsulates the switching instruction according to the preset communication frame format, with the instruction type identified as interface switching, the data field carrying the target interface ID, and calculates the checksum before sending it to the slave; at the same time, the host updates the current interface identifier it maintains to the target interface ID; If the jump conditions are not met, the host will not generate or issue any instructions and will directly discard the current event.

[0054] (4) Slave instruction verification and interface switching execution After the slave device receives the complete data frame via the serial port, it first performs checksum verification on the frame data: If the verification fails, the current data frame is discarded without responding to any response signal, and the current interface remains unchanged. If the verification passes, the slave device performs multi-level status verification on the switching command: Determine if the current state is an animation playback or interface switching execution state; if so, refuse to execute. Determine if the target interface ID is a valid and legitimate interface; Determine whether the current interface and the target interface meet the preset jump constraints.

[0055] After all checks pass, the slave device calls the LVGL graphics library interface to execute interface rendering and switching animation; if any check fails, the slave device silently discards the instruction and does not execute any interface jump.

[0056] (5) Continuous event loop processing After the slave device completes one interface switch, it enters the normal display state. If the user triggers another touch operation during this period, the slave device continues to update the semaphore and buffer; the master device detects the semaphore change in the next round of polling, reads the event again and executes the decision process, realizing an orderly response to continuous operations, and preventing event blocking or chaos due to animation delays.

[0057] IV. Abnormal Scenarios and Reliability Description In complex environments such as those with electromagnetic interference, if serial data distortion leads to checksum errors, the slave device will directly discard the erroneous frame without executing an illegal jump. The master device employs a one-way command issuance mechanism, eliminating the need to wait for slave device responses and preventing deadlocks or freezes due to communication anomalies. Furthermore, because interface switching decisions are entirely centralized in the master device, with the slave device passively executing commands, the issue of discrepancies between the displayed interface and the actual operating status of the device is completely avoided.

[0058] V. Description of the Effects of the Implementation Examples In a comparative test of continuous high-frequency touch during animation playback, this embodiment can reliably record all valid events, with smooth interface switching without lag, resource conflicts, or system crashes; the interface state and the host business state are always synchronized. Compared with the traditional slave autonomous decision-making architecture, the system stability, interaction smoothness, and maintainability are significantly improved.

[0059] Example 2 (Single-chip multi-tasking architecture) The difference between this embodiment and Embodiment 1 is that the host function and slave function are integrated into the same multi-core microcontroller (or a single-core MCU is used in conjunction with a real-time operating system).

[0060] Hardware configuration differences: A multi-core MCU (e.g., dual-core Cortex-M33) is used, with core 0 running decision-making tasks and core 1 running display tasks; physical buttons are connected to core 0 via GPIO interrupts, and the touchscreen is connected to core 1 via an I2C interface. Tasks communicate via shared memory and message queues, replacing the UART serial port in Example 1.

[0061] Workflow: The display task (core 1) captures touch events, maintains an event counting semaphore and a single-element buffer, and continues the above operations during animations or transitions; the display task does not make any predictions or decisions about whether touch events will trigger interface transitions. The decision task (core 0) monitors semaphore changes through shared memory. When a change in semaphore value is detected, it reads event information from the buffer. At the same time, the decision task directly captures physical key press events. The decision task acts as the sole decision node for interface switching. It determines whether switching is allowed based on the global interface state machine and preset switching rules. If allowed, it sends a switching message (containing the target interface ID) to the display task via a message queue. After receiving the switching message, the display task performs the same secondary verification as in the first embodiment (animation status, interface jump permission, etc.). After the verification is successful, the graphics library is called to perform the interface switching.

[0062] In this embodiment, inter-task communication replaces serial communication, but the core centralized decision-making, semaphore queuing, and secondary verification mechanisms are exactly the same.

[0063] Alternative implementation methods The technical solutions described in this invention are not limited to the two embodiments described above. For example: The communication interface between the master and slave can be SPI, I2C or a custom parallel bus, as long as it can transmit data frames. The interface between the touchscreen and the slave device is not limited to I2C; it can use SPI or USB, etc. Physical buttons can be connected to the host via an I2C expansion chip, and the host will still capture the data uniformly. In a dual-MCU architecture, in addition to polling, the master can also actively notify the master via an additional interrupt line to monitor semaphores.

[0064] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A centralized decision-making master-slave screen interface control method, characterized in that, include: Touch events are captured from the device side, and an event counter semaphore is maintained. Each time a touch event is captured, the semaphore is incremented by one, and the event information is stored in the buffer to overwrite the old data. The above-mentioned capture, semaphore increment and buffer write operations are continuously performed during the execution of interface animation or switching on the slave device. The host side directly receives physical button events; The device does not make any predictions or decisions regarding whether a touch event will trigger a screen switch. The host monitors changes in the event counting semaphore, and when a change in the semaphore value is detected, it reads the event information from the slave's buffer. The host side acts as the interface switching decision node. Based on the global interface state machine and preset switching rules, it independently determines whether switching is allowed for each read event. If allowed, it generates a switching command and sends it to the slave side. If not allowed, no instruction will be sent; After receiving the switching instruction from the slave device, it first checks whether the current state meets the switching conditions. If the verification passes, it performs the interface switching. If no instruction is received or the verification fails, the slave device maintains the current interface unchanged and does not actively initiate any interface jump.

2. The method according to claim 1, characterized in that, The event counting semaphore is maintained by the slave side, and the master side monitors its changes through polling or interruption. When the master side detects that the semaphore value is different from the previously recorded reference value, it triggers an event read operation. After the master side completes an event read, it decrements the semaphore by one, or updates the reference value recorded by the master side to the current semaphore value.

3. The method according to claim 1, characterized in that, The cache is a single-element cache that only stores the event information of the most recent touch event. When a new touch event occurs, the latest event information is directly written into the cache to overwrite the old data, and no event queue is maintained. The slave device does not actively clear the cache. After the master device reads the event information in the cache each time, the contents of the cache remain unchanged until the next touch event overwrites it.

4. The method according to claim 1, characterized in that, The communication link between the host and slave sides uses a UART serial port; the communication frame format includes, in order: a one-byte frame header, a one-byte instruction type, a variable-length data field, and a one-byte checksum; the switching instruction is encapsulated using this frame format, the instruction type field identifies it as an interface switching instruction, and the data field carries the target interface identifier; after the slave side receives the complete frame, it first calculates the checksum of the data excluding the frame header and compares it with the received checksum, and if the comparison is successful, it parses and executes the message.

5. The method according to claim 4, characterized in that, After the host side issues a switching command, it does not wait for confirmation from the slave side, nor does it retransmit the command. When the slave side fails the verification, or when the verification passes but the current state does not meet the switching conditions, it silently discards the command, does not send any negative response or error feedback, and maintains the original interface unchanged.

6. The method according to claim 1, characterized in that, The physical buttons are directly connected to one or more GPIO interfaces on the host side. The host side captures button events via rising or falling edge interrupts, and button debouncing is performed by the host side. The touch screen is connected to the slave side via I2C or SPI interfaces. The slave side obtains touch coordinates via polling or interrupts, and converts the coordinates into a preset touch area ID as event information and stores it in the buffer.

7. The method according to claim 1, characterized in that, The verification of whether the current state meets the switching conditions includes: determining whether the slave device is currently executing a graphics library animation interface call or an interface switching action; if an animation is playing or a switching is in progress, the currently received switching instruction is rejected and the instruction is discarded.

8. The method according to claim 7, characterized in that, Also includes: Determine whether the currently displayed interface on the slave side allows jumping to the target interface indicated by the switching command; the slave side has a pre-stored interface jump permission table or a set of rules, recording the set of target interfaces allowed to jump to under each source interface; if the target interface is not in the permission set, the execution is refused; if the target interface identifier exceeds the range of interfaces supported by the slave side, the execution is refused.

9. The method according to claim 1, characterized in that, The host side maintains a global interface state machine, which records the current interface identifier and the set of allowed target interfaces for each interface. When a key event is received or touch event information is read, the host side determines whether switching is allowed by looking up a table based on the current interface identifier and event content. If permitted, the host updates its own recorded current interface identifier to the target interface while sending the switching command.

10. The method according to claim 1, characterized in that, The operation of continuously capturing touch events on the slave side during the execution of interface animation or switching is a non-blocking operation; the coordinate scanning of the touch screen is located in an interrupt service routine or a high-priority task, and is not blocked or delayed due to the rendering of the graphics library or animation delay; when the slave side is in the waiting delay stage of animation playback, the touch interrupt is still responded to, and the semaphore increment and buffer write operations are still executed.

11. The method according to claim 1, characterized in that, The event information includes a touch area ID; a static mapping table of touch screen coordinate ranges to area IDs is pre-stored on the device side, with each area ID corresponding to a rectangular area on the screen; after capturing the touch coordinates, the area ID is obtained by traversal or calculation using a formula; If the coordinates fall within an invalid area, the touch event is ignored, and semaphore increment and cache writing are not performed.

12. The method according to claim 1, characterized in that, The method is applied to an embedded human-machine interaction device with at least one physical button and a touch screen; the device is any one of a smart home central control screen, a small home appliance control panel, an industrial human-machine interface, or a consumer electronics product with a screen; the host side and the slave side each correspond to two independent microcontrollers, or are integrated on different cores of the same multi-core microcontroller.

Images