BOM-based keyboard key function configuration method, apparatus, equipment, and medium
Patent Information
- Application Number
- CN202610943866.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2026-06-29
- Publication Date
- 2026-09-18
- Estimated Expiration
- 2046-06-29
AI Technical Summary
[0003]上述现有配置范式存在显著局限,首先,由于需针对不同功能需求维护相互独立的软件版本,导致版本矩阵日益庞大,不仅增加了开发与测试的边际成本且降低了产线部署与订单切换的效率;其次,多版本并行使得售后维护面临严峻的版本错配风险,维修终端在执行刷新操作时极易引入非匹配的固件程序,提升了售后管控难度与返工率;此外,传统配置流程高度依赖人工识别设备订单属性并手动调用对应的写入工具,该人工干预环节构成了系统自动化链路的瓶颈,极易因主观疏漏导致按键功能配置错误,难以满足现代高密度制造对高可靠性与零缺陷的严苛要求
通过直接解析源头BOM数据中预设栏位的特征信息进行逻辑判断,彻底免除了产线订单切换时的软件更迭,大幅缩减了开发与测试的边际成本;将逻辑判断结果转化为第一或第二配置参数,并直接烧录至设备的非易失性存储介质中,以将按键功能定义从易被覆盖的软件层下沉至掉电不丢失的硬件层,使得后续任何系统重装或售后刷机均无法篡改已固化的按键属性,从而杜绝了非匹配固件介入导致的错配风险与返工率;从BOM特征提取、启用条件自动判定、参数生成到精准写入的全链路自动化,可避免了人工识别订单属性与手动调用写入工具的环节,阻断了主观疏漏导致配置错误的路径。
Smart Images

