Programmable key interaction system and method capable of being known in power failure
By generating a function mapping table and displaying image data through the main control system, and combining programmable button modules, non-volatile memory and e-ink screen, the problems of traditional physical button functions being fixed and labels disappearing after power failure are solved. This enables the visualization of button functions after power failure, improving the adaptability of the device and the user experience.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-25
- Publication Date
- 2026-03-31
AI Technical Summary
Traditional physical buttons have fixed function labels that cannot be dynamically adjusted, resulting in poor equipment adaptability and scalability. Furthermore, the function labels disappear after the main control system is powered off, affecting equipment operation and safety.
The main control system generates a function mapping table and displays image data. Combined with a programmable button module, non-volatile memory, and electronic ink screen, the button functions remain visible even after power failure.
Ensure that button functions remain visible after power failure, reducing learning costs, preventing accidental operation, and improving device interaction flexibility and reliability.
Smart Images

Figure CN121764339A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of human-computer interaction technology, and in particular to a programmable button interaction system and method that is aware of power failure. Background Technology
[0002] Traditional physical buttons typically have their function labels permanently affixed to the device surface via silkscreen printing or engraving, such as operation symbols like "Confirm" or "Return." This fixed design means that button functions cannot be adjusted to meet actual needs after the product leaves the factory, severely limiting the device's adaptability and expandability. In complex devices involving multi-scenario operations, users must memorize the function changes of the same button in different modes. For example, in industrial control panels or medical equipment, button functions dynamically switch according to system status, which significantly increases the learning difficulty and easily leads to misoperation.
[0003] Existing technologies attempt to use small displays, such as OLED screens, to dynamically update button labels to improve interactive flexibility. However, these display solutions rely on a continuous power supply to maintain image display. Once the main control system loses power or enters a deep sleep state, the screen immediately becomes unusable, and all function labels disappear instantly. At this time, users cannot recognize the operation content corresponding to the buttons, causing the device to completely lose its interactive capability in emergency power outage scenarios, which may cause operational interruption or safety hazards, especially in mission-critical environments. For programmable button systems with dynamically changeable functions, the disappearance of function labels after a power outage will completely negate its core advantage (flexibility), making it even inferior to traditional buttons with fixed labels. The above defects highlight the core problem of the unknowable function labels in traditional solutions during power outage scenarios, urgently requiring a solution that can maintain the visibility of button functions after the main control system loses power. Summary of the Invention
[0004] The purpose of this application is to propose a programmable key interaction system and method that is aware of power failure, which has the advantage of keeping the key function indicators visible even after the main control system is powered off, thereby avoiding operation interruption or safety hazards.
[0005] To address the aforementioned technical problems, embodiments of this application provide a programmable key interaction system that is aware of power failure, comprising: The main control system is used to generate a function mapping table of physical buttons and display image data according to the current scene. A programmable keypad module, communicatively connected to the main control system, includes: The processor receives and stores the function mapping table and the display image data, and detects key events after the main control system is powered off. A non-volatile memory, connected to the slave processor, is used to store the function mapping table and the display image data; A physical button array, connected to the slave processor, is used to receive user press operations; An electronic ink screen, connected to the slave processor, is used to display function identifiers corresponding to each of the physical buttons in the physical button array, and to maintain the display state of the function identifiers after the main control system is powered off; The slave processor is configured to respond to the triggering operation of the physical key array according to the function mapping table stored in the non-volatile memory after the main control system is powered off.
[0006] To address the aforementioned technical problems, embodiments of this application provide a programmable button interaction method that is aware of power failure, comprising: The main control system generates a function mapping table and display image data of physical buttons based on scene switching. The function mapping table includes at least one button ID and function code. The electronic ink screen is updated and displayed according to the displayed image data, so that the electronic ink screen displays the function identifiers corresponding to each button ID; After the main control system is powered off, the trigger events of the physical button array are monitored; If the physical button is detected to be triggered, the function code corresponding to the physical button is queried and used as the target function code; Execute the operation corresponding to the target function code or store the target function code; When the stored target function code exists and the main control system is powered on again, the stored target function code is reported to the main control system.
[0007] This invention provides a programmable button interaction system and method with power-off detection capability. The method includes: a main control system for generating a function mapping table and display image data for physical buttons based on the current scene; a programmable button module communicatively connected to the main control system, including: a slave processor for receiving and storing the function mapping table and the display image data, and detecting button events after the main control system is powered off; a non-volatile memory connected to the slave processor for storing the function mapping table and the display image data; a physical button array connected to the slave processor for receiving user press operations; and an e-ink screen connected to the slave processor for displaying function identifiers corresponding to each physical button in the physical button array, and maintaining the display state of the function identifiers after the main control system is powered off; wherein the slave processor is configured to respond to trigger operations of the physical button array according to the function mapping table stored in the non-volatile memory after the main control system is powered off. This invention generates a function mapping table and display image data through a main control system. The programmable key module maintains the display of function identifiers and key detection via an e-ink screen after power failure, solving the problem of unknowable function identifiers after power failure in traditional solutions. It has the advantage of maintaining the visibility of key function identifiers even after the main control system is powered off. Furthermore, by introducing an e-ink screen as the display medium and utilizing its bistable characteristics, the function identifiers can be continuously displayed without power consumption after a single refresh. Finally, by persistently storing the function mapping relationship using non-volatile memory, it ensures that the slave processor can still correctly interpret the key presses even after power failure. Attached Figure Description
[0008] To more clearly illustrate the solutions in this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0009] Figure 1 This is a schematic diagram of a programmable button interaction system that is known when power is off, provided in an embodiment of this application.
[0010] Figure 2 This is a schematic diagram of the hardware architecture of a programmable button interaction system that is known when power is off, provided in an embodiment of this application.
[0011] Figure 3 This is a flowchart illustrating the implementation of the programmable button interaction method with power-off awareness provided in this application embodiment; Figure 4 This is a software workflow diagram provided in an embodiment of this application; Figure 5This is a flowchart illustrating the implementation of the first sub-process in the programmable button interaction method with power failure detection provided in this application embodiment; Figure 6 This is a flowchart illustrating the implementation of the second sub-process in the programmable button interaction method with power failure detection provided in this application embodiment. Detailed Implementation
[0012] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein in the specification of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application; the terms "comprising" and "having," and any variations thereof, in the specification, claims, and foregoing drawings of this application, are intended to cover non-exclusive inclusion. The terms "first," "second," etc., in the specification, claims, or foregoing drawings of this application are used to distinguish different objects, not to describe a particular order.
[0013] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.
[0014] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.
[0015] Please refer to Figure 1 and Figure 2 This application provides an embodiment of a programmable keypad interaction system that is aware of power failure. Figure 2 This is a schematic diagram of the hardware architecture of a programmable button interaction system that is known when power is off, provided in an embodiment of this application.
[0016] like Figure 1 As shown, the programmable button interaction system that is known even when the power is off in this embodiment includes: a main control system 10 and a programmable button module 20, wherein: The main control system 10 is used to generate a function mapping table and display image data of physical buttons according to the current scene; the programmable button module 20 is communicatively connected to the main control system and includes: a slave processor 201, used to receive and store the function mapping table and the display image data, and to detect button events after the main control system is powered off; a non-volatile memory 202, connected to the slave processor, used to store the function mapping table and the display image data; a physical button array 203, connected to the slave processor, used to receive user pressing operations; and an e-ink screen 204, connected to the slave processor, used to display function identifiers corresponding to each physical button in the physical button array, and to maintain the display state of the function identifiers after the main control system is powered off. The slave processor is configured to respond to the triggering operation of the physical key array according to the function mapping table stored in the non-volatile memory after the main control system is powered off.
[0017] Traditional physical buttons typically have fixed functions, with their function markings permanently affixed to the device surface via silkscreen printing or engraving. This design means that button functions cannot be changed after the product leaves the factory, lacking necessary flexibility. In some complex devices, users need to memorize the different functions of the same button in different modes, which not only increases the learning curve but also easily leads to misoperation. Furthermore, while existing technologies utilize small screens (such as OLEDs) to dynamically display button functions, these screens require continuous power. Once the device is powered off, all function markings disappear, and users will be unable to recognize the button functions, thus affecting the normal operation of the device.
[0018] To address this issue, this application proposes a programmable button interaction system that is aware of power failures, aiming to solve the problems of fixed functions, inability to dynamically change, and loss of function identifiers after power failure in traditional physical buttons. This system, by introducing a main control system 10, can dynamically generate a function mapping table and display image data for the physical buttons based on the current scenario, thereby achieving flexible configuration of button functions. Simultaneously, the programmable button module 20 is communicatively connected to the main control system 10. Its internal slave processor 201 can continue to detect button events after the main control system 10 is powered off, and uses non-volatile memory 202 to store the function mapping table and display image data, ensuring that data is not lost after power failure. Furthermore, the system is equipped with an e-ink screen 204 to display the function identifiers corresponding to each physical button in the physical button array 203. Utilizing the characteristics of the e-ink screen 204, the function identifiers remain displayed even in a power failure state, thus ensuring that users can clearly identify and operate the buttons under any circumstances.
[0019] For ease of understanding, the following explains some key terms in this embodiment: Main control system 10: This typically refers to the main processing unit in the equipment, responsible for overall logic control, data processing, and task scheduling. In this system, its main function is to generate and manage the function mapping table of physical buttons and the corresponding display image data based on the current operating scenario or user requirements.
[0020] Programmable button module 20: This is an independent hardware module that communicates with the main control system 10 and is specifically responsible for the interactive management and display updates of physical buttons. Its core function is to dynamically change the button functions and display content based on the received data.
[0021] Processor 201: The microcontroller or microprocessor inside the programmable button module 20. Its main responsibilities are to receive and store the function mapping table and display image data sent by the main control system 10, drive the e-ink screen 204 to display, and independently detect the trigger events of the physical buttons after the main control system 10 is powered off.
[0022] Non-volatile memory 202: A storage medium that retains its contents even after a power outage, such as flash memory or EEPROM. In this system, it is used to persistently store the function mapping table and display image data to ensure that the button functions and display indicators can still be accessed and used from the processor 201 after the main control system 10 is powered off.
[0023] Physical button array 203: A collection of multiple physical buttons used to receive user press operations. These buttons typically have mechanical feedback, providing users with an intuitive interactive experience.
[0024] E-ink screen 204: A bistable display technology characterized by its ability to maintain the display state without continuous power supply after the content is refreshed. In this system, it is used to display function icons corresponding to physical buttons, thus providing visual feedback even in the event of a power outage.
[0025] Function mapping table: A data structure that defines the correspondence between physical buttons and specific function codes. It may contain information such as the button's unique identifier, its corresponding operation function, and display method.
[0026] Display image data: Graphical data used to present functional identifiers on the e-ink screen 204. This data can be bitmap, vector, or other image formats that can be resolved by the e-ink screen 204 driver.
[0027] Key events: refer to the signals or state changes generated when a user operates a physical key, such as key press, key release, long press, etc.
[0028] Function identifier: The text, icon or graphic displayed on the e-ink screen 204 to indicate the current function of the corresponding physical button.
[0029] This application provides a programmable button interaction system that is aware of power failure. The system includes a main control system 10, which generates a function mapping table for physical buttons and display image data based on the current scenario. Specifically, the main control system 10 can preset multiple operating scenarios, such as "Home Mode," "Audio-Visual Mode," "Office Mode," "Entertainment Mode," or "Settings Mode." When the system enters a specific scenario, the main control system 10 retrieves or dynamically calculates the button function configuration matching that scenario from its internal memory. For example, in "Office Mode," a button might be mapped to the "Save Document" function, while in "Entertainment Mode," the same button might be mapped to the "Play / Pause" function. These function configurations are organized in the form of a function mapping table, and corresponding display image data is generated to display "Save" or "Play" indicators next to the buttons.
[0030] The programmable keypad module 20 is communicatively connected to the main control system 10. This module, as an independent subsystem, is responsible for the physical interaction and display management of the keys. Communication between the main control system 10 and the programmable keypad module 20 can employ various standard interfaces, such as a serial peripheral interface (SPI) or an I2C interface, to ensure data transmission stability and efficiency.
[0031] The programmable button module 20 includes a slave processor 201. This slave processor 201 receives and stores the function mapping table and display image data sent by the main control system 10. For example, the slave processor 201 can be configured with a receive buffer. When the main control system 10 sends data, the data is first written to this buffer, and then parsed and stored by the slave processor 201. Furthermore, the slave processor 201 also has the ability to detect button events after the main control system 10 is powered off. Specifically, the slave processor 201 can be configured in a low-power mode, sensing the button press state by monitoring the level changes of the physical button array 203. Even when the main control system 10 is not in operation, the slave processor 201 can still maintain a response to button events.
[0032] Non-volatile memory 202 is connected to slave processor 201 and is used to store function mapping table and display image data. As one implementation, non-volatile memory 202 can be embedded flash memory (eFlash) or external serial flash memory (SPIFlash). When slave processor 201 receives the function mapping table and display image data sent by master control system 10, it writes this data into non-volatile memory 202 for persistent storage. Therefore, even if the system is completely powered off, this critical data will not be lost, ensuring that the system can be restored to its state before the power outage after power is restored.
[0033] The physical button array 203 is connected to the slave processor 201 to receive user press operations. The physical button array 203 can consist of multiple independent mechanical buttons, each of which is connected to a general purpose input / output (GPIO) pin of the slave processor 201 via a wire. When a user presses a button, the corresponding GPIO pin level changes. The slave processor 201 detects this change through polling or interrupt mechanisms, thereby identifying the specific button operation.
[0034] The e-ink screen 204 is connected to the slave processor 201 and is used to display the function labels corresponding to each physical button in the physical button array 203. The driving circuit of the e-ink screen 204 is connected to the slave processor 201. The slave processor 201 generates driving signals based on the stored display image data to control the refreshing of the pixels of the e-ink screen 204. For example, the e-ink screen 204 can be a whole display area, with display areas corresponding to each physical button divided by software, and the corresponding function labels displayed in these areas. Due to the bistable nature of the e-ink screen 204, once the image refresh is complete, the displayed content can remain unchanged for a long time even if the power supply is disconnected.
[0035] The power-off responsive programmable button interaction system of this application dynamically generates a button function mapping table and display image data through the main control system 10. The slave processor 201 and non-volatile memory 202 in the programmable button module 20 maintain function identification and button event detection even after power failure. This effectively solves the problems of fixed functions in traditional physical buttons, the inability to dynamically change them, and the disappearance of function identification after power failure in existing dynamic display schemes. Therefore, users do not need to memorize complex function correspondences, reducing learning costs and the risk of misoperation. Furthermore, even when the device unexpectedly loses power or enters a low-power state, the button functions can still be clearly identified and operated, greatly improving the flexibility, reliability, and user experience of device interaction.
[0036] In one specific embodiment, the main control system 10 adopts a high-performance application processor (such as the ARM Cortex-A series) and runs a Linux or RTOS operating system. It has peripheral interfaces such as Wi-Fi / Bluetooth module, audio codec, and sensor interface, and communicates with the slave processor 201 through a high-speed serial interface (such as SPI or USB).
[0037] The processor 201 utilizes an ultra-low-power MCU (ESP32-S3 or STM32L5 series). The deep sleep mode operating current of the processor 201 is < 10μA. The processor 201 incorporates non-volatile memory 202 (Flash), supports multiple GPIOs and touch-sensing interfaces, and can integrate an e-paper display controller. Furthermore, the processor 201 features an independent power supply design: powered by a 3.3V LDO, with support for a 0.1F supercapacitor as backup power.
[0038] In some of the embodiments described above in this application, a processor 201 is proposed to detect key events after power failure. However, in its implementation, there is a lack of a dynamic update mechanism for the function mapping table and display image data, an operation execution or code storage mechanism after the key trigger event, and an event reporting mechanism after power-on. This results in incomplete operation of the system after power failure, data that cannot be recovered, or loss of user events.
[0039] In this regard, this application further proposes that the processor 201 is also configured to, after receiving an update instruction sent by the main control system 10, store the function mapping table and display image data in the non-volatile memory 202 and drive the electronic ink screen 204 to update the display; after the main control system 10 is powered on again, report the stored function code to the main control system 10.
[0040] Specifically, the technical feature of "after receiving the update command sent by the main control system 10, storing the function mapping table and display image data in the non-volatile memory 202, and driving the e-ink screen 204 to update the display" aims to ensure that the programmable button module 20 can promptly synchronize and persist the latest function mapping table and display image data when the main control system 10 updates its function configuration, and simultaneously update the user interface. One implementation is that after receiving the update command sent by the main control system 10, the slave processor 201 first performs an integrity check on the received function mapping table and display image data, for example, by comparing CRC checksums or hash values, to ensure error-free data transmission. After successful verification, the slave processor 201 writes this data to a preset storage area in the non-volatile memory 202. After writing, the slave processor 201 sends an acknowledgment signal to the main control system 10. Subsequently, the slave processor 201 parses the new display image data and generates corresponding waveform data according to the driving protocol of the e-ink screen 204, driving the e-ink screen 204 to perform partial or global refresh to display the latest function identifiers. Another implementation involves the processor 201 employing a dual-memory mechanism upon receiving an update command. Specifically, the non-volatile memory 202 maintains two memory regions: one currently active and one awaiting update. The processor 201 writes the new function mapping table and display image data to the region awaiting update, and after writing, updates an indicator bit to mark the region awaiting update as active, while simultaneously marking the original active region as the old data region. This approach ensures that even if an exception occurs during the update process, the system can roll back to the previous valid configuration. After the data is written and the active region is switched, the processor 201 immediately drives the e-ink screen 204 to update the display, ensuring that the user interface remains consistent with the latest function configuration.
[0041] Furthermore, after the main control system 10 is powered off, the slave processor 201 detects the trigger event of the physical button array 203 and executes the corresponding operation or stores the function code in the function mapping table stored in the non-volatile memory 202. This describes how the slave processor 201 continues to respond to user operations and executes corresponding actions or records events according to the preset function mapping table in the special case of the main control system 10 being powered off. One implementation is that after detecting a power failure signal from the main control system 10 (e.g., by monitoring the power supply status of the main control system 10 or receiving a power-off command from the main control system 10), the slave processor 201 enters a low-power mode, but still maintains continuous monitoring of the physical button array 203. When a physical button is detected to be triggered, the slave processor 201 reads the function mapping table entry corresponding to the button ID from the non-volatile memory 202. According to the function code type defined in the entry, if the function code indicates a locally executable operation (e.g., switching the display mode of the programmable button module 20 itself, adjusting the backlight brightness, etc.), the slave processor 201 will directly execute the operation. If the function code indicates an operation requiring processing by the main control system 10, the slave processor 201 stores the function code in a specific area of the non-volatile memory 202, waiting for the main control system 10 to power on again before processing. Alternatively, the slave processor 201 periodically scans the state of the physical button array 203 after the main control system 10 is powered off. To save power, an interrupt wake-up mechanism can be used, meaning the slave processor 201 is only woken up by an interrupt to process the data when a physical button is pressed. Once a button trigger is detected, the slave processor 201 looks up the corresponding function code according to the function mapping table stored in the non-volatile memory 202. The function code can contain an operation type field, such as "local execution" or "remote reporting." If the operation type is "local execution," the slave processor 201 calls the corresponding internal processing function. If the operation type is "remote reporting," the slave processor 201 packages the button ID, function code, and trigger time information and stores it in a circular buffer or queue, also located in the non-volatile memory 202, to ensure data is not lost after power failure.
[0042] The technical feature of "reporting the stored function codes to the main control system 10 after the main control system 10 is powered on again" aims to ensure that after the main control system 10 is powered on and operating normally, the programmable button module 20 can promptly notify the main control system 10 of user operation events that occurred during the power outage, so as to achieve seamless operation and context recovery. One implementation is that after the processor 201 detects that the main control system 10 is powered on again (e.g., by monitoring the power restoration of the main control system 10 or receiving a start signal from the main control system 10) and completes its self-test, it actively checks whether there are stored function codes in the non-volatile memory 202. If so, the processor 201 sends these function codes one by one to the main control system 10 through its communication interface with the main control system 10 (e.g., SPI, I2C, UART, etc.). After receiving these function codes, the main control system 10 parses and processes them according to its internal logic, such as simulating the corresponding operations performed by the user before the power outage, or updating its internal state machine. After successfully reporting and receiving confirmation from the main control system 10, the slave processor 201 clears the reported function codes from the non-volatile memory 202. Alternatively, after power-on and initialization, the main control system 10 proactively sends a query command to the slave processor 201 to inquire about any unprocessed events. Upon receiving the query command, the slave processor 201 checks the queue of function codes stored in the non-volatile memory 202. If the queue is not empty, the slave processor 201 sends all function codes in the queue (or sends them in batches) to the main control system 10. To ensure reliable data transmission, a communication protocol with a retransmission mechanism can be used. After processing the reported function codes, the main control system 10 sends a clear command to the slave processor 201, instructing it to clear the reported function codes. This method ensures that the main control system 10 only receives data when it is ready to process events, avoiding data overflow or insufficient processing.
[0043] This application effectively solves the problems of incomplete operation, unrecoverable data, and lost user events in the programmable key interaction system after the main control system 10 is powered off. Specifically, after receiving the update command sent by the main control system 10, the slave processor 201 can promptly store the latest function mapping table and display image data in the non-volatile memory 202 and drive the e-ink screen 204 to update the display. This ensures that even if the main control system 10 is powered off, the programmable key module 20 can still work based on the latest configuration information, avoiding the problem of outdated or inconsistent data, while ensuring the real-time performance and accuracy of the user interface. Furthermore, after the main control system 10 is powered off, the slave processor 201 can still continuously detect the trigger events of the physical key array 203. Once a trigger is detected, the slave processor 201 can flexibly choose to execute local operations or store function codes according to the function mapping table stored in the non-volatile memory 202. This mechanism ensures that the user's operations during the power outage of the main control system 10 are not missed. For some key local functions, the user can still operate; for events that need to be processed by the main control system 10, they can be reliably stored. Furthermore, after the main control system 10 is powered on again, the processor 201 can report the function codes stored during the power outage to the main control system 10. This enables the main control system 10 to restore the operating context and process user events that occurred during the power outage, thereby achieving seamless operation transition, greatly improving system reliability and user experience, and avoiding problems such as loss of user operations or inconsistent system states caused by power outages.
[0044] In some of the embodiments described above in this application, an electronic ink screen 204 is proposed to display button function indicators after power failure. However, in its implementation, if the screen layout is not appropriate, the indicators may not match the button positions, making it difficult for users to accurately identify the button functions, thereby reducing the availability and reliability of the system.
[0045] In response, this application further proposes an e-ink screen 204 layout as either an integrated main screen or a distributed sub-screen system. The integrated main screen is divided into several label areas, each label area being aligned with one of the physical buttons. In the distributed sub-screen system, each physical button is assigned an e-ink sub-screen.
[0046] Specifically, regarding the layout of the e-ink screen 204, an integrated main screen or a distributed sub-screen system can be adopted. An integrated main screen refers to a single, relatively large e-ink display screen whose display area covers multiple physical buttons. The advantage of this layout is the integrity of the display area and the simplicity of the design, allowing for more flexible interface design. For example, the integrated main screen can be a complete e-ink display panel, large enough to cover the entire physical button array 203, or an e-ink display screen with a specific shape whose display area matches the overall outline of the physical button array 203. A distributed sub-screen system refers to configuring a small e-ink display screen independently for each physical button. The advantage of this layout is that the function label of each button can be more closely integrated with the button itself, providing a more intuitive visual correspondence. For example, an independent e-ink sub-screen can be integrated above or inside each physical button, or an e-ink sub-screen can be placed next to each physical button.
[0047] When using an integrated main screen layout, to ensure consistency between function icons and corresponding physical buttons, the display area of the integrated main screen is logically or physically divided into multiple independent label areas. Each label area is specifically used to display the function icon of a physical button. To achieve precise user interaction, these label areas are strictly aligned spatially with their corresponding physical buttons. For example, the pixel coordinates of each label area can be precisely calculated and defined using software algorithms, ensuring that its center point or boundary coincides with or is closely adjacent to the center point or boundary of the corresponding physical button in physical space; alternatively, physical positioning structures can be set below or above the integrated main screen to assist users in associating buttons with the label areas on the screen.
[0048] When using a distributed sub-screen system layout, each physical button is equipped with a dedicated e-ink sub-screen. This one-to-one configuration ensures a direct correspondence between function labels and physical buttons, eliminating ambiguity for users during identification. For example, a small e-ink sub-screen can be directly embedded into the pressing surface of the physical button, making the button itself a display unit; or, the e-ink sub-screen can be closely installed above, below, or to the side of each physical button, forming a visually inseparable whole.
[0049] This application effectively solves the problem of mismatch between the displayed labels on the e-ink screen 204 and the physical button positions, significantly improving the accuracy of user interaction and the reliability of the system. Specifically, whether using an integrated main screen with precisely divided label areas aligned with the physical buttons, or using a distributed sub-screen system with an independent e-ink sub-screen for each physical button, it ensures that users can clearly and intuitively identify the function labels of each button. This precise correspondence avoids user misoperation due to misalignment of labels and buttons, reduces the user's learning cost, and especially after the main control system 10 is powered off, the e-ink screen 204 can still display the function labels, allowing users to continue operating accurately, thus ensuring the availability of the system and the user experience under various working conditions.
[0050] In some of the embodiments described above in this application, a function mapping table is proposed to define button functions and displays. However, in its implementation, the function mapping table lacks detailed field definitions and cannot support diverse triggering conditions, resulting in insufficient system interaction flexibility and users being unable to adapt to button operation needs in complex scenarios.
[0051] In this regard, this application further proposes that the fields of the function mapping table stored in the non-volatile memory 202 include: button ID, function code, display type, display image data, and trigger condition; wherein the trigger condition is at least one of single click, long press, combination key, timing key, system mode, and time condition.
[0052] Specifically, the button ID is a unique identifier used to uniquely identify each physical button in the physical button array 203 of the programmable button module 20. For example, the button ID can be an integer value, such as 1, 2, 3, etc., or a string, such as "KEY_UP", "KEY_DOWN", etc., so that the processor 201 can accurately identify which physical button the user pressed. The function code is an instruction or data associated with a specific button operation, which defines the specific operation that the system should perform when the button is triggered. For example, the function code can be a predefined enumeration value, such as "VOLUME_UP", "POWER_OFF", or a pointer to a specific processing function, or a command string to be executed. The display type indicates how the function identifier corresponding to the physical button is presented on the e-ink screen 204. For example, the display type can be specified as plain text display, icon display, text and icon combination display, or a specific graphic layout mode. The display image data is the actual image information used to render the function identifier on the e-ink screen 204. For example, the displayed image data can be bitmap data (such as monochrome BMP format), vector graphics data, or font data used to generate specific characters or icons. The trigger condition defines the specific user action or system state required for a key event to be recognized and its function code executed. The trigger condition can include various types, such as: A single click refers to a brief press and release of a physical button by the user, typically lasting less than a preset threshold, such as 200 milliseconds. A long press refers to a user continuously pressing and holding a physical button for a duration exceeding a preset threshold, such as 500 milliseconds. A combination of buttons refers to a user simultaneously pressing two or more specific physical buttons, or sequentially pressing multiple physical buttons within a very short time interval.
[0053] Sequence buttons refer to multiple physical buttons pressed in a preset order, such as "up-up-down-down". System mode refers to the button's function being activated only when the system is in a specific operating mode (such as "playback mode", "edit mode", or "settings mode"). Time condition refers to the button's function being effective only during a specific time period (such as "9:00 AM to 5:00 PM") or meeting specific time logic (such as "within 10 minutes after power-on").
[0054] This application embodiment solves the problem of insufficient interactive flexibility by specifically defining the field structure of the function mapping table, enhancing the system's adaptability to diverse user inputs. The function mapping table fields include a key ID, ensuring that each physical key has a unique identifier, facilitating accurate lookup and mapping of corresponding functions from the processor 201, thereby effectively avoiding misoperation. The function code defines the specific operation or task executed by the key, enabling the processor 201 to still execute predetermined functions based on the function codes stored in the non-volatile memory 202 even after the main control system 10 is powered off, ensuring the system's power failure awareness. The display type specifies the presentation method of the function identifier, ensuring that the display on the e-ink screen 204 is consistent with user operation, improving the user experience. The display image data provides image information, supporting the updated display on the e-ink screen 204, ensuring that the function identifier remains visible after power failure. Furthermore, the triggering conditions include at least one of the following: single click, long press, key combination, time sequence key, system mode, and time condition. This allows the system to respond to a variety of complex input methods, such as key combination or time-dependent operations, thereby greatly expanding the interaction scenarios, improving the diversity and flexibility of user operations, and enabling users to perform more refined and personalized operations according to actual needs.
[0055] In some of the embodiments described above in this application, a processor 201 and a non-volatile memory 202 are proposed to detect key events and store data after the main control system 10 is powered off. However, in its implementation, if the processor 201 and the non-volatile memory 202 stop working due to power failure, key detection and function code storage after power failure cannot be realized, resulting in user operations not being recorded or responded to.
[0056] In this regard, this application further proposes that after the main control system 10 is powered off or enters deep sleep mode, the processor 201 and the non-volatile memory 202 maintain power supply. The programmable button module 20 also includes an independent backup power supply; The independent backup power supply is used to provide sustaining power to the slave processor 201, the non-volatile memory 202, and the e-ink screen 204 after the main control system 10 is powered off or enters deep sleep mode.
[0057] Specifically, the condition "after the main control system 10 is powered off or enters deep sleep mode" can be implemented in several ways, including but not limited to the following: One method is to continuously monitor the power status of the main control system 10 through the internal power management unit (PMU). When the power supply voltage of the main control system 10 is detected to be lower than a preset threshold, or when the main control system 10 sends a command to the PMU to enter deep sleep mode, it is determined that the main control system 10 has been powered off or entered deep sleep mode. Another method is to continuously monitor the communication bus activity or specific heartbeat signals between the main control system 10 and the programmable button module 20 from the processor 201. If no activity signal from the main control system 10 is detected within a preset time, it is considered that the main control system 10 has been powered off or entered deep sleep mode.
[0058] Regarding the provision of sustaining power to the processor 201, non-volatile memory 202, and e-ink screen 204, the implementation methods may include, but are not limited to, the following: One method is to configure independent backup power supplies, such as small lithium batteries or supercapacitors, for the processor 201, non-volatile memory 202, and e-ink screen 204. When the main control system 10 is powered off, the independent backup power supply automatically switches to backup power supply mode to ensure the continuous operation of the processor 201 and non-volatile memory 202. Another method is to design the processor 201 and non-volatile memory 202 as ultra-low power components during system design, and maintain only minimal power supply to these two components when the main control system 10 is powered off or in deep sleep mode, for example, by supplying power through a low-power branch of the main power supply, thereby ensuring their basic functions without consuming excessive energy.
[0059] Through the above technical solution, when the main control system 10 is powered off or enters a deep sleep state, the slave processor 201 can still maintain normal operation and continuously monitor the trigger events of the physical button array 203. Simultaneously, the non-volatile memory 202 remains powered, ensuring that the slave processor 201 can reliably store the function codes corresponding to the key operations performed by the user during the power outage; the e-ink screen 204 also remains powered. When the main control system 10 is powered on again and resumes normal operation, the slave processor 201 can report these function codes stored during the power outage to the main control system 10 for processing. This effectively solves the problem that user operations cannot be recorded or responded to after the main control system 10 is powered off, greatly improving the availability and user experience of the programmable key interaction system, and ensuring the continuity and reliability of the interactive functions.
[0060] In some of the embodiments described above in this application, a function mapping table is proposed to define button functions. However, during its implementation, the function mapping table may not be able to be dynamically adjusted according to the button scenario and mode, which limits the adaptability and flexibility of the system.
[0061] In this regard, this application further proposes that the function mapping table is dynamically programmed according to the scenario and mode of the button. That is, the function mapping table can be dynamically edited.
[0062] Specifically, the function mapping table is the core data structure defining the function, display content, and trigger conditions of each physical button in the physical button array 203. Its "dynamic programming" means that the content of this function mapping table is not fixed but can be updated or switched in real time according to specific conditions during system operation. This dynamism allows the button function definition to flexibly adapt to changes in the external environment or internal state. The "scenario" of the button typically refers to the macroscopic operating environment or application context of the device. For example, when the device is used as an in-vehicle entertainment system, the scenario could be "navigation mode," "music playback mode," or "telephone mode"; or "daytime mode" or "nighttime mode" defined based on external factors such as ambient light and geographical location. The "mode" of the button refers to the specific operating state or functional subset of the button in a specific scenario. For example, in the "music playback mode" scenario, the mode could be "volume adjustment mode," "song switching mode," or "playlist browsing mode"; it could also be a specific combination of operations set by the user according to personal preferences.
[0063] To achieve dynamic programming of the function mapping table, various methods can be employed. For example, the main control system 10 can generate or select different function mapping tables in real time based on the current operating status of the device, user selection, or changes in the external environment, and send them to the programmable button module 20 via the communication interface. After receiving a new function mapping table from the processor 201, it stores it in the non-volatile memory 202 and drives the e-ink screen 204 to update the display. Another implementation method is that the processor 201 pre-stores multiple function mapping tables for different scenarios and modes. When the processor 201 receives a scenario or mode switching command from the main control system 10, or based on certain conditions detected by the processor 201 itself (e.g., environmental changes detected by sensors), the processor 201 can select and activate a suitable mapping table from the pre-stored mapping tables.
[0064] In this embodiment, when the device's scenario or mode changes, the function mapping table can be automatically or on-demand updated, ensuring that the function definition of each physical button in the physical button array remains consistent with the current operating environment and user needs. For example, in an in-vehicle system, when switching from "navigation mode" to "music playback mode," the button functions and the function labels displayed on the e-ink screen are updated accordingly, avoiding the burden on users to memorize button functions in different modes and significantly reducing learning costs and the possibility of misoperation. Furthermore, even if the main control system is powered off, because the non-volatile memory stores the latest dynamically programmed function mapping table, users can still understand the current function of the buttons through the function labels displayed on the e-ink screen, further enhancing the system's "power-off awareness" capability and improving the overall adaptability and user experience of the system.
[0065] In another specific embodiment, a more intelligent, event-triggered, hierarchical power supply system is provided, including: the system defaults to an extremely low-power "listening state," with power supplied only from the processor and key detection circuitry. When a valid key press is detected from the processor, the system first reads the function code corresponding to the key press from the NVM, and then determines the next action based on a preset strategy: For simple commands (such as "power on / off"), the slave processor can directly control the power management IC and wake up the relevant functional modules of the main processor independently.
[0066] For complex instructions (such as "start a specific mode"), the processor then triggers the complete power-on process of the main system.
[0067] Technical benefits: This "gradual wake-up" mechanism avoids starting the entire system every time a button is pressed, achieving more precise and energy-efficient power management than simple timed power-off.
[0068] Please see Figure 3 and Figure 4 , Figure 3 This illustrates a specific implementation of a programmable key interaction method that is aware of power failure. Figure 4 This is a software workflow diagram provided in the embodiments of this application.
[0069] It should be noted that if substantially the same result is obtained, the method of this invention is not based on... Figure 3 Limited to the order of the processes shown, this method includes the following steps: S11: Obtain the function mapping table and display image data of the physical buttons generated by the main control system according to the scene switching, wherein the function mapping table includes at least one button ID and function code. S12: Drive the e-ink screen to update the display according to the display image data, so that the e-ink screen displays the function identifier corresponding to each button ID. S13: After the main control system is powered off, monitor the trigger events of the physical button array. S14: If a physical button trigger is detected, query the function code corresponding to the physical button as the target function code. S15: Execute the operation corresponding to the target function code or store the target function code. S16: When the stored target function code exists and the main control system is powered on again, report the stored target function code to the main control system.
[0070] Traditional physical buttons have fixed functions and permanently fixed labels, making it impossible to change their functions after the product leaves the factory. Users need to memorize button functions for different modes, resulting in high learning costs and a high risk of misoperation. Existing technologies use small screens to dynamically display button functions, but because the screen requires continuous power, the function labels disappear after power is off, rendering the buttons inoperable. To solve the problem of users being unable to operate the buttons after a power outage, and to provide dynamically programmable button functions to avoid high learning costs and misoperation, this application proposes a programmable button interaction method that is aware of power outages.
[0071] To address this issue, this application proposes a programmable button interaction method that is aware of power failure. This method is executed by a slave processor in a programmable button module. Specifically, the slave processor first obtains the function mapping table and display image data of the physical buttons generated by the main control system based on scene switching. The function mapping table includes a correspondence between at least one button ID and a function code. The main control system can preset multiple operating scenarios, such as office mode or entertainment mode, and dynamically generate appropriate function configurations when switching scenes. For example, in office mode, a button ID may be mapped to the "save document" function code, while in entertainment mode it may be mapped to the "play / pause" function code, thereby avoiding the need for users to memorize multiple mode functions and reducing the risk of misoperation. Subsequently, the slave processor drives the e-ink screen to update the display based on the display image data, so that the e-ink screen displays the function identifiers corresponding to each button ID. The e-ink screen utilizes its bistable display characteristics, which allows it to maintain the display content without continuous power supply after refreshing, ensuring that the function identifiers remain visible even after power failure, providing users with clear visual feedback.
[0072] After the main control system is powered off, the slave processor continues to independently monitor the trigger events of the physical button array. It maintains its ability to detect changes in button voltage levels through a low-power design. If a physical button trigger is detected, the slave processor queries the function code corresponding to that physical button from the stored function mapping table, using it as the target function code. This query process is based on pre-stored mapping relationships to ensure operational accuracy. Next, the slave processor executes the operation corresponding to the target function code or stores the target function code. For operations that can be executed locally (such as adjusting volume), the response is completed directly. For operations that require processing by the main control system (such as data saving), the target function code is temporarily stored in a non-volatile memory area. When the control system is powered on again, if the stored target function code exists, the slave processor immediately reports it to the main control system to restore the operational state during the power outage and maintain system consistency.
[0073] This application combines the power-off display characteristics of an e-ink screen with the independent monitoring capabilities of a slave processor. Utilizing a dynamic storage mechanism of a function mapping table, it ensures that function identifiers remain visible and key events are processed even after the main control system is powered off. This eliminates the need for users to memorize complex function mappings, significantly reducing learning costs and the risk of misoperation. Simultaneously, it ensures normal operation of the device during unexpected power outages or low-power states, enhancing the flexibility and reliability of the interaction.
[0074] In some of the embodiments described above in this application, a function mapping table and display image data are obtained to drive the electronic ink screen to update the display. However, if the data is not reliably stored during this process, it may be lost or damaged when the power is off, thereby affecting the reliability of button operation after the power is off.
[0075] In response, this application further proposes that after obtaining the function mapping table and display image data of the physical buttons generated by the main control system according to the scene switching, the method further includes: writing the function mapping table and the display image data into a non-volatile memory for storage, and updating the storage verification information.
[0076] Specifically, after the main control system generates the function mapping table and display image data for physical buttons based on scene switching, i.e., the main control system has generated new button configuration data and sent it to the programmable button module, the processor immediately performs a storage operation upon receiving this data. The function mapping table is a key data structure defining the behavior of physical buttons. Its fields may include button ID, function code, display type, the display image data, and trigger conditions, used to associate specific physical buttons with preset function operations. The display image data is used to present graphic information corresponding to the function identifiers of the physical buttons on the e-ink screen, such as pixel data of icons, text, or patterns. Storing this data in non-volatile memory refers to transferring the received function mapping table and display image data from volatile memory (such as RAM) to non-volatile memory from the processor. Non-volatile memory is a storage medium that retains its contents even after power is lost, such as flash memory, electrically erasable programmable read-only memory (EEPROM), or ferroelectric random access memory (FRAM). By storing the data in non-volatile memory, it can be ensured that this critical button configuration information is not lost even when the main control system is powered off. In addition, after data is written to non-volatile memory, the storage checksum information is updated. Storage checksum information is additional information calculated based on the stored data, such as a Cyclic Redundancy Check (CRC) code, checksum, or parity bit. Its purpose is to verify the integrity and accuracy of the stored data, preventing errors during the writing process or accidental tampering during storage. Updating the checksum information typically involves recalculating the checksum and storing it along with the data so that it can be compared and verified during subsequent data retrieval.
[0077] In this embodiment, after the main control system generates new key configuration data and sends it to the programmable key module, the slave processor immediately writes the function mapping table and display image data into the non-volatile memory and updates the storage verification information. This process ensures that the latest key configuration data can be reliably and persistently stored, effectively avoiding data loss or corruption caused by a sudden power outage of the main control system. When the main control system loses power, the slave processor can read the complete and verified key configuration data from the non-volatile memory, thereby continuing to detect the trigger events of the physical key array and execute the corresponding functional operations or store function code, ensuring the availability and reliability of the key interaction system in the power outage state. At the same time, by updating the verification information, the robustness of data storage is further improved, ensuring the accuracy of data reading and providing users with a stable and reliable key interaction experience.
[0078] Please see Figure 5 , Figure 5A specific implementation of step S12 is shown below: S121: Determine the target screen area based on the button ID. S122: Retrieve the display image data corresponding to the button ID from the non-volatile memory, using it as the target display image data. S123: Drive the e-ink screen to refresh the target screen area based on the target display image data, so that the e-ink screen displays the function identifiers corresponding to each button ID.
[0079] In some of the solutions described above in this application, the function mapping table and display image data are written to non-volatile memory for persistent storage. However, in the process of driving the e-ink screen to update the display, the lack of a precise area refresh mechanism for the button ID may lead to low refresh efficiency or inaccurate display.
[0080] In response, this application further proposes to update the display of the e-ink screen based on the displayed image data, so that the e-ink screen displays the function identifiers corresponding to each button ID. This process includes the following steps: First, the target screen area is determined based on the button ID. This step aims to assign a specific display area to each physical button on the e-ink screen, ensuring that the function label is accurately presented above or beside the corresponding button. The button ID is a unique identifier for a physical button, allowing the location of its corresponding display area within the overall display layout of the e-ink screen. Specifically, a mapping table between button IDs and screen coordinate ranges can be pre-stored in the processor. When a button ID is received, the processor directly queries this mapping table to obtain the starting coordinates and size information of the corresponding screen area. Alternatively, the screen area corresponding to each button ID can be dynamically calculated using an algorithm based on the overall layout of the e-ink screen and the physical arrangement of the physical button array. For example, if the e-ink screen uses an integrated main screen layout divided into several label areas, the pixel range of the corresponding label area on the main screen can be calculated based on the order or position of the button IDs. If a distributed sub-screen system is used, each button ID directly corresponds to an independent e-ink sub-screen, and the entire display area of that sub-screen is the target screen area.
[0081] Secondly, the display image data corresponding to the key ID is retrieved from non-volatile memory as the target display image data. This step ensures that even after the main control system is powered off, the processor can still retrieve the display content associated with a specific key ID from the non-volatile memory, thereby driving the e-ink screen to display the correct key function identifier. The display image data can be a pre-rendered bitmap, vector graphics instructions, or text information, used to present the function identifier on the e-ink screen. Specifically, the non-volatile memory can store a data structure containing the key ID, function code, and a pointer or index pointing to the actual display image data storage location. The processor queries this data structure based on the key ID, and then reads the corresponding display image data from a specific address in the non-volatile memory using the pointer or index. Alternatively, the display image data of all keys can be packaged and stored in a file, and a mapping table between key IDs and data offsets in the file can be maintained in the non-volatile memory. The processor obtains the offset based on the key ID, and then reads the image data of the corresponding length from the file.
[0082] Finally, the target display image data drives the e-ink screen to refresh the target screen area, so that the function identifiers corresponding to each button ID are displayed on the e-ink screen. This step is crucial for achieving partial updates of the e-ink screen. It uses the acquired target display image data to refresh only the target screen area corresponding to a specific button ID, rather than refreshing the entire screen. This significantly reduces power consumption and shortens refresh time for the e-ink screen. Specifically, the processor sends a partial refresh command through the e-ink screen's controller interface. This command typically includes the coordinates and size of the target screen area, as well as the image data to be displayed. After receiving the command, the e-ink screen controller only updates the pixel state of the specified area. Alternatively, the processor can first load the target display image data into the frame buffer of the e-ink screen controller at the location corresponding to the target screen area, and then send a partial refresh command, instructing the controller to refresh only the updated area in the frame buffer.
[0083] This application provides an efficient and accurate method for updating an e-ink screen. By associating specific screen areas with display data via button IDs, it solves the problems of low refresh efficiency and inaccurate display. Specifically, the target screen area is determined based on the button ID, ensuring that operation is performed only on the local area corresponding to the button, avoiding the resource waste and latency caused by full-screen refresh. The display image data corresponding to the button ID is retrieved from non-volatile memory, utilizing the persistence of storage to directly associate the button with the data, ensuring that the data can be accessed quickly and accurately after the main control system is powered off. The e-ink screen refreshes the target screen area based on the target display image data, updating specific areas in a targeted manner, reducing refresh time and energy consumption, while ensuring that the function identifier strictly corresponds to the button ID, improving display accuracy and user operation reliability. These features work together to achieve low-power, high-efficiency dynamic updating of button function identifiers, significantly improving the user experience.
[0084] Please see Figure 6 , Figure 6 A specific implementation of step S15 is shown below: S151: If the operation corresponding to the target function code is a first operation type, then the operation corresponding to the target function code is executed. S152: If the operation corresponding to the target function code is a second operation type, then the target function code is stored, and the power-on process of the main control system is triggered.
[0085] In some of the solutions described above in this application, target function code is executed or stored to handle key events after a power outage. However, in this process, the operation type is not clearly distinguished, which may lead to incorrect execution or improper storage when handling key events in a power outage state, affecting system efficiency and accuracy.
[0086] In response, this application further proposes to execute the operation corresponding to the target function code or store the target function code, including: if the operation corresponding to the target function code is a first operation type, then execute the operation corresponding to the target function code; if the operation corresponding to the target function code is a second operation type, then store the target function code and trigger the power-on process of the main control system.
[0087] Specifically, when the processor detects a trigger event of the physical button array and retrieves the corresponding target function code, it determines the operation type based on that target function code. If the operation corresponding to the target function code is the first operation type, it means that the operation can be completed independently by the processor without the involvement of the main control system. Examples include lighting an LED indicator, sending a simple wake-up signal, adjusting the backlight brightness of the programmable button module, switching the display mode of the e-ink screen, or recording simple user preference settings in local memory. These operations typically have low resource requirements and real-time requirements. In this case, the processor will directly call the corresponding hardware interface or software module to complete the specified action according to preset logic or an instruction set stored in non-volatile memory. For example, if the target function code indicates "increase brightness," the processor will send an instruction to the backlight driver circuit to increase the brightness; if it indicates "switch display mode," it will update the display parameters of the e-ink screen.
[0088] On the other hand, if the target function code corresponds to a second operation type, it indicates that the operation requires the participation of the main control system to complete. This includes complex operations such as starting a specific application mode, launching an application, performing network communication, data processing, or controlling other external devices. These operations typically involve significant computing resources, external interfaces, or complex business logic, and cannot be completed independently by the slave processor. In this case, the slave processor will not execute the operation immediately, but will temporarily store the detected target function code in its connected non-volatile memory. This storage ensures that the function code will not be lost even if an unexpected power outage occurs during the power-on process of the main control system, thus guaranteeing the reliability of the operation. After storing the target function code, the slave processor will send a wake-up signal or power-on command to the main control system to trigger the power-on process of the main control system. This can be a physical level signal or a specific communication protocol command, designed to prompt the main control system to resume operation from a power-off or sleep state for subsequent processing of the stored function code.
[0089] In this embodiment, the processing of user key press events is finely managed when the main control system is powered off. Specifically, by distinguishing between "first operation type" and "second operation type," the slave processor can intelligently determine the nature of the key press operation. For operations of the first operation type, the slave processor can execute them immediately locally, such as adjusting the display or settings of the programmable key module itself, thereby providing an instant-response user experience and avoiding unnecessary system wake-up delays. For operations of the second operation type, since they require complex processing by the main control system, the slave processor will not execute them blindly, but will securely store them in non-volatile memory and actively trigger the main control system to power on. This mechanism ensures that after the main control system is powered on again, it can accurately acquire and process the instructions issued by the user during the power outage, avoiding the problem of user operation loss or incorrect execution due to the main system power failure. This type-based processing method not only improves the system's response reliability and the correctness of user operations in the power outage state, but also optimizes system power consumption management, waking up the main control system only when necessary, thereby extending the device's standby time.
[0090] In one specific embodiment, a smart home central controller is provided (imagine a smart home central controller), comprising: Home Mode: The e-ink screen displays lighting and air conditioning scenes, with corresponding button labels changing to "Bright Mode" and "Comfort Mode." These labels remain visible even after a power outage. (The main e-ink screen displays a floor plan of the home, highlighting the status of lighting and air conditioning. The buttons below are labeled "Bright Mode," "Comfort Mode," and "Armed Away." Even in the event of a power outage, users can easily restore a comfortable home environment by pressing the "Comfort Mode" button upon returning home, based on the screen display.) Multimedia Mode: The screen switches to the media control interface, and the button labels change to "Playback", "Volume +", "Switch Input Source", etc.
[0091] Security Mode: The screen dims, and the button labels change to "Arm" and "One-Click Alarm." (The screen dims, primarily displaying camera feeds and sensor status; button labels change to "Arm," "Disarm," and "One-Click Alarm." Even after power failure, key security operation access points remain clearly visible.) This way, even if the user returns home after the controller has been completely powered off, they can accurately press the "Comfort Mode" button based on the last display on the screen.
[0092] In another specific embodiment, a laboratory measuring instrument is provided, which is a multi-functional oscilloscope. The buttons around the multi-functional knob on its panel have different functions in different measurement modes (time domain, frequency domain, protocol analysis). Using the embodiment of this application, the sub-e-ink screen next to each button displays labels such as "Voltage Range," "Time Base," "Start Measurement," and "Automatic Calibration" according to the mode switch, avoiding user confusion and improving measurement efficiency.
[0093] In another specific embodiment, a professional video switcher is provided. During live broadcast production, different buttons on the switcher can be programmed to switch between different camera signals, play specific clips, or provide special effects. Using the method of this application, the director can pre-configure the function of each button according to the program schedule, and the e-ink screen on the button clearly displays the camera number or clip name. Even if the equipment is turned off after rehearsal, all button functions are readily apparent upon the next power-on, ensuring the accuracy and efficiency of the live broadcast.
[0094] Obviously, the embodiments described above are merely some embodiments of this application, not all embodiments. The accompanying drawings show preferred embodiments of this application, but do not limit the scope of this application. This application can be implemented in many different forms; rather, these embodiments are provided to provide a more thorough and comprehensive understanding of the disclosure of this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or make equivalent substitutions for some of the technical features. Any equivalent structures made using the content of this application's specification and drawings, directly or indirectly applied to other related technical fields, are similarly within the scope of protection of this application.
Claims
1. A programmable keypad interaction system with power-off awareness, characterized in that, include: The main control system is used to generate a function mapping table of physical buttons and display image data according to the current scene. A programmable keypad module, communicatively connected to the main control system, includes: The processor receives and stores the function mapping table and the display image data, and detects key events after the main control system is powered off. A non-volatile memory, connected to the slave processor, is used to store the function mapping table and the display image data; A physical button array, connected to the slave processor, is used to receive user press operations; An electronic ink screen, connected to the slave processor, is used to display function identifiers corresponding to each of the physical buttons in the physical button array, and to maintain the display state of the function identifiers after the main control system is powered off; The slave processor is configured to respond to the triggering operation of the physical key array according to the function mapping table stored in the non-volatile memory after the main control system is powered off.
2. The programmable key interaction system with power failure detection according to claim 1, characterized in that, The slave processor is also configured to; Upon receiving the update command sent by the main control system, the function mapping table and the display image data are stored in the non-volatile memory, and the electronic ink screen is driven to update the display. And after the main control system is powered on again, the stored function codes are reported to the main control system.
3. The programmable key interaction system with power failure detection according to claim 1, characterized in that, The electronic ink screen layout can be either an integrated main screen or a distributed sub-screen system. The integrated main screen is divided into several label areas, and each label area is aligned with a physical button in position; Each physical button in the distributed sub-screen system is equipped with an e-ink sub-screen.
4. The programmable key interaction system with power failure detection according to claim 1, characterized in that, The fields of the function mapping table stored in the non-volatile memory include: button ID, function code, display type, display image data, and trigger condition; The triggering condition is at least one of the following: single click, long press, combination key, time sequence key, system mode, and time condition.
5. The programmable key interaction system with power failure detection according to claim 1, characterized in that, The programmable key module also includes an independent backup power supply; The independent backup power supply is used to provide sustaining power to the slave processor, the non-volatile memory, and the e-ink screen after the main control system is powered off or enters deep sleep mode.
6. The programmable keypad interaction system with power-off detection according to any one of claims 1 to 5, characterized in that, The function mapping table is dynamically programmed according to the scenario and mode of the button.
7. A programmable button interaction method that is aware of power failure, characterized in that, The method is executed by a slave processor in a programmable key module, and includes: The main control system generates a function mapping table and display image data of physical buttons based on scene switching. The function mapping table includes at least one button ID and function code. The electronic ink screen is updated and displayed according to the displayed image data, so that the electronic ink screen displays the function identifiers corresponding to each button ID; After the main control system is powered off, the trigger events of the physical button array are monitored; If the physical button is detected to be triggered, the function code corresponding to the physical button is queried and used as the target function code; Execute the operation corresponding to the target function code or store the target function code; When the stored target function code exists and the main control system is powered on again, the stored target function code is reported to the main control system.
8. The programmable button interaction method with power failure detection according to claim 7, characterized in that, After obtaining the function mapping table of physical buttons and display image data generated by the main control system according to the scene switching, the method further includes: The function mapping table and the display image data are written into a non-volatile memory for storage, and the storage verification information is updated.
9. The programmable button interaction method with power failure detection according to claim 8, characterized in that, The step of driving the electronic ink screen to update the display based on the displayed image data, so that the electronic ink screen displays the function identifiers corresponding to each of the button IDs, includes: The target screen area is determined based on the button ID; The display image data corresponding to the button ID is obtained from the non-volatile memory and used as the target display image data; Based on the target display image data, the e-ink screen is driven to refresh the target screen area, so that the e-ink screen displays the function identifiers corresponding to each button ID.
10. The programmable key interaction method with power failure detection according to any one of claims 7 to 9, characterized in that, The step of executing the operation corresponding to the target function code or storing the target function code includes: If the operation corresponding to the target function code is a first operation type, then the operation corresponding to the target function code is executed; If the target function code corresponds to the second operation type, then the target function code is stored, and the power-on process of the main control system is triggered.