Figure CN122470058B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the technical field of electronic equipment manufacturing and computer peripheral control, and in particular to a method, apparatus, device and medium for configuring keyboard key functions based on BOM. Background Technology
[0002] With the rapid evolution of intelligent computing devices, human-computer interaction interfaces are developing towards greater customization and intelligence. Taking laptops as an example, to adapt to different operating system environments or specific application ecosystems (such as AI-assisted keys), the logical mapping of physical keyboard keys needs to be defined differently. Currently, the industry mainly relies on burning different versions of underlying firmware or configuration software into the non-volatile storage media during the device manufacturing process, based on the target sales region or system pre-installation type, to achieve hardware-level solidification of key functions. This technical path based on pre-installed firmware branches constitutes the basic technical framework for achieving differentiated configuration of peripheral functions in current electronic manufacturing services.
[0003] The existing configuration paradigm has significant limitations. First, the need to maintain independent software versions for different functional requirements leads to an ever-growing version matrix, which not only increases the marginal cost of development and testing but also reduces the efficiency of production line deployment and order switching. Second, the parallel operation of multiple versions exposes after-sales maintenance to a severe risk of version mismatch. When performing refresh operations, the repair terminal is prone to introducing incompatible firmware programs, increasing the difficulty of after-sales management and rework rate. In addition, the traditional configuration process relies heavily on manual identification of equipment order attributes and manual invocation of the corresponding writing tool. This manual intervention constitutes a bottleneck in the system's automation chain and is prone to errors in button function configuration due to subjective negligence, making it difficult to meet the stringent requirements of high reliability and zero defects in modern high-density manufacturing. Summary of the Invention
[0004] To overcome the shortcomings of existing technical solutions, embodiments of the present invention provide a method, apparatus, device, and medium for configuring keyboard key functions based on BOM.
[0005] The technical solution adopted by this invention to solve its technical problem is: A method for configuring keyboard key functions based on BOM, the method comprising: Obtain the BOM data of the device to be configured; the BOM data includes identification information used to identify keyboard function configuration requirements; Obtain the feature information of the preset configuration fields from the BOM data; Based on the feature information, determine whether the device to be configured meets the activation conditions for a specific button function; If the activation conditions are met, a first configuration parameter corresponding to the specific button function is generated, and the first configuration parameter is written into the storage medium of the device to be configured. If the activation conditions are not met, a second configuration parameter corresponding to the default key function is generated and written into the storage medium of the device to be configured to solidify the function of the keyboard keys.
[0006] Secondly, embodiments of the present invention also provide a keyboard key function configuration device based on a BOM, the device comprising: The acquisition module is used to acquire the BOM data of the device to be configured; the BOM data includes identification information for identifying keyboard function configuration requirements; The extraction module is used to obtain feature information of preset configuration fields from the BOM data; The judgment module is used to determine whether the device to be configured meets the activation conditions of a specific button function based on the feature information. The configuration execution module is configured to generate a first configuration parameter corresponding to the specific key function if the activation condition is met, and write the first configuration parameter into the storage medium of the device to be configured; if the activation condition is not met, generate a second configuration parameter corresponding to the default key function, and write the second configuration parameter into the storage medium of the device to be configured, so as to solidify the function of the keyboard keys.
[0007] Thirdly, embodiments of the present invention provide a computer device, the computer device including a processor, a network interface, a memory and a communication bus, wherein the processor, the network interface and the memory communicate with each other through the communication bus; Memory, used to store computer programs; When a processor executes a program stored in memory, it implements the steps of the BOM-based keyboard key function configuration method described in the first aspect above.
[0008] Fourthly, embodiments of the present invention further provide a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the BOM-based keyboard key function configuration method as described in any one of the first aspects.
[0009] Compared with the prior art, the beneficial effects of the present invention are: By directly parsing the feature information of preset fields in the source BOM data for logical judgment, software iterations during production line order switching are completely eliminated, significantly reducing the marginal cost of development and testing. The logical judgment results are converted into first or second configuration parameters and directly burned into the non-volatile storage medium of the device. This moves the button function definition from the easily overwritten software layer to the hardware layer that is not lost when power is off. This ensures that the fixed button attributes cannot be tampered with by any subsequent system reinstallation or after-sales flashing, thereby eliminating the risk of mismatch and rework caused by the intervention of incompatible firmware. The full-link automation from BOM feature extraction, automatic determination of activation conditions, parameter generation to accurate writing avoids the need for manual identification of order attributes and manual calling of writing tools, blocking the path of configuration errors caused by subjective negligence. Attached Figure Description
[0010] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0011] Figure 1 This is a flowchart of the steps of the keyboard key function configuration method based on BOM according to an embodiment of the present invention; Figure 2 This is a block diagram of a keyboard key function configuration device based on BOM according to an embodiment of the present invention; Figure 3 This is a schematic block diagram of a computer device according to an embodiment of the present invention. Detailed Implementation
[0012] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0013] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.
[0014] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.
[0015] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.
[0016] In order to solve the problems existing in the current technology, The following details a specific scheme for configuring keyboard key functions based on a BOM (Bill of Materials) according to an embodiment of the present invention. Figure 1 As shown, the specific steps of this BOM-based keyboard key function configuration method include the following: In step S110, the BOM data of the device to be configured is obtained; the BOM data includes identification information used to identify keyboard function configuration requirements.
[0017] Specifically, in actual industrial production environments, such as SMT production lines or system programming stations for laptops, the device to be configured in this embodiment of the invention is a laptop motherboard in a bare or semi-finished state connected to a manufacturing execution system or host computer production tool. An automated development tool, i.e., the configuration execution end, can directly pull the bill of materials (BOM) data uniquely bound to the device to be configured in real time from the MES system or production database through a preset communication interface. This automated retrieval mechanism ensures a closed loop in the data flow and avoids delays and errors caused by manual intervention.
[0018] Traditional BOM data mostly only contains the physical attributes of materials, such as the model of resistors and capacitors, and the part number of structural components. However, in this embodiment of the invention, the BOM data is structurally extended at the software level. The BOM data obtained at this time not only contains the hardware part number, but also some data at the software level of the batch or the specific order of equipment, that is, the identification information used to identify the keyboard function configuration requirements. In this way, the hardware manufacturing list and the software configuration strategy are deeply coupled, realizing the refined management of one item, one code or one single definition.
[0019] In a preferred embodiment, the identification information is embedded in a specific field of the BOM data in the form of key-value pairs. For example, for keyboard configuration requirements with AI-assisted functions, such as Copilot Key, the identification information can be specifically a string feature like AutoBOM OS=Windows or AutoBOM OS=Non-Windows; in other embodiments, for configuration requirements restricted by regional compliance policies, the identification information is a region code such as Sales Region=US or Sales Region=EU.
[0020] Once the development tool obtains the aforementioned BOM data, its underlying parsing module will accurately locate and extract the subsequent values, such as Windows or US, using regular expression matching or string truncation. The extracted feature values will be directly used as the core input variables in the next step to determine whether the device's keyboard meets the specific key functions, i.e., the conditions for enabling AI keys. This completely replaces the subjective judgment process in traditional processes where production line workers visually identify order labels and manually select software versions.
[0021] In step S120, the feature information of the preset configuration field is obtained from the BOM data.
[0022] Specifically, it's important to first clarify that the device to be configured can be an electronic device such as a laptop or tablet. The BOM data can be structured spreadsheets, such as Excel, CSV, or database forms within an MES system, similar to the BOM data for laptops on the production line. Pre-defined configuration fields refer to specific columns planned and defined in the BOM form before the production process, based on sales strategies for different countries / regions, operating system pre-installation requirements, and keyboard hardware specifications; these are typically AQ or BP columns, etc.
[0023] In actual operation, after the development tools or configuration system obtain the entire BOM data, they do not traverse the entire data. Instead, they use a preset data parsing algorithm (such as string matching based on key-value pairs or regular expression extraction technology) to directly and accurately locate the aforementioned preset configuration fields.
[0024] Furthermore, the specific data content uniquely bound to the current device order under this field is extracted to obtain the feature information. In the actual application scenario of this invention, this feature information is mainly used to characterize whether the device has the hardware and software environment to run specific AI functions, such as the Copilot Key. Taking actual production data as an example, the extraction process of this feature information is specifically manifested as follows: 1. Feature extraction based on operating system identifiers: Specifically, the development tool captures key fields similar to AutoBOMOS in preset fields and extracts their corresponding values, such as whether it is Windows or not. Here, whether it is Windows or not is the extracted feature information, which directly reflects the device's underlying operating system's support capability for AI buttons. 2. Feature extraction based on keyboard hardware model and status code: Specifically, the development tool captures preset fields such as KeyboardCTE US to extract the keyboard's part number code, such as A4 or A3, and the corresponding status setting value, such as Setting=0 or Setting=1. Here, A4 combined with Setting = 0 constitutes the feature information indicating support for Copilot Key; while A3 combined with Setting=1 constitutes the feature information indicating that Copilot Key is not supported and needs to be configured as an Application Key.
[0025] Based on the above operating principle, BOM form data, which was originally only used for material management, can be transformed into feature information that can be directly read and logically judged by computer programs. This eliminates the need for the traditional manual process of consulting BOM forms and making subjective judgments, and achieves high-precision, automated data bridging between production data sources and functional configuration parameters.
[0026] In step S130, it is determined whether the device to be configured meets the activation conditions for a specific button function based on the feature information.
[0027] Specifically, before performing this step, the system has a pre-built or configured activation condition rule base corresponding to specific key functions, such as the Copilot Key AI function. This activation condition rule base defines the logical mapping relationship between feature information and key function activation status. Its judgment criteria cover multiple dimensions such as operating system compatibility requirements, function authorization policies of the target sales area, and the physical support capabilities of the keyboard hardware itself.
[0028] In actual operation, the system uses the feature information of the preset configuration fields extracted in the previous stage as input variables and imports them into the preset judgment logic for comparison and parsing. Specifically, by performing conditional decomposition and logical operation on the feature information, for example, the system simultaneously reads the character AutoBOM OS= which represents the operating system attribute and the character Setting=0 which represents the keyboard configuration status.
[0029] Furthermore, if the feature information simultaneously satisfies that the operating system is Windows, representing a low-level operating environment with AI capabilities, and the keyboard configuration state is 0 (Normal mode, indicating that the specific key is not disabled or redefined at the hardware level), then the system's internal judgment engine outputs the first judgment result, confirming that the device to be configured meets the conditions for enabling the specific key function. Conversely, if any key node in the feature information does not match, for example, if AutoBOM OS = non-Windows is parsed, meaning there is a lack of system environment support, or if Setting = 1 (Customized mode) is parsed, it indicates that the key is preset as a normal application key, and the system outputs the second judgment result, confirming that the device to be configured does not meet the conditions for enabling the specific key function.
[0030] Through the above operating principle, the complex decision-making process that originally relied on manual identification of BOM forms and subjective evaluation of regional sales strategies is transformed into a rigorous and deterministic computer logic judgment, ensuring that the activation conditions of specific button functions can be accurately identified and confirmed in cross-regional and multi-batch production and manufacturing environments.
[0031] In step S140, if the activation condition is met, a first configuration parameter corresponding to the specific button function is generated and written into the storage medium of the device to be configured.
[0032] Specifically, at the branch control level of the system logic flow, when the aforementioned determination step outputs a deterministic result that meets the activation conditions, such as when the feature information simultaneously satisfies that AutoBOM OS is Windows and KeyboardSetting is 0, a high-privilege execution thread for parameter generation and solidification writing is automatically triggered.
[0033] During the generation phase of the first configuration parameter, the system's built-in configuration script or middleware, based on the determination result, calls a preset parameter mapping table or instruction set to generate the first configuration parameter that strictly corresponds to a specific button function, such as the CopilotKeyAI function. In the specific application scenario of this invention, this first configuration parameter, at the underlying logic level, is a set of specific control instructions or status codes used to define the button hardware state; for example, the system will generate a variable representing the Normal state, i.e., the underlying variable supporting the Copilot function, specifically embodied in the feature variable 00000 returned after the manufacturing MES parsing.
[0034] During the stage of writing the first configuration parameters to the storage medium, the underlying communication interface and the burning tool are called, such as calling the EEPROM.exe program via the command line, to encapsulate the generated status code 00000 into a specific burning instruction, such as EEPROM.exe –s –td –b “00000”, and send it to the device to be configured, such as a laptop computer at the test station on the production line.
[0035] It should be noted that the storage medium specifically refers to the non-volatile memory electrically connected to the keyboard controller, i.e., the EC or keyboard MCU, such as an EEPROM chip or SPI Flash. A communication connection is established with this storage medium through the system bus to accurately write the first configuration parameter 00000 into the corresponding specific register address or memory sector.
[0036] Through the above operating principle, the logical judgment results at the software level are directly converted into physically fixed data at the hardware level. Since the parameters are directly written to non-volatile storage media, this write operation has the characteristic of not losing data when power is off. Thus, the hardware attribute of the button as a specific AI function key is completely fixed before the device leaves the factory, ensuring that the subsequent operating system or BIOS can directly obtain the accurate function definition when reading the keyboard mapping, realizing a fully automated closed loop from data judgment to hardware-level parameter burning.
[0037] In step S150, if the activation conditions are not met, a second configuration parameter corresponding to the default key function is generated and written into the storage medium of the device to be configured to solidify the function of the keyboard keys.
[0038] Specifically, at the branch control level of the system logic flow, when the output of the aforementioned judgment step does not meet the activation conditions, such as the feature information parsing that the AutoBOM OS is not Windows, or the keyboard configuration state is Setting=1, i.e., Customized mode, the fault tolerance and compatibility processing branch of the default function is automatically triggered.
[0039] During the generation phase of the second configuration parameter, the system invokes preset default mapping rules to generate a second configuration parameter corresponding to common key functions, such as the traditional Application Key. This second configuration parameter is logically differentiated at the underlying level by specific control commands or status codes that distinguish it from supported states. For example, the system generates an underlying variable representing the Customized state, which disables specific AI functions and reverts to the default function; this can be specifically reflected in the feature variable 00001 returned after the manufacturing MES parsing.
[0040] During the stage of writing the second configuration parameter to the storage medium, the underlying communication interface and the programming tool are invoked, such as by calling the EEPROM.exe program via the command line. The generated status code 00001 is encapsulated into the corresponding programming instruction, namely EEPROM.exe –s –td –b “0 0 0 0 1”, and sent to the device to be configured. Through the underlying bus protocol, the second configuration parameter is precisely written into a specific register address associated with the non-volatile memory within the device to be configured.
[0041] This step solidifies the functionality of the keyboard keys. Since non-volatile storage media has the physical characteristic of not losing data when power is off, the second configuration parameter is written into it. In this way, at the device's physical factory level, the hardware-level identity of this key is permanently redefined from a specific AI function key to a default general key. This effectively avoids the risk of key malfunction, unresponsiveness, or system error triggering when the device does not have a specific AI operating environment. It ensures that the same hardware platform can provide a stable and reliable key interaction experience under different software and hardware constraints.
[0042] In some specific embodiments, the feature information includes operating system type information or sales region information; the step is to determine whether the device to be configured meets the activation conditions of a specific button function based on the feature information, specifically including the following steps: The system identifies whether the feature information contains a preset target operating system identifier; if it contains the target operating system identifier, the system determines that the activation conditions for the specific key function are met; if it does not contain the target operating system identifier, the system determines that the activation conditions for the specific key function are not met.
[0043] Specifically, feature information serves as a multi-dimensional judgment criterion, encompassing operating system type information, such as Windows, Linux, or DOS, and sales region information, such as China or Japan. In the judgment logic of this embodiment, operating system type information is used as the core pre-judgment dimension because specific key functions, such as the Copilot Key, often heavily rely on the underlying AI framework and interface support of a specific operating system; for example, related components can only be called in a Windows environment. Therefore, the configuration script or rule engine pre-sets a target operating system identifier that is strictly bound to this specific key function, such as the character feature "Windows".
[0044] Based on the confirmation that the target operating system identifier is included, it is necessary to further identify whether the feature information contains a preset target sales region identifier; specifically, whether specific button functions, especially cloud-side AI functions, are restricted by data privacy regulations, export control regulations, or product commercialization release strategies of different countries or regions, and are not open for use in all regions of the world; therefore, by continuing to extract and match keywords from the sales region field in the BOM data, such as the values corresponding to the aforementioned Sales Region, such as "US", "CN", "EU", etc.
[0045] During the identification and judgment process, algorithms such as string parsing, keyword matching, or regular expression extraction are used to accurately retrieve the acquired feature information. Specifically, for the operating system field parsed from the BOM preset configuration fields, such as the specific value corresponding to the aforementioned AutoBOM OS, a target operating system identifier hit detection is performed.
[0046] In terms of logical branching, if a preset target operating system identifier is successfully identified in the string sequence of feature information, i.e., the detection result is AutoBOM OS: is Windows, it indicates that the software ecosystem pre-installed on the device to be configured has the underlying environment to support the operation of the specific button function. The system logic judgment module outputs a positive result, i.e., it determines that the device to be configured meets the activation conditions of the specific button function. Conversely, if the system does not find the aforementioned target operating system identifier in the feature information, for example, the detection result is AutoBOM OS: not Windows, it means that other incompatible operating systems are pre-installed, indicating that there is an architectural limitation between the device software environment and the specific AI button function. The system judgment module outputs a negative result, i.e., it determines that the device to be configured does not meet the activation conditions of the specific button function.
[0047] This approach abstracts and transforms complex cross-regional and cross-system hardware and software adaptation strategies into automated character-level retrieval and judgment logic targeting the target operating system identifier. The mechanism using operating system type as the core filtering factor not only accurately eliminates the risk of key malfunctions or system errors caused by system environment incompatibility at the source, but also achieves deep decoupling between the judgment rules and the BOM data structure.
[0048] In this way, when the function of a specific button is expanded to be compatible with a new operating system in the future, it is only necessary to add the corresponding target operating system identifier to the system, without refactoring the judgment code, thus improving the scalability of the configuration system and the accuracy of production line judgment.
[0049] In some specific embodiments, the steps involve writing the first configuration parameter into the storage medium of the device to be configured, or writing the second configuration parameter into the storage medium of the device to be configured, specifically including the following steps: Based on the generated first or second configuration parameters, the preset writing tool is invoked to generate the corresponding writing command.
[0050] Specifically, during the instruction generation phase, the first configuration parameter (e.g., variable 00000 representing support for a specific AI button function) or the second configuration parameter (e.g., variable 00001 representing the default application key) generated after logical judgment is dynamically passed to the underlying writing tool pre-deployed in the production industrial control computer or manufacturing execution system. This pre-defined writing tool is a low-level programming program with direct hardware access and communication permissions. Upon receiving the configuration parameters, the writing tool encapsulates and assembles them into a complete writing instruction conforming to a specific hardware communication protocol, according to predefined instruction syntax rules.
[0051] For example, the tool converts the variable 00000 into a command-line instruction EEPROM.exe –s –td –b “0 0 0 0 0” that includes the communication flag, the target register offset address, and the data payload.
[0052] The configuration data is burned into the non-volatile memory of the device to be configured by executing the write command.
[0053] Specifically, during the instruction execution and data burning phase, the aforementioned write instructions are executed through the operating system's process scheduling interface. During execution, the writing tool establishes a connection with the device to be configured, such as the embedded controller inside a laptop computer at the production line's burning station, via the hardware communication bus on the system motherboard, and addresses the non-volatile memory belonging to the keyboard module via EC.
[0054] Because existing non-volatile memory has the physical characteristic of retaining data even when power is off, the writing tool sends a Write Enable control signal to the memory. It then precisely writes the configuration data bitstream carried in the instruction, i.e., the status code 00 0 0 0 or 0 0 0 1, into the corresponding physical memory sector or register address. After writing is complete, a data readback verification is performed to ensure the integrity of the write operation.
[0055] In a further embodiment, the aforementioned write instruction is a string containing a status identifier; when the enable condition is met, the status identifier is configured to a first value; when the enable condition is not met, the status identifier is configured to a second value.
[0056] Specifically, in this embodiment of the invention, the write command is not directly issued via the system bus in the form of raw binary machine code, but is encapsulated and transmitted in string format. This string command defines a specific command prefix, such as the program name EEPROM.exe, operation parameter identifiers, and the core data payload area. The status identifier is a key control field embedded in this string data payload area, corresponding to the bit state of a specific control register in the non-volatile memory, used to directly define the functional attributes of a specific key on the keyboard from the hardware level.
[0057] During the dynamic generation of instructions, the status identifier is assigned a differentiated value based on the result of the preceding logical judgment. When the device to be configured is determined to meet the activation conditions of a specific button function, such as the Copilot Key AI function, the status identifier is configured to a predetermined first value, which can be understood as the character "0". When generating the write instruction, this character is precisely concatenated to the corresponding data bit of the instruction string, ultimately forming a complete string instruction such as EEPROM.exe –s –td –b "0 0 00 0". In this instruction, the status identifier "0" conveys the encoded semantics of the "normal" mode to the underlying hardware, instructing the microcontroller to enable the button scanning matrix mapping associated with the specific AI function.
[0058] Conversely, when the device to be configured is determined not to meet the above-mentioned activation conditions, the status identifier is configured to a second value that has a logical opposition to the first value, that is, the second value is specifically represented by the character "1", and a string instruction such as EEPROM.exe –s –td –b "0 0 0 0 1" is generated accordingly. The status identifier "1" transmits the encoded semantics of the "custom" mode to the underlying hardware, clearly instructing the microcontroller to block or disconnect the specific AI function trigger signal, switch the hardware logic of the physical button and redirect it to the default application button.
[0059] By condensing complex hardware and software adaptation strategies into numerical switching of a single state identifier, not only are the write commands highly structured and readable, reducing the instruction parsing complexity of the programming tool, but this standardized string instruction format is also seamlessly compatible with existing production line automated testing and programming architectures, ensuring extremely high execution efficiency in the hardware configuration data distribution process in cross-batch, large-scale manufacturing environments.
[0060] In some specific embodiments, after determining whether the device to be configured meets the activation conditions for a specific button function based on the feature information, the following steps are also included: Read the keyboard hardware model information of the device to be configured.
[0061] Specifically, after making an initial assessment of the software and sales strategy based on BOM feature information, the system proceeds to the physical compatibility verification stage at the hardware level. By calling underlying hardware communication interfaces, such as SMBus, I2C bus, or ACPI tables, the system sends enumeration or read commands to the motherboard embedded controller or the microcontroller inside the keyboard of the device to be configured, capturing the keyboard hardware model information of the currently physically connected device in real time. This hardware model information can specifically manifest as the keyboard's supplier ID, device ID, or a specific part number code stored in the keyboard's read-only memory.
[0062] Determine whether the keyboard supports key function reconfiguration based on the keyboard hardware model information.
[0063] Specifically, the keyboard hardware model information read in real time is imported into a pre-defined hardware capability dictionary for comparative analysis. This dictionary predefines the physical and electrical attributes and firmware architecture of each keyboard model, clearly defining the programmable capabilities of the key mapping matrix for different keyboard models. By looking up the dictionary, it can accurately identify whether the current keyboard model integrates erasable and rewritable non-volatile memory, and whether its keyboard controller supports dynamically modifying the scan code mapping of specific keys through external commands, i.e., determining whether key function reconfiguration is supported.
[0064] If supported, proceed with the steps of generating a first configuration parameter corresponding to a specific key function or generating a second configuration parameter corresponding to a default key function.
[0065] Specifically, based on the above hardware capability verification results, strict conditional branch control is executed. If the comparison results confirm that the current keyboard hardware model supports key function reconfiguration, it indicates that the aforementioned software-level judgment result based on BOM feature information has a physical execution basis. The system then allows the subsequent process to proceed and formally executes the step of generating the first configuration parameter or the second configuration parameter. Conversely, if the system determines that the currently assembled keyboard hardware does not support reconfiguration, such as an old or low-end model with hard-wired key functions, it will block and skip the subsequent parameter generation and writing process, and optionally generate hardware incompatibility error logs or alarm prompts.
[0066] Therefore, it can be seen that by first judging the soft conditions and then verifying the hard foundation, the dual verification architecture can effectively intercept blind burning operations caused by incorrect material loading or incorrect material information entry on the production line. This not only avoids underlying errors such as communication bus hang-up and timing timeout caused by sending write commands to keyboards that do not support reconfiguration, but also avoids production delays caused by invalid burning at the system level.
[0067] In a further embodiment, the step of determining whether the keyboard supports key function reconfiguration based on the keyboard hardware model information specifically includes the following steps: Retrieve the setting parameter values corresponding to the keyboard hardware model.
[0068] Specifically, during the parameter acquisition stage, the system uses the keyboard hardware model information read in real time from previous steps, such as the specific keyboard part number code "KB Model X," as an index key to query and match it in a locally pre-built hardware configuration dictionary table or a cloud-based material database. This configuration dictionary table pre-establishes and stores the mapping relationship between each keyboard hardware model and the parameter values. Through table lookup, the parameter value uniquely corresponding to the current keyboard hardware model can be quickly extracted. This parameter value is essentially a physical attribute identifier code fixed by the keyboard manufacturer during the hardware design phase, used to intuitively reflect whether the keyboard model has programmable non-volatile memory and whether the key mapping matrix modification permission is enabled.
[0069] If the parameter value is set to the first preset value, it is determined that button function reconfiguration is not supported; if the parameter value is set to the second preset value, it is determined that button function reconfiguration is supported.
[0070] Specifically, during the execution condition determination phase, the system rigorously compares the extracted setting parameter value with a preset threshold or status code. If the system identifies the setting parameter value as the first preset value, such as 0 or Fixed, it indicates from a hardware logic perspective that the correspondence between the key scan code and the physical key of this keyboard model has been hard-coded in the PCB circuit design or the mask ROM of the keyboard microcontroller, and there is no external write interface or storage space to overwrite its default mapping. Based on this, the system outputs a determination result that key function reconfiguration is not supported, thus directly blocking the reconfiguration at the software logic level. The system continuously issues programming commands to prevent invalid communication handshakes from causing the industrial control computer on the production line to time out and freeze. Conversely, if the system recognizes that the setting parameter value is the second preset value, such as 1 or Programmable, it indicates from the underlying hardware logic that the keyboard model integrates erasable and writable storage media such as EEPROM, and its keyboard firmware supports receiving configuration commands from the external system bus to dynamically redefine the key functions. Based on this, the system accurately determines that the keyboard supports key function reconfiguration and allows the control flow to normally enter the execution branch that generates the first configuration parameter or the second configuration parameter.
[0071] In some specific embodiments, after writing the first configuration parameter or the second configuration parameter to the storage medium of the device to be configured, the following steps are also included: Read the current configuration data from the storage medium.
[0072] Specifically, after the physical programming of the configuration parameters is completed, the data readback and verification phase begins immediately. In the actual electromagnetic environment of a production line, non-volatile memory may be affected by uncontrollable factors such as transient interference from bus communication, physical bad blocks in the storage medium, or improper write protection during write operations, resulting in false writes or "data flips." To eliminate such risks, a read command is sent again to the storage medium of the device to be configured via the underlying hardware bus, targeting the specific register physical address where the write operation was just performed, and reading the actual data stored inside to obtain the current configuration data.
[0073] Compare the current configuration data with the pre-stored standard data.
[0074] Specifically, the current configuration data is extracted into a memory buffer and compared byte by byte with the locally stored standard data. It should be noted that the standard data is the original image of the first or second configuration parameter that the system generates based on the preceding judgment logic (such as whether the enable condition is met or not as mentioned above), which is expected to be accurately written to, i.e., the expected "0 0 0 0 0" or "0 0 0 0 1" status code sequence.
[0075] If they match, the configuration is considered successful and a pass signal is output; if they do not match, the configuration is considered failed and an alarm signal is output.
[0076] Specifically, in the judgment and signal output stage of the comparison results, bidirectional branch control is implemented: if the verification algorithm confirms that the current configuration data and the pre-stored standard data are completely consistent at the bit level, it physically confirms that the function definition of the specific button has been accurately solidified, and the configuration is determined to be successful. A pass signal is then output to the manufacturing execution system or the production line control console to allow the current equipment to flow into the next production process. Conversely, if there is any difference in the comparison results, the configuration is determined to be unsuccessful, indicating that the underlying hardware solidification has not met expectations. The normal offline process of the equipment will be immediately blocked, and an alarm signal will be output to link the production line's audible and visual alarm or interception mechanism, instructing manual intervention to check the hardware communication link or storage medium status.
[0077] In some specific embodiments, after writing the first configuration parameter or the second configuration parameter to the storage medium of the device to be configured, and during the non-mass production R&D debugging phase, the following steps may be optionally adopted: Control the device to be configured to boot into a preset lightweight test operating system environment; load the filter driver mounted on top of the keyboard class driver stack in the test operating system; intercept the actual hardware interrupt data reported when the target key is triggered through the filter driver, and extract the actual HID scan code.
[0078] Specifically, after the physical burning of the storage medium is completed, a restart command is sent to the device to be configured. During the restart process, the device to be configured skips the conventional large user operating system installation steps and directly and quickly boots into a highly customized lightweight test operating system environment, such as a simplified version of WinPE, through a preset network boot or external USB virtual disk boot method. This environment removes all unnecessary system services and graphical interfaces, retaining only the most basic underlying hardware driver framework. Its core purpose is to provide a clean, interference-free and extremely fast software running platform for subsequent keyboard behavior verification.
[0079] During the mounting and loading phase of the filter driver, transparent data hijacking is achieved using the layered driver architecture of modern operating systems. In the enumeration phase of the lightweight test operating system startup, the system dynamically loads a pre-written dedicated filter driver. In the device stack architecture of the operating system, this filter driver is precisely mounted at the top of the keyboard class driver stack. For example, in the Windows driver model, it is attached to the Kbdclass class driver. This architectural position means that the filter driver does not directly control the keyboard hardware, nor is it responsible for passing key presses to the upper-level application. Instead, it has priority to intercept and inspect all keyboard data packets flowing through the driver stack.
[0080] Finally, in the hardware interrupt interception and HID scan code extraction stage, accurate capture from underlying electrical signals to standardized protocol data is achieved. When the target key, such as the Copilot Key position to be verified, is triggered, the microcontroller inside the keyboard generates the corresponding hardware interrupt signal based on the configuration parameters just written to the EEPROM. The motherboard interrupt controller of the device to be configured captures this signal and triggers the interrupt service routine. Subsequently, the keyboard port driver reads the underlying hardware scan code. When this data is encapsulated into a standard HID report descriptor format and passed up the driver stack to the upper-layer Kbdclass driver, the pre-mounted filter driver forcibly intercepts the IRP data packet. The filter driver parses the HID report data structure, locates and extracts the actual HID scan code representing the true identity of the key.
[0081] The present invention also provides a BOM-based keyboard key function configuration device 100, which is used to execute any of the aforementioned BOM-based keyboard key function configuration methods.
[0082] Specifically, the following describes in detail the specific structure of a BOM-based keyboard key function configuration device 100 provided by an embodiment of the present invention, according to the appendix. Figure 2 As shown, the specific structure of the keyboard key function configuration device includes the following: The acquisition module is used to acquire the BOM data of the device to be configured; the BOM data includes identification information for identifying keyboard function configuration requirements; The extraction module is used to obtain feature information of preset configuration fields from the BOM data; The judgment module is used to determine whether the device to be configured meets the activation conditions of a specific button function based on the feature information. The configuration execution module is configured to generate a first configuration parameter corresponding to the specific key function if the activation condition is met, and write the first configuration parameter into the storage medium of the device to be configured; if the activation condition is not met, generate a second configuration parameter corresponding to the default key function, and write the second configuration parameter into the storage medium of the device to be configured, so as to solidify the function of the keyboard keys.
[0083] The present invention further provides a computer device, which can be used to execute the BOM-based keyboard key function configuration method in any of the above embodiments.
[0084] See Figure 3 The computer device 500 includes a processor 502, a memory, and a network interface 505 connected via a communication bus 501. The memory may include a storage medium 503 and internal memory 504.
[0085] The storage medium 503 can store the operating system 5031 and the computer program 5032. When the computer program 5032 is executed, it can cause the processor 502 to execute a BOM-based keyboard key function configuration method. The storage medium 503 can be a volatile storage medium or a non-volatile storage medium.
[0086] The processor 502 provides computing and control capabilities to support the operation of the entire computer device 500.
[0087] The internal memory 504 provides an environment for the computer program 5032 in the storage medium 503 to run. When the computer program 5032 is executed by the processor 502, the processor 502 can execute a keyboard key function configuration method based on BOM.
[0088] This network interface 505 is used for network communication, such as providing data transmission. Those skilled in the art will understand that... Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present invention and does not constitute a limitation on the computer device 500 to which the present invention is applied. The specific computer device 500 may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.
[0089] The processor 502 is used to run the computer program 5032 stored in the memory to implement the corresponding functions in the above-described BOM-based keyboard key function configuration method.
[0090] Those skilled in the art will understand that Figure 3 The embodiments of the computer device shown do not constitute a limitation on the specific configuration of the computer device. In other embodiments, the computer device may include more or fewer components than illustrated, or combine certain components, or have different component arrangements. For example, in some embodiments, the computer device may include only memory and a processor. In such embodiments, the structure and function of the memory and processor are different from those shown. Figure 3 The embodiments shown are consistent and will not be described again here.
[0091] It should be understood that, in this embodiment of the invention, the processor 502 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.
[0092] In another embodiment of the invention, a computer-readable storage medium is provided. This computer-readable storage medium may be volatile or non-volatile. The computer-readable storage medium stores a computer program, wherein when executed by a processor, the computer program implements the steps included in the above-described BOM-based keyboard key function configuration method.
[0093] Those skilled in the art will readily understand that, for the sake of convenience and brevity, the specific working processes of the devices, apparatuses, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this invention.
[0094] In the several embodiments provided by this invention, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Units with the same function may be grouped into one unit. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.
[0095] Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interface, device or unit, or it may be an electrical, mechanical or other form of connection.
[0096] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments of the present invention, depending on actual needs.
[0097] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0098] The integrated units described above can be implemented in either hardware or software functional units.
[0099] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a computer-readable storage medium and includes several instructions to cause a computer device (which may be a personal computer, a data transmitter, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned computer-readable storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks.
[0100] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.
Claims
1. A method for configuring keyboard key functions based on BOM, characterized in that, The method includes: Obtain the BOM data of the device to be configured; the BOM data includes identification information used to identify keyboard function configuration requirements; Obtain the feature information of the preset configuration fields from the BOM data; Based on the feature information, determine whether the device to be configured meets the activation conditions for a specific button function; If the activation conditions are met, a first configuration parameter corresponding to the specific button function is generated, and the first configuration parameter is written into the storage medium of the device to be configured. If the activation conditions are not met, a second configuration parameter corresponding to the default key function is generated and written into the storage medium of the device to be configured to solidify the function of the keyboard keys. The feature information includes operating system type information or sales region information; The step of determining whether the device to be configured meets the activation conditions for a specific button function based on the feature information includes: Identify whether the feature information contains a preset target operating system identifier; If the target operating system identifier is included, then the activation conditions for the specific key function are met. If the target operating system identifier is not included, it is determined that the activation conditions for the specific key function are not met. The step of writing the first configuration parameter into the storage medium of the device to be configured, or writing the second configuration parameter into the storage medium of the device to be configured, includes: Based on the generated first or second configuration parameters, a preset writing tool is invoked to generate the corresponding writing instruction; the writing instruction is encapsulated and transmitted in string format, and a specific command prefix is defined inside the writing instruction, which includes the program name being invoked, the operation parameter identifier, and the core data payload area; By executing the write instruction, the configuration data is burned into the non-volatile memory of the device to be configured.
2. The keyboard key function configuration method based on BOM according to claim 1, characterized in that, The write instruction is a string containing a status identifier; When the activation condition is met, the status identifier is configured to a first value; When the activation condition is not met, the status identifier is configured to a second value.
3. The keyboard key function configuration method based on BOM according to claim 1, characterized in that, After determining whether the device to be configured meets the activation conditions for a specific button function based on the feature information, the method further includes: Read the keyboard hardware model information of the device to be configured; Determine whether the keyboard supports key function reconfiguration based on the keyboard hardware model information; If supported, then execute the step of generating the first configuration parameter corresponding to the specific key function or the step of generating the second configuration parameter corresponding to the default key function.
4. The keyboard key function configuration method based on BOM according to claim 3, characterized in that, The step of determining whether the keyboard supports key function reconfiguration based on the keyboard hardware model information includes: Obtain the setting parameter value corresponding to the keyboard hardware model; If the set parameter value is the first preset value, it is determined that button function reconfiguration is not supported; If the set parameter value is the second preset value, then it is determined that the button function reconfiguration is supported.
5. The keyboard key function configuration method based on BOM according to claim 1, characterized in that, After writing the first configuration parameter or the second configuration parameter to the storage medium of the device to be configured, the method further includes: Read the current configuration data from the storage medium; The current configuration data is compared with the pre-stored standard data; If they match, the configuration is considered successful and a pass signal is output. If there is a discrepancy, the configuration is deemed to have failed and an alarm signal is output.
6. A keyboard key function configuration device based on BOM, characterized in that, The device is used to execute the BOM-based keyboard key function configuration method as described in any one of claims 1-5, and the device comprises: The acquisition module is used to acquire the BOM data of the device to be configured; the BOM data includes identification information for identifying keyboard function configuration requirements; The extraction module is used to obtain feature information of preset configuration fields from the BOM data; The judgment module is used to determine whether the device to be configured meets the activation conditions of a specific button function based on the feature information. The configuration execution module is configured to generate a first configuration parameter corresponding to the specific key function if the activation condition is met, and write the first configuration parameter into the storage medium of the device to be configured; if the activation condition is not met, generate a second configuration parameter corresponding to the default key function, and write the second configuration parameter into the storage medium of the device to be configured, so as to solidify the function of the keyboard keys.
7. A computer device, characterized in that, The computer device includes a processor, a network interface, a memory, and a communication bus, wherein the processor, network interface, and memory communicate with each other through the communication bus; Memory, used to store computer programs; When a processor executes a program stored in memory, it implements the steps of the BOM-based keyboard key function configuration method according to any one of claims 1-5.
8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the BOM-based keyboard key function configuration method as described in any one of claims 1-5.
Citation Information
Patent Citations
Programmable logic device configuration method and hardware board card
CN121979583A
Standardized test keyboard and standardized test keyboard group
CN212276370U