Device initialization method, electronic device and readable storage medium
By matching device identification information and communication addresses in the device configuration file, combined with Mutex lock, the problem of electronic devices accurately detecting and initializing electronic devices during the boot stage is solved, and detection accuracy and resource utilization are improved.
Patent Information
- Application Number
- CN202310716499.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-06-15
- Publication Date
- 2025-01-03
- Estimated Expiration
- 2043-06-15
AI Technical Summary
The prior art is difficult to accurately detect and initialize the installed electronic devices during the electronic equipment boot stage, resulting in cumbersome detection process, high resource consumption, and possible misjudgment.
By obtaining the device's identification information and communication address in the device configuration file, matching the stored identification information, initializing the configuration after confirming that the communication is normal, combining Mutex locks to improve detection accuracy and avoid misjudgment.
The device detection process is simplified, detection accuracy is improved, resources are saved, resource waste and misjudgment are avoided, and initialization time is shortened.
Smart Images

Figure CN117707628B_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the technical field of intelligent terminals, and in particular to a device initialization method, an electronic device and a readable storage medium. Background Art
[0002] Electronic devices can be equipped with the same type of electronic devices provided by different suppliers. By presetting the code information of the same type of electronic devices from multiple different suppliers on the software baseline of the electronic device (i.e., the stable version of the software document or source code in the electronic device), the electronic device can be compatible with the same type of electronic devices provided by different suppliers. During the startup phase of the electronic device, such as the first startup, the electronic device needs to initialize and configure the electronic devices inside it, that is, call the code information corresponding to the electronic device to initialize and configure the electronic device so that the corresponding function of the electronic device in the electronic device can be used normally. Therefore, it is necessary to detect the electronic device to determine which specific electronic device among multiple electronic devices of the same type the electronic device is actually equipped with, and then initialize and configure the electronic device based on the determined code information of the electronic device.
[0003] For example, by presetting the code information of color temperature sensors S1-S5 provided by different suppliers on the software baseline of the mobile phone, the mobile phone can be equipped with (i.e. compatible with) any one of the color temperature sensors S1-S5. Among them, if the mobile phone is actually equipped with color temperature sensor S1. During the startup phase of the electronic device, it is necessary to detect the color temperature sensor of the mobile phone and accurately detect the color temperature sensor S1 actually installed on the mobile phone, and then initialize the configuration of the color temperature sensor S1 based on the code information of the color temperature sensor S1, so that the corresponding functions in the mobile phone can be used normally, for example, it can include adjusting the shooting parameters of the camera in the mobile phone during the shooting process, or adjusting the color of the captured video or image, etc.
[0004] How to accurately detect the electronic devices actually installed in electronic equipment is a problem that needs to be solved at present. Summary of the invention
[0005] To solve the above problems, embodiments of the present application provide a device initialization method, an electronic device, and a readable storage medium.
[0006] In a first aspect, an embodiment of the present application provides a device initialization method, which is applied to an electronic device, and the method includes: detecting that the electronic device is started; obtaining first identification information and a first communication address corresponding to a first device to be initialized based on a device configuration file of the electronic device; determining the first identification information to match the second identification information of the stored second device; obtaining first initialization information corresponding to the second device; and initializing and configuring the first device based on the first initialization information when it is determined that the communication of the second device is normal based on the first communication address.
[0007] It can be understood that the device configuration file of the electronic device can be a device tree file, and the device tree file can be configured with various identification information (such as device name) and various communication addresses of the electronic devices that can be configured in the current project, such as I2C addresses, etc. The identification information can form an identification information list, and the communication addresses can form a communication address list.
[0008] It can be understood that the first identification information may be an electronic device name in a name list of first devices obtained based on the configuration file, and the first communication address may be an electronic device address in an address list of first devices obtained based on the configuration file.
[0009] It can be understood that the first component may be an electronic component actually mounted on the electronic device.
[0010] It can be understood that the identification information of the second device may be identification information of one of the mountable electronic devices corresponding to the first device pre-stored in the electronic device.
[0011] It can be understood that the device tree file limits the configuration information of the current electronic device. Therefore, when a device name does not exist in the device tree file, it will not be configured in the current electronic device. For example, the first device is a color temperature sensor, and one of the color temperature sensor devices that can be installed is named A2. The device names obtained based on the device tree file are A3 and A4, which proves that the electronic device corresponding to A2 cannot exist in the electronic device. Therefore, there is no need to perform subsequent detection on the color temperature sensor named A2, such as no need to perform subsequent detection on whether the communication is normal, which can effectively simplify the detection process and save resources.
[0012] In a possible implementation of the first aspect above, first identification information and a first communication address corresponding to a first device to be initialized are obtained based on a device configuration file of the electronic device; including: obtaining an identification information set and a communication address set corresponding to the first device to be initialized based on a device tree file; the first identification information is identification information in the identification information set, and the first communication address is a communication address in the communication address set.
[0013] In a possible implementation of the first aspect above, it is determined that the communication of the second device is normal based on the first communication address; including: reading the third identification information of the first device based on the first device identification function corresponding to the second device and the first communication address; when the third identification information matches the second identification information of the second device, it is determined that the communication of the second device is normal.
[0014] It can be understood that the third identification information of the first device can be read based on the first device identification function, such as the get_chip_id function. When the device name corresponding to the actually mounted first device can be read and the read third identification information of the first device matches the device name in the corresponding function pointer group obtained based on the device tree file, it can be determined that the first device currently detected is an actually mounted electronic device and the communication is normal.
[0015] It is understandable that in some embodiments, some compatible electronic devices may have the same wiring method, for example, device A and device B have the same wiring method, resulting in the I2C communication conditions of device A and device B being substantially the same. Therefore, when the electronic device actually carried by the electronic device is device B, when detecting device A, it may also detect that the communication condition is normal, resulting in the misjudgment that device A is the actual carried device, resulting in a misjudgment problem. The method provided in the embodiment of the present application, when performing device detection, not only simply determines whether the I2C communication is abnormal, but also determines whether the name of the electronic device matches. Based on the above two aspects of judgment, the accuracy of detection can be improved, avoiding the misjudgment situation that exists in some embodiments.
[0016] In a possible implementation of the first aspect above, the electronic device stores a first function pointer group corresponding to the second device, the first function pointer group including second identification information, first initialization information and a first device identification function; corresponding to determining the first identification information of the first device, matching it with the stored second identification information, establishing an association between the first communication address and the first function pointer group.
[0017] It can be understood that the electronic device stores a first function pointer group corresponding to the second device, and when the first identification information of the first device matches the stored second identification information of the second device, the first communication address is assigned to the first function pointer group for storage.
[0018] In a possible implementation of the first aspect above, initializing and configuring the first device based on the first initialization information includes: determining identification information of the first function pointer group corresponding to the second device; and initializing and configuring the first device by calling the first initialization information based on the identification information of the first function pointer group.
[0019] It can be understood that the identification information of the first function pointer group can be the subscript of the function pointer group mentioned in the embodiment of the present application, such as a digital identification.
[0020] It can be understood that based on the above scheme, the actual mounted device can be initialized and configured by directly matching the corresponding function function in the function pointer group according to the array corresponding to the identified actual mounted device, thereby shortening the loading time caused by the need to re-search and match the corresponding function function when there are multiple alternative electronic devices on the same baseline and multiple function functions are available.
[0021] In a possible implementation of the first aspect above, the first initialization information includes a detection function, a removal function, a power suspend function, a power restore function, and a device identification function.
[0022] In a possible implementation of the first aspect above, the electronic device stores identification information of multiple mountable devices corresponding to a first device in the electronic device; determines the first identification information to match the stored second identification information of the second device; including: determining the second identification information matching the first identification information from the identification information of the multiple mountable devices.
[0023] In a second aspect, an embodiment of the present application provides an electronic device, including a memory for storing instructions; and a processor for executing instructions so that the device initialization method provided by the above-mentioned first aspect and various possible implementations of the first aspect is implemented.
[0024] In a third aspect, an embodiment of the present application provides a readable storage medium having instructions stored thereon, which, when executed on an electronic device, enables the device initialization method provided by the above-mentioned first aspect and various possible implementations of the first aspect to be implemented.
[0025] In a fourth aspect, an embodiment of the present application provides a computer program product, including instructions, which, when executed on an electronic device, enable the electronic device to implement the device initialization method provided by the above-mentioned first aspect and various possible implementations of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS
[0026] Figure 1 According to some embodiments of the present application, a schematic diagram of a scenario of mobile phone startup configuration is shown;
[0027] Figure 2 According to some embodiments of the present application, a schematic flow chart of a device initialization method is shown;
[0028] Figure 3 According to some embodiments of the present application, a schematic flow chart of a device initialization method based on a mutex lock is shown;
[0029] Figure 4A According to some embodiments of the present application, a schematic diagram of a system architecture of an electronic device is shown;
[0030] Figure 4B According to some embodiments of the present application, a schematic diagram of a system architecture of another electronic device is shown;
[0031] Figure 4C According to some embodiments of the present application, a schematic diagram of a system architecture of another electronic device is shown;
[0032] Figure 4D According to some embodiments of the present application, a schematic diagram of a system architecture of another electronic device is shown;
[0033] Figure 5 According to some embodiments of the present application, a flow chart of another device initialization method is shown;
[0034] Figure 6 According to some embodiments of the present application, a specific flow chart of a device initialization method is shown;
[0035] Figure 7 According to some embodiments of the present application, a schematic diagram of an electronic device 10 is shown. DETAILED DESCRIPTION
[0036] Illustrative embodiments of the present application include, but are not limited to, a device initialization method, an electronic device, and a readable storage medium.
[0037] It can be understood that the embodiments of the present application can be applied to any electronic device that needs to perform device detection, including but not limited to mobile phones, tablet computers, wearable devices (such as smart watches, smart bracelets, etc.), vehicle-mounted devices, Internet of Things devices, smart home devices, etc. For ease of description, the technical solution of the embodiments of the present application is introduced below using an electronic device mobile phone as an example.
[0038] It can be understood that the embodiments of the present application can be applied to detect any electronic device that needs to be detected and configured by an electronic device, including but not limited to proximity light devices, ambient light devices and laser devices (direct time-of-flight, Dtof) in electronic devices. For ease of description, the technical solution of the present application is introduced below by taking the color temperature sensor of an electronic device in a mobile phone as an example.
[0039] To facilitate understanding, the terms involved in the embodiments of the present application are first introduced.
[0040] (1) Software Baseline
[0041] A software baseline is a stable version of a software code document or source code in an electronic device. During the software development process, when new requirements are generated for the software and frequent updates are required, unknown errors may occur. At this time, the system can be rolled back to the previous software baseline so that a stable version can be used to meet the needs of device testing and other requirements, while fixing existing problems. In an embodiment of the present application, for example, the code information of color temperature sensors S1-S5 can be preset in the software baseline, so that when the color temperature sensor S1 actually installed in the electronic device is detected, it can be initialized and configured based on the code information of the color temperature sensor S1.
[0042] (2) Kernel target module
[0043] The kernel object module (KO) is a loadable module in the kernel layer. The KO module includes driver code and can dynamically add functions to the kernel layer. When the electronic device is running, the kernel functions can be expanded or reduced by loading or unloading the KO module. The KO module can usually include drivers, file systems, network protocol stacks, and other kernel functions. The functions of the kernel layer can be expanded or improved by writing KO modules.
[0044] (3) Device Tree
[0045] Device tree source (DTSI) is a data structure that describes hardware. The device tree consists of a series of named nodes and attributes. Hardware devices can use the device tree without having to perform a lot of redundant coding in the kernel layer. Attributes refer to names and values that appear in pairs.
[0046] In order to facilitate the understanding of the technical solution of this application, Figure 1 Taking the scenario shown as an example, the application scenario of the device initialization method is introduced. Figure 1 According to some embodiments of the present application, a schematic diagram of performing power-on initialization configuration of a mobile phone 10 is shown.
[0047] refer to Figure 1 , the user can control the mobile phone 10 to start up and configure by long pressing the power button 11 of the mobile phone 10. When the user long presses the power button 11 of the mobile phone 10 for a preset time, the interactive interface of the mobile phone 10 displays a prompt box 101, prompting the user to confirm whether to activate and configure the mobile phone 10. The user can confirm to start activating and configuring the mobile phone 10 by clicking the confirmation box 1011. During the startup and configuration process of the mobile phone 10, the mobile phone 10 can detect the electronic devices used inside it, such as the color temperature sensor, to determine the information of the color temperature sensor it carries. The information of the color temperature sensor may include the name information, model information, communication address information, etc. of the color temperature sensor.
[0048] It can be understood that the color temperature sensor is a sensor used to detect the color or color temperature of a light source. It can be used to transmit a corresponding electrical signal according to the color or color temperature of the light source, so that the corresponding binary information after the electrical signal is converted can be recognized by a machine.
[0049] In some embodiments, the color temperature sensor can automatically adjust the screen color temperature of the electronic device according to the color temperature of the environment, and can be used to detect the color temperature of the environment when the electronic device is shooting, so that the color of the captured video or image is more accurate, or to perform color calibration on the image, etc., which is not limited here.
[0050] Understandably, Figure 1 The power-on method of the mobile phone 10 shown is only an example. In other embodiments, the power-on of the mobile phone 10 may be controlled by other buttons or button combinations of the mobile phone 10, which is not limited here.
[0051] As mentioned above, electronic devices can support the installation of electronic devices of the same type provided by different suppliers. The code information of the same type of electronic devices from multiple different suppliers can be preset on the software baseline of the electronic device, so that the electronic device can be compatible with the same type of electronic devices provided by different suppliers. During the startup phase of the electronic device, the electronic device needs to initialize and configure the electronic devices inside it, that is, call the code information corresponding to the electronic device to initialize and configure the electronic device so that its corresponding functions can be used normally. Therefore, it is necessary to detect the electronic device to determine which specific electronic device of the same type is actually installed in the electronic device, and then initialize and configure the electronic device based on the determined code information of the electronic device.
[0052] In some embodiments of the present application, the electronic devices can be detected in turn through the detection function, and whether the electronic device is a color temperature sensor actually installed in the electronic device can be determined by judging whether the I2C address communication of the electronic device is normal. However, this solution needs to drive the installable device to judge the I2C address communication status before determining whether it is an actually installed device, and each device needs to be judged, resulting in process waste and excessive resource consumption.
[0053] For example Figure 2 A schematic diagram of a device initialization method is shown. For ease of understanding, the electronic device is a color temperature sensor as an example for explanation, and the specific process includes:
[0054] S201: Start the detection mode (Mod_probe).
[0055] It can be understood that the device detection (Mod_probe) function is a driver command of Linux, which can load a specified single module or a group of modules into the kernel layer. In this application, the kernel layer can call the device detection (Mod_probe) function to execute the subsequent process to load the color temperature sensor into the KO module and communicate with the upper layer.
[0056] S202: Initialize the public entry function (Mod_init) of the KO module.
[0057] It can be understood that each driver has the statement Mod_init, which means that the driver command is automatically executed when the system starts, that is, the public population function Mod_init is defined.
[0058] In some embodiments, the driver code corresponding to each electronic device can be encapsulated in the KO module in the Kernel. When performing device detection, the public entry function Mod_init of the KO module can be initialized to define functions related to driver initialization and exit.
[0059] It is understandable that the kernel header file of the kernel layer needs to be included in the compilation of the Linux kernel, and the driver code of the kernel layer KO module needs to include the following three header files: #include<linux / init.h> 、#include<linux / module.h> 、#include<linux / kernel.h> Among them, init.h defines the functions related to driver initialization and exit; kernel.h defines frequently used function prototypes and macro definitions; module.h defines functions and variables related to kernel modules.
[0060] S203: Calling the i2c_add_driver function of the i-th color temperature sensor based on the common entry function.
[0061] In some embodiments, the i2c_add_driver function of the current i-th color temperature sensor can be called based on the public entry function, so that the current i-th color temperature sensor can be registered in the device list of the KO module. It can be understood that the device list is a collection of compatible electronic devices in the kernel layer.
[0062] S204: calling the real_probe function of the i-th color temperature sensor to drive the current color temperature sensor.
[0063] In some embodiments, the real_probe function of the current color temperature sensor may be called, that is, the current color temperature sensor is prepared to be driven, so that the current color temperature sensor may be bound to the public node entry of the kernel layer.
[0064] S205: Determine whether the I2C communication of the current color temperature sensor is normal.
[0065] In some embodiments, when the current color temperature sensor is driven, it is determined whether the I2C communication of the current color temperature sensor is normal. If the communication is normal, the process goes to step S206 to bind the color temperature sensor with normal communication to the public node entry in the kernel layer. If the communication is abnormal, the process goes to step S207 to store the color temperature sensor with abnormal communication as a virtual device in the system kernel layer.
[0066] S206: Bind the color temperature sensor with normal communication to the public node entrance in the kernel layer.
[0067] In some embodiments, if the communication of the current color temperature sensor is normal, the color temperature sensor with normal communication is bound to the public node entry in the kernel layer, so that the current color temperature sensor can be connected to the upper layer communication based on the kernel layer driver.
[0068] S207: The color temperature sensor with abnormal communication is stored in the system as a virtual device.
[0069] In some embodiments, if the communication of the current color temperature sensor is abnormal, the color temperature sensor with the abnormal communication will be stored in the system as a virtual device.
[0070] S208: Function returns, i=i+1.
[0071] It can be understood that no matter whether the communication of the current color temperature sensor is normal or not, it is necessary to return to step S202 to continue to execute the next detection process of the (i+1) th color temperature sensor.
[0072] As mentioned above, this solution needs to be run to drive the mountable device to determine whether it is an actual mounted device by judging the I2C address communication status, and each device needs to be judged, resulting in process waste and excessive resource consumption.
[0073] In other embodiments, a mutual exclusion (Mutex) lock can be added to determine whether it is a color temperature sensor actually installed in the electronic device. When each device is detected, a mutex lock is added, and then the flag bit of the mutex lock is first determined. If the flag bit is not empty, it means that the detection has been successful. If the flag bit is empty, it means that no device has been successfully detected yet, and the I2C address of the electronic device is called in sequence to determine the I2C address communication status. Based on the I2C address communication status, it is determined whether the corresponding color temperature sensor is the color temperature sensor actually installed in the electronic device. In this solution, by adding a flag bit to determine the Mutex lock before determining the I2C communication, the next color temperature sensor is detected after the detection of one color temperature sensor is completed, avoiding the interruption of the detection process of the current color temperature sensor by continuing to detect other sensors when the current color temperature sensor has not been detected, resulting in the cumbersome process of needing to detect again, but it is still necessary to execute the above in sequence. Figure 2 The I2C communication judgment process of all the color temperature sensors mentioned results in process waste and excessive resource consumption.
[0074] refer to Figure 3 , Figure 3 A schematic diagram of a device initialization method based on a mutex lock is shown. For ease of understanding, the electronic device is a color temperature sensor as an example for explanation. The specific process includes:
[0075] S301: Start the detection mode (Mod_probe).
[0076] It can be understood that step S301 can refer to the above-mentioned step S201 and will not be repeated here.
[0077] S302: Initialize the public entry function (Mod_init) of the KO module.
[0078] It can be understood that step S302 can refer to the above step S202 and will not be repeated here.
[0079] S303: Calling the i2c_add_driver function of the i-th color temperature sensor based on the common entry function.
[0080] It can be understood that step S303 can refer to the above step S203 and will not be repeated here.
[0081] S304: calling the real_probe function of the current color temperature sensor.
[0082] It can be understood that step S304 can refer to the above-mentioned step S204 and will not be repeated here.
[0083] S305: Lock the current color temperature sensor driver process through the Mutex lock (Probe_lock).
[0084] In some embodiments, a mutual exclusion (Mutex) is added, i.e., a Mutex lock is used to probe-lock the driving process of the current color temperature sensor. That is, the driving process of the current color temperature sensor is locked, and during the driving process of the current color temperature sensor, other color temperature sensors can no longer be probed and driven.
[0085] It can be understood that the Mutex lock is a sleep lock mechanism that ensures serialization and can suspend the current process, that is, lock the current detection process. The use of the Mutex lock requires setting a flag to determine whether the Mutex lock is currently in a locked state.
[0086] S306: Determine whether the flag color_name of the Mutex lock is empty.
[0087] In some embodiments, the flag color_name of the Mutex lock is judged. When it is determined that the flag color_name is empty, it is determined that there is no color temperature sensor in the driving process, and the process goes to step S307 to call the real_probe function of the current color temperature sensor to drive the current color temperature sensor; when it is determined that the flag color_name is not empty, it is determined that a color temperature sensor has been successfully detected, and the process goes to step S310, and the I2C communication judgment of the current color temperature sensor is not executed, but the current detection process is unlocked to continue the detection process of the next color temperature sensor.
[0088] S307: calling the real_probe function of the current color temperature sensor to drive the current color temperature sensor.
[0089] In some embodiments, when it is determined that the flag color_name is empty, it is determined that no color temperature sensor is currently in the driving process, and the real_probe function of the current color temperature sensor is called based on I2C to drive the current color temperature sensor, so that the current color temperature sensor can be bound to the public node entry of the kernel layer.
[0090] S308: Determine whether the current color temperature sensor I2C communication is normal.
[0091] In some embodiments, when the current color temperature sensor is driven, it is determined whether the I2C communication of the current color temperature sensor is normal. If the communication is normal, the process goes to S309 and the flag color_name is set to indicate that the current color temperature sensor is an electronic device actually mounted on the electronic device. If the communication is abnormal, the process still goes to step S310 and the I2C communication judgment of the current color temperature sensor is not performed. Instead, the current detection process is unlocked to continue the detection process of the next color temperature sensor.
[0092] S309: Setting the flag color_name indicates that the current color temperature sensor is an electronic device actually mounted in the electronic device.
[0093] In some embodiments, it is determined that when the I2C of the color temperature sensor can communicate normally, it is determined that the current color temperature sensor is the color temperature sensor actually mounted on the electronic device, and the flag color_name is set to the corresponding identifier to indicate that a color temperature sensor has successfully detected the current color temperature sensor.
[0094] S310: Unlock the calling process of the current color temperature sensor (Probe_unlock).
[0095] In some embodiments, after the detection process of the current color temperature sensor ends, the calling process of the current color temperature sensor is unlocked through the Probe_unlock function.
[0096] In some embodiments, when it is determined that the flag bit is not empty, it indicates that a color temperature sensor is currently in the detection process or a color temperature sensor has successfully detected. The calling process of the currently successfully detected color temperature sensor can be unlocked through the Probe_unlock function.
[0097] S311: Function returns, i=i+1.
[0098] In some embodiments, after determining the color temperature sensor actually mounted on the electronic device, the color temperature sensor actually mounted can be bound to the public node entry so that it can be connected to the upper layer. Then return to step S302 to continue detecting the next color temperature sensor, that is, regardless of whether the flag bit is empty or not, and whether there is a color temperature sensor communicating normally, it is necessary to return to step S202 to continue executing the next, i.e., the detection process of the i+1th color temperature sensor.
[0099] In some embodiments, if the current color temperature sensor is not a color temperature sensor actually mounted on the electronic device, the current color temperature sensor is used as a suspended virtual device in the kernel layer, and the process returns to step S302 to continue detecting the next color temperature sensor. In some embodiments, when the flag is empty, the process directly returns to step S302 to continue detecting the next color temperature sensor.
[0100] In the above scheme, by adding a flag bit for judging the Mutex lock before judging the I2C communication, the next color temperature sensor is detected after one color temperature sensor is detected, which avoids the problem that the detection process of the current color temperature sensor is interrupted by continuing to detect other sensors when the current color temperature sensor has not been detected, resulting in the cumbersome process of needing to detect again. However, the above scheme still needs to be executed in sequence. Figure 2 The I2C communication judgment process of all the color temperature sensors mentioned results in process waste and excessive resource consumption.
[0101] In order to solve the above problems, an embodiment of the present application provides a device initialization method. First, a function pointer group (or array) of compatible electronic devices corresponding to the device to be initialized can be preset. For example, if the device to be initialized is a color temperature sensor, and there are 5 types of compatible color temperature sensors, then function pointer groups corresponding to the 5 types of color temperature sensors are preset. The function pointer group may include device identification information corresponding to each electronic device (for example, device name, I2C address, etc.), probe, remove, power suspend and power resume functions, etc.
[0102] Then, the identification information (such as device name) and I2C addresses of the electronic devices that can be configured in the current project of the electronic device can be obtained based on the DTSI device tree file corresponding to the electronic device. The device names in each function pointer group are matched based on the device names obtained from the DTSI file, and the corresponding function pointer group to be selected is obtained, and the I2C addresses corresponding to the device names obtained based on the DTSI device tree file are assigned to the corresponding function pointer group to be selected. The devices that communicate normally among the devices corresponding to the function pointer group to be selected are used as the devices actually carried by the current electronic device, and the device is initialized and configured based on the functional functions in the function pointer group to be selected.
[0103] It can be understood that the DTSI device tree file limits the configuration information of the current electronic device. Therefore, the device name that does not exist in the DTSI device tree file will not be configured in the current electronic device. For example, the device name of one of the compatible color temperature sensors corresponding to the color temperature sensor is A2, and the device names obtained based on the DTSI device tree file are A3 and A4, which proves that the electronic device corresponding to A2 cannot exist in the electronic device. Therefore, there is no need to perform subsequent detection, such as no need to detect whether the subsequent communication is normal, which can effectively simplify the detection process and save resources.
[0104] In some embodiments, the function pointer group corresponding to each electronic device may also include a key function (get_chip_id).
[0105] After determining the function pointer group to be selected, the device name of the currently actually mounted electronic device can be read based on the key function (get_chip_id) in the function pointer group to be selected. When the device name corresponding to the actually mounted electronic device can be read and the read device name matches the device name in the corresponding function pointer group to be selected, it can be determined that the currently detected mountable electronic device is the electronic device actually mounted on the electronic device and the communication is normal. The currently detected mountable electronic device is used as the electronic device actually mounted on the electronic device, and the device function binding and initialization process are performed. If the device name of the electronic device actually mounted on the electronic device cannot be read or the read device name does not match the device name of the corresponding function pointer group to be selected, that is, the currently detected mountable electronic device is not the actually mounted electronic device, then the detection of the next electronic device is performed directly.
[0106] In this way, during detection, it is not just a matter of judging whether the I2C communication is abnormal, but also whether the name of the electronic device matches. This can improve the accuracy of detection and avoid misjudgments in the prior art. The following is an explanation of the misjudgments in the prior art: It can be understood that some compatible electronic devices may have the same wiring method, for example, device A and device B have the same wiring method, resulting in the I2C communication conditions of device A and device B being essentially the same. Therefore, when the electronic device actually carried by the electronic device is device B, when detecting device A, the communication condition is also detected to be normal, resulting in the misjudgment that device A is the actual carried device.
[0107] In some embodiments, the function pointer group includes functional functions such as probe, remove, suspend and resume functions corresponding to each electronic device. After determining the actual mounted electronic device, the functional binding and initialization process of the device can be directly based on the probe function in the function pointer group. In addition, the remove function can be used to clean up the corresponding memory resources when removing the electronic device in the kernel layer; the suspend function can manage the sleep of the power management module; the resume function can manage power recovery. In this way, the functions required by the device are normalized, and the corresponding functional functions in the function pointer group can be directly matched according to the actual mounted device identified, shortening the loading time caused by the need to re-search and match the corresponding functional functions when there are multiple alternative electronic devices in the same baseline.
[0108] In order to facilitate understanding of the technical solution of the present application, the system architecture of the electronic device mentioned in the present application is described by taking the architecture of a color temperature sensor as an example.
[0109] In some embodiments, Figure 4A As shown, the system architecture of the electronic device may include a framework layer, a hardware abstraction layer, a kernel layer, and a hardware layer. Among them:
[0110] The framework layer may include a camera service unit. In some embodiments, when a user opens a camera application, the camera service may be called through the framework layer, for example, to obtain camera device properties.
[0111] The hardware abstraction layer (HAL) can include automatic exposure, automatic white balance, network control system, etc. The hardware abstraction layer is an abstraction and encapsulation of hardware devices, providing a unified access interface for the system to access different hardware devices. The HAL layer is between the framework layer and the kernel layer. The HAL layer can shield the differences between different hardware devices and provide a unified interface for the system to access hardware devices.
[0112] The hardware abstraction layer can communicate with the framework layer using the hardware abstraction layer interface definition language (HDIL). For example, the hardware abstraction layer can call functions such as automatic exposure, automatic white balance, and network control based on the notification of obtaining camera device properties in the framework layer. The hardware abstraction layer can also include an automated test tool communication protocol (MMI_apk), which can be used to provide a communication test interface for testing electronic components of electronic devices, such as providing a communication test interface for color testing of color temperature sensors in electronic devices, and providing a communication test interface for flicker testing of flicker sensors in electronic devices. The hardware abstraction layer can also include a function server, which can include a diag_client function, which can be used to provide support for the driver of the color temperature sensor, such as driving the color temperature sensor for color calibration through the diag_client function. The hardware abstraction layer can also include a sensor hardware abstraction layer.
[0113] The core layer may include a color temperature sensor driver.
[0114] The hardware layer may include different models of color temperature sensors, etc.
[0115] It can be understood that the above-mentioned framework layer, hardware abstraction layer, kernel layer and hardware layer may also include other units or modules besides the above-mentioned ones, which are not limited here.
[0116] For example, in some embodiments, Figure 4B As shown, the sensor hardware abstraction layer may include a color temperature sensor hardware abstraction layer and a flicker sensor hardware abstraction layer.
[0117] The kernel layer may include a public node entry and a color temperature sensor driver file. The driver file of the color temperature sensor in the kernel layer may include a color temperature sensor interface and code information of the color temperature sensor, etc. The color temperature sensor interface may be used to bind the color temperature sensor to the public node entry, thereby binding the color temperature sensor to the upper layer application through the public node entry. The driver file of the color temperature sensor may include driver code information, for example, the driver code information of the color temperature sensor TCS3408, the driver code information of the color temperature sensor BU27006, and the driver code information of the color temperature sensor A57341, etc. It can be understood that the above-mentioned color temperature sensor can be an ambient light sensor or a stroboscopic sensor, which is not limited here. It can be understood that in other embodiments, the driver file of the color temperature sensor may also include driver code information of other color temperature sensors other than the above-mentioned color temperature sensor, which is not limited here.
[0118] The hardware layer may be a color temperature sensor of different models, for example, the model of the color temperature sensor may be TCS3408, BU27006 or color temperature sensor A57341, etc., which is not limited here.
[0119] In some embodiments, based on Figure 4B The structure shown can realize the above-mentioned Figure 3 The method shown, for example, can call the i2c_add_driver function of the color temperature sensor TCS3408 based on the public entry function of the kernel layer, and call the real probe function of the color temperature sensor TCS3408 to drive the color temperature sensor TCS3408, and determine whether the I2C communication of the color temperature sensor TCS3408 is normal. If the communication is normal, the color temperature sensor TCS3408 can be bound to the public node entry through the color temperature sensor interface, and then the color temperature sensor TCS3408 can be functionally bound to the upper layer application through the public node entry; if the communication is abnormal, the color temperature sensor TCS3408 is stored in the kernel as a virtual device. Further, continue to detect sensors such as the color temperature sensor BU27006 or A57341 until all color temperature sensors are detected.
[0120] However, in the above scheme, the I2C communication judgment process of all color temperature sensors needs to be executed in sequence, that is, all color temperature sensors need to be detected. Even if a color temperature sensor has been successfully detected as a color temperature sensor actually installed in the electronic device, other color temperature sensors still need to be detected, resulting in process waste and excessive resource consumption.
[0121] In addition, in the above scheme, each electronic device called will be registered in the power management module, causing other electronic devices that are not actually installed in the electronic device to become virtual devices in the power management module, and then causing the virtual device to be called every time the power management module is suspended and resumed, resulting in a waste of resources.
[0122] In some embodiments, to solve the above problems, Figure 4C As shown, a device detection and function binding module can be added in the kernel layer, so that after the actual color temperature sensor is correctly detected through the device detection and function binding module in the color temperature sensor interface, the actual color temperature sensor can be bound to the upper-layer application through the public node entrance.
[0123] Compared with the above Figure 4B The color temperature sensor interface in Figure 4C The color temperature sensor interface may include a device detection and function binding module. The device detection and function binding module can realize that after correctly detecting the color temperature sensor actually mounted on the electronic device, the color temperature sensor actually mounted on the electronic device communicates with the upper layer through the public node entrance and performs function binding, etc., while the color temperature sensor not actually mounted on the electronic device will not be directly registered to the power management module through the public node entrance, thereby avoiding the existence of suspended virtual devices in the power management module, causing the power management module to repeatedly suspend and resume the virtual devices, thereby solving the resource waste problem mentioned in the above solution.
[0124] In addition, when performing device detection based on the device detection and function binding module, the I2C address read from the DTSI device tree file can be assigned to the function pointer group corresponding to each electronic device that can be carried, wherein the function pointer group includes the device name (e.g., device id) and the key function (get_chip_id). Then, the id of the actual electronic device carried is read based on the corresponding I2C address through the key function (get_chip_id) corresponding to the currently detected electronic device. When the id corresponding to the actual electronic device can be read and the read id matches the id in the current function pointer group, it can be judged that the currently detected electronic device is the actual electronic device carried and the communication is normal, and the currently detected electronic device is used as the actual electronic device carried, and the device function binding and initialization process is performed. When the id corresponding to the actual electronic device carried can be read but the read id does not match the id in the current function pointer group, the currently detected electronic device is not the actual electronic device carried, and the next electronic device is detected. Based on this, when performing device detection, it is not just a simple judgment whether the I2C communication is abnormal, but also whether the name of the electronic device matches. Based on the above two aspects of judgment, the accuracy of detection can be improved and the misjudgment situation existing in some implementation plans can be avoided.
[0125] In some schemes, compared with the embodiment of the present application that provides an abstract public node entrance for the sensor in the kernel layer, some schemes do not adopt an abstract public node entrance, but each electronic device has a corresponding driver and node entrance, and then a public sensor interface is set in the hardware abstraction layer of the sensor to achieve unified interface. However, the above method has obvious defects, namely, poor compatibility with multiple devices. When using alternative electronic devices provided by different suppliers, it is necessary to expand functions in the kernel layer and the hardware abstraction layer, and the compatibility is not high.
[0126] For example Figure 4D As shown, Figure 4D The diagram shows an interface diagram of a color temperature sensor. It can be seen that the color temperature sensor TMF882 needs to communicate with the hardware abstraction layer of the color temperature sensor TMF882 through the TMF882 node entry; the color temperature sensor VL5311 needs to communicate with the hardware abstraction layer of the color temperature sensor VL5311 through the VL5311 node entry. That is, each color temperature sensor needs to be bound to the upper layer through its corresponding color temperature sensor interface and node entry, and the compatibility of each interface and node entry is not high.
[0127] The device initialization method provided in the embodiment of the present application is described in detail below. Figure 5 , Figure 5A schematic diagram of a device initialization method is shown. For ease of understanding, the electronic device is a color temperature sensor as an example for explanation, and the specific process includes:
[0128] S501: Configure a list of electronic device names and an I2C address of each electronic device in the current project in the DTSI device tree file.
[0129] It can be understood that the DTSI device tree file configures various identification information (such as device names) and various communication addresses of electronic devices that can be configured in the current project, such as I2C addresses, etc. The identification information can form a device name list, and the communication addresses can form a communication address list.
[0130] In some embodiments, the name of the electronic device can be configured in the DTSI device tree file to match the name of the electronic device in the driver code when detecting the electronic device. And the I2C address of each electronic device in the current project can be configured in the DTSI device tree file to determine the communication status of the electronic device based on its I2C address after the electronic device name is matched. It can be understood that the device name that does not exist in the DTSI device tree file will not be configured in the current electronic device. For example, the name of one of the color temperature sensor devices that can be installed is A2, and the device names obtained based on the DTSI device tree file are A3 and A4, which proves that the electronic device corresponding to A2 cannot exist in the electronic device. Therefore, there is no need to perform subsequent detection, such as no need to detect whether the subsequent communication is normal, which can effectively simplify the detection process and save resources.
[0131] S502: Read the name of the electronic device and the corresponding I2C address in the KO driver of the kernel layer, and assign the I2C address read in the DTSI device tree file to a predefined function pointer group to form a device function list for detecting the electronic device.
[0132] In some embodiments, the function pointer group may refer to a function pointer group, which is pre-defined in the compilation stage. The function pointer group is essentially a structure array. Each function pointer group includes the name, i2c address and function function of the corresponding electronic device that can be mounted. The function function may include: get_chip_id, probe, remove, suspend and resume functions, etc.
[0133] In some embodiments, each function pointer group may correspond to an array identifier, such as an array subscript in digital form.
[0134] During actual detection, the name of the electronic device and the corresponding I2C address are read in the KO driver of the kernel layer, and the device name in each array is matched based on the device name obtained from the DTSI device tree file, and the corresponding function pointer group to be selected is obtained, and the I2C address corresponding to the device name obtained based on the DTSI device tree file is assigned to the register address (reg-addr) of the corresponding function pointer group to be selected. The device with normal communication in the electronic device corresponding to the function pointer group to be selected is used as the device actually carried by the current electronic device, and the device is initialized and configured based on the function function in the function pointer group to be selected. For example, the electronic device can support the carrying of devices A1-A5, which correspond to their respective function pointer groups, and the subscripts of each function pointer group can be 1-5; further, based on the devices A3 and A4 parsed from the DTSI device number. The name of each device in the devices A1-A5 is matched with the two device names parsed from the device tree respectively. When the names match, the I2C address corresponding to the matched device is assigned to the corresponding function pointer group for storage, and then the matching device can be initialized and configured based on the function in the function pointer group corresponding to the matched device.
[0135] It can be understood that the device function list may include the name of the electronic device, the i2c address and the function function. For example, the function function may include: get_chip_id, probe, remove, suspend and resume, etc.
[0136] It can be understood that polling refers to determining in sequence whether the name of the color temperature sensor in the currently polled function pointer group matches the name of the color temperature sensor in the color temperature sensor name list (color_sensor_list). If a successful match is found, polling is terminated and the I2C address corresponding to the color temperature sensor is stored in the function pointer group reg-addr; if a match is not found, the next color temperature sensor is determined to match the array.
[0137] S503: Determine the name match and I2C communication status of the electronic device based on the get_chip_id function to confirm the electronic device actually installed in the current electronic device.
[0138] It can be understood that the get_chip_id function can be used to determine whether the name of the currently detected electronic device matches and whether the I2C communication is normal.
[0139] In some embodiments, the id (name) of the actually mounted electronic device can be read based on the corresponding I2C address through the key function (get_chip_id) corresponding to the currently detected mountable device. When the id can be read and the read id matches the id in the function pointer group, it can be determined that the mountable electronic device being detected is the actually mounted electronic device and the communication is normal, and the currently detected mountable electronic device is used as the actually mounted electronic device.
[0140] In some embodiments, the return value can be monitored to confirm whether the currently detected electronic device is the electronic device actually carried by the electronic device. For example, when the return value is "true", it is determined that the currently detected electronic device is the electronic device actually carried by the electronic device, and the array index of the function pointer group corresponding to the current electronic device is saved.
[0141] S504: Based on the determined array index corresponding to the electronic device actually mounted on the electronic device, call the probe function corresponding to the electronic device actually mounted on the electronic device to perform function binding of the electronic device.
[0142] In some embodiments, when the get_chip_id function determines that the name of the current color temperature sensor matches and the I2C communication is normal, the current color temperature sensor driver (color_driver_ops) array instance is saved, that is, the array index is saved. For example, if it is determined that the electronic device is equipped with the current color temperature sensor TCS3408, and the corresponding color_driver_ops array index is 3, then the array 3 of the current color temperature sensor TCS3408 is saved, and the color temperature sensor TCS3408 is called and driven based on the function in the array 3, that is, the successfully detected color temperature sensor is bound to the color temperature sensor interface through the device detection and function binding module, and the successfully detected color temperature sensor is bound to the public node entry through the color temperature sensor interface, and the function binding and initialization of the color temperature sensor TCS3408 and the upper application are realized through the public node entry.
[0143] In some embodiments, when the system loads a module or creates an instance for the module, for example, when the KO module saves the array of the color temperature sensor TCS3408, the system will automatically allocate memory space for the color temperature sensor TCS3408 to the KO module, and after allocating the memory, automatically initialize the environment variables, and then use the environment variables to initialize the hardware, start the operating system, etc.
[0144] In some embodiments, when the color temperature sensor TCS3408 fails to detect, the device detection and function binding module will not bind the color temperature sensor TCS3408 to the color temperature sensor interface, that is, it will not be bound to the public node entry and the upper layer for function binding.
[0145] Based on the above method, the actual mounted device can be initialized and configured by directly matching the corresponding function in the function pointer group according to the array corresponding to the identified actual mounted device, thus shortening the loading time caused by the need to re-search and match the corresponding function functions when there are multiple alternative electronic devices in the same baseline and multiple function functions are available.
[0146] And in some embodiments, the function pointer group also includes functional functions such as probe, remove, suspend and resume functions corresponding to each electronic device. After determining the actual mounted electronic device, the functional binding and initialization process of the device can be directly based on the probe function in the function pointer group. In addition, the remove function can be used to clean up the corresponding memory resources when removing the electronic device in the kernel layer; the suspend function can manage the sleep of the power management module; the resume function can manage the power recovery. In this way, the functions required by the device are normalized, and the corresponding functional functions in the function pointer group can be directly matched according to the actual mounted device identified, which shortens the loading time caused by the need to re-match the corresponding functional functions when there are multiple alternative electronic devices in the same baseline and multiple functional functions are available.
[0147] In addition, in the embodiment of the present application, by configuring the information of multiple electronic devices that may be used to obtain the detection results in the DTSI device tree file, the global electronic device array is innovatively adopted to dynamically obtain the configuration information of the electronic device, and confirm the actual electronic device when detecting the electronic device, thereby realizing dynamic electronic device identification. After correctly detecting the electronic device actually carried by the electronic device, there is no need to detect other electronic devices again, which greatly improves the process redundancy problem and improves the detection efficiency.
[0148] In addition, color temperature sensors that are not actually mounted on electronic devices will not be directly registered in the power management module through the public node entrance, so as to avoid the existence of suspended virtual devices in the power management module, causing the power management module to repeatedly suspend and resume the virtual devices, thus solving the resource waste problem mentioned in the above solution.
[0149] The specific process of the device initialization method provided by this application is described below.
[0150] refer to Figure 6 , Figure 6 A schematic diagram of a specific process of a device initialization method is shown. For ease of understanding, the electronic device is a color temperature sensor as an example for explanation, and the specific process includes:
[0151] S601: Initialize the common entry function (Mod_init).
[0152] In some embodiments, each driver program has a Mod_init statement, which indicates that the driver command is automatically executed when the system starts, that is, a public population function Mod_init is defined.
[0153] S602: Initialize the color_driver_ops array.
[0154] In some embodiments, the color_driver_ops array is initialized, and the color_driver_ops array includes the name of the color temperature sensor supported in the driver code compiled by the kernel layer, the I2C communication address, the function function, etc. Among them, the function function may include a probe detection function, a remove removal detection function, a suspend power suspension function, and a resume power recovery function, etc.
[0155] For example, if there are five color temperature sensors that can be installed, five function pointer groups can be set. For example, the function pointer group can include the name of the color temperature sensors S1-S5, the I2C communication address, the function function, etc. Among them, the function function can include the probe detection function, the remove removal detection function, the suspend power suspension function and the resume power recovery function, etc. It can be understood that the array subscripts of the function pointer groups of different color temperature sensors are different. For example, the array subscripts of the color temperature sensors S1-S5 can correspond to 1-5. It can be understood that the array subscripts of different color temperature sensors can be preset to arbitrary values during the initial compilation, etc., and are not limited here.
[0156] S603: Calling the i2c_add_driver function of the i-th color temperature sensor based on the common entry function.
[0157] In some embodiments, the i2c_add_driver function of the ith color temperature sensor can be called based on the public entry function, so that each color temperature sensor can be registered in the device list of the KO module, wherein the device list is a collection of compatible electronic devices in the kernel layer.
[0158] S604: The Client pointer is judged to be null.
[0159] In some embodiments, the transmission parameters of the color temperature sensor can be judged to be empty based on the client pointer, that is, the system memory allocation and driver code information are checked to ensure that transmission parameters such as the name of the color temperature sensor, I2C communication address, key functions, etc. are not empty in the color_driver_ops array.
[0160] S605: Client->dev save.
[0161] In some embodiments, the structure corresponding to the Client->dev client is saved, that is, the color_driver_ops array is saved.
[0162] It can be understood that the color_driver_ops array includes the name, I2C communication address, function function, etc. of each color temperature sensor supported in the driver code compiled by the kernel layer, where the function function may include a probe detection function, a remove removal detection function, a suspend power suspension function, and a resume power recovery function, etc.
[0163] S606: Obtain the structure of the power management module Ido from the DTSI device tree file.
[0164] In some embodiments, the structure of the power management module Ido is obtained from the DTSI device tree file of the kernel layer. It can be understood that Ido is the power management module and can control the suspension and recovery of the power management module.
[0165] S607: Power on the power management module Ido based on the regulator-enable function.
[0166] In some embodiments, the power management module Ido is powered on by controlling the regulator-enable function.
[0167] S608: Parse the address list and name list of the color temperature sensor from the DTSI device tree file.
[0168] In some embodiments, the address list and name list of the color temperature sensor are parsed based on the DTSI device tree file. For example, the driver code of the kernel layer includes information on the supported color temperature sensors S1-S5, and the address list and name list of the color temperature sensors S1-S3 can be parsed through the DTSI device tree file.
[0169] It can be understood that the DTSI device tree file may include name information and communication address information of the electronic device, and the electronic device can be parsed based on the DTSI device tree file.
[0170] S609: Polling the array to match the name of the color temperature sensor.
[0171] In some embodiments, the identification information (e.g., color temperature sensor name) and I2C addresses of the color temperature sensor that can be configured in the current project of the electronic device can be obtained based on the DTSI device tree file corresponding to the electronic device. The color temperature sensor name in each function pointer group is matched based on the color temperature sensor name obtained from the DTSI file to obtain the corresponding function pointer group to be selected, and the I2C address corresponding to the color temperature sensor name obtained based on the DTSI device tree file is assigned to the corresponding function pointer group to be selected.
[0172] In some embodiments, the name of the color temperature sensor may be: TCS3408, BU27006, A57341, etc., which are not limited here. Based on the name of the color temperature sensor, it is determined whether the name of the color temperature sensor currently being polled matches the name of the color temperature sensor in the color temperature sensor name list (color_sensor_list). If it matches, it goes to step S610 to store the I2C address corresponding to the current color temperature sensor in the array register address (reg-addr). Otherwise, it goes to step S612 to continue polling to determine whether it matches the name of the next color temperature sensor.
[0173] S610: Store the I2C address of the matching color temperature sensor into the array reg-addr.
[0174] In some embodiments, the color temperature sensor name in each function pointer group is matched based on the color temperature sensor name obtained based on the DTSI file, the corresponding candidate function pointer group is obtained, and the I2C address corresponding to the color temperature sensor name obtained based on the DTSI device tree file is assigned to the register address reg-addr of the corresponding candidate function pointer group.
[0175] S611: Update the address list of the array.
[0176] In some embodiments, it can be understood that the function pointer group is an array, and the values assigned in the register address reg-addr of the initial array are all 0 or other default values. When it is preliminarily determined that the current color temperature sensor is a color temperature sensor that can be installed in the electronic equipment project, the array reg-addr can be updated, and the I2C communication address obtained by parsing the DTSI device tree file can be assigned to reg-addr.
[0177] S612: Update the name list of the array.
[0178] In some embodiments, it can be understood that when the name of the color temperature sensor currently polled and the color temperature sensor name list are preliminarily determined, the name corresponding to the current color temperature sensor can be updated. For example, the color temperature sensor S3 is currently detected, and the array initialized in the above step S602 is polled to determine whether the name of the current color temperature sensor matches the name of the color temperature sensor in the initialized array. If so, the name of the color temperature sensor in the current array is updated to the name of the currently matched color temperature sensor. Otherwise, the name list of the array is not updated.
[0179] It is understandable that in other embodiments, when it is determined by polling the array that the name of the array does not match the name of the current color temperature sensor, the process returns to step S609 to continue polling whether the name of the next color temperature sensor can match the name of the color temperature sensor in the array.
[0180] S613: Determine whether the communication is normal based on the get_chip_id function.
[0181] In some embodiments, the id (name) of the actually mounted electronic device can be read based on the corresponding I2C address through the key function (get_chip_id) corresponding to the currently detected mountable device. When the id can be read and the read id matches the id in the function pointer group, it can be determined that the mountable electronic device being detected is the actually mounted electronic device and the communication is normal, and the currently detected mountable electronic device is used as the actually mounted electronic device.
[0182] It can be understood that chip_id can be a code for the type of color temperature sensor. The get_chip_id function can be used to determine whether the name of the current color temperature sensor matches and whether the I2C communication is normal, and the return value is monitored to confirm whether the currently detected electronic device is the electronic device actually carried by the electronic device. For example, when the return value is "true", it is determined whether the currently detected electronic device is the electronic device actually carried by the electronic device, and the corresponding array index of the current electronic device is saved, that is, when the name of the electronic device matches and the communication is normal, go to step S615 to save the current color_driver_ops instance. Otherwise, go to step S614 to update the array index.
[0183] S614: Update the array index.
[0184] In some embodiments, when the get_chip_id function determines that the current color temperature sensor communication is abnormal, return to step S613, and continue to match the I2C communication of the next color temperature sensor based on the get_chip_id function to see if the communication is normal. If the name of the next color temperature sensor matches the name of the corresponding color temperature sensor in the array and the I2C communication is normal, the array index is updated to the array index of the color temperature sensor with normal communication.
[0185] S615: Save the current color_driver_ops instance and array index.
[0186] In some embodiments, when the get_chip_id function determines that the name of the current color temperature sensor matches and the I2C communication is normal, the current color_driver_ops array instance is saved, that is, the array index is saved. For example, if it is determined that the electronic device is equipped with the current color temperature sensor TCS3408, and the corresponding color_driver_ops array index is 3, then the array 3 of the current color temperature sensor TCS3408 is saved, and the color temperature sensor TCS3408 is called and driven based on the function in array 3, so that the color temperature sensor TCS3408 can be connected to the upper layer and realize the corresponding function.
[0187] S616: Initialize environment variables.
[0188] In some embodiments, it can be understood that the environment variable is an array of string pointers. When the system loads a module or creates an instance for the module, for example, when the array of color temperature sensor TCS3408 is saved in the KO module, the system will automatically allocate memory space for the color temperature sensor TCS3408 to the KO module, and after allocating memory, automatically initialize the environment variables, and then use the environment variables to initialize the hardware, start the operating system, etc.
[0189] S617: Call the probe function of the current color_driver_ops array.
[0190] In some embodiments, the probe function of the color_driver_ops array 3 saved above is called to detect the color temperature sensor corresponding to the color_driver_ops array 3. For example, the probe function in the saved color_driver_ops array 3 can be called, the memory resources of the color temperature sensor can be cleaned up based on the remove function, the power sleep can be managed based on suspend, and the power recovery can be managed based on resume.
[0191] Based on this, when performing device detection, it is not only judged whether the I2C communication is abnormal, but also whether the name of the electronic device matches. This can improve the accuracy of detection and avoid the situation where some compatible electronic devices may have the same wiring method, resulting in a situation where the electronic device is actually equipped with device B, and when detecting device A, the communication is detected to be normal, and device A is mistakenly judged to be the actual device installed.
[0192] And in some embodiments, the function pointer group also includes functional functions such as probe, remove, suspend and resume functions corresponding to each electronic device. After determining the actual mounted electronic device, the functional binding and initialization process of the device can be directly based on the probe function in the function pointer group. In addition, the remove function can be used to clean up the corresponding memory resources when removing the electronic device in the kernel layer; the suspend function can manage the sleep of the power management module; the resume function can manage the power recovery. In this way, the functions required by the device are normalized, and the corresponding functional functions in the function pointer group can be directly matched according to the actual mounted device identified, which shortens the loading time caused by the need to re-match the corresponding functional functions when there are multiple alternative electronic devices in the same baseline and multiple functional functions are available.
[0193] In addition, in the embodiment of the present application, by configuring the information of multiple electronic devices that may be used to obtain the detection results in the DTSI device tree file, the global electronic device array is innovatively adopted to dynamically obtain the configuration information of the electronic device, and confirm the actual electronic device when detecting the electronic device, thereby realizing dynamic electronic device identification. After correctly detecting the electronic device actually carried by the electronic device, there is no need to detect other electronic devices again, which greatly improves the process redundancy problem and improves the detection efficiency.
[0194] In addition, color temperature sensors that are not actually mounted on electronic devices will not be directly registered in the power management module through the public node entrance, so as to avoid the existence of suspended virtual devices in the power management module, causing the power management module to repeatedly suspend and resume the virtual devices, thus solving the resource waste problem mentioned in the above solution.
[0195] Figure 7 A system schematic diagram of an electronic device (taking the mobile phone 10 described in the present application as an example) provided according to some embodiments of the present application is shown.
[0196] It is understood that the structure illustrated in the embodiment of the present invention does not constitute a specific limitation on the mobile phone 10. In other embodiments of the present application, the mobile phone 10 may include more or fewer components than shown in the figure, or combine some components, or separate some components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.
[0197] The mobile phone 10 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) connector 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, a color temperature sensor 180N, etc.
[0198] The processor 110 may include one or more processing units, for example, the processor 110 may include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor (BP), and / or a neural-network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.
[0199] The processor 110 may also be provided with a memory for storing instructions and data.
[0200] The charging management module 140 is used to detect charging input from a charger. The charger may be a wireless charger or a wired charger. In some embodiments, the charging management module 140 may detect charging input from a wired charger through the USB interface 130. In other embodiments, the charging management module 140 may detect wireless charging input through a wireless charging coil of the mobile phone 10. While the charging management module 140 is charging the battery 142, it may also power the electronic device through the power management module 141.
[0201] The power management module 141 is used to connect the battery 142, the charging management module 140 and the processor 110. The power management module 141 detects the input of the battery 142 and / or the charging management module 140, and supplies power to the processor 110, the internal memory 121, the external memory 120, the display screen 194, the camera 193, and the wireless communication module 160. The power management module 141 can also be used to monitor parameters such as battery capacity, battery cycle number, battery health status (leakage, impedance), etc. In some embodiments, the power management module 141 can also be set in the processor 110. In some embodiments, the power management module 141 and the charging management module 140 can also be set in the same device. In some embodiments, the power management module 141 can configure the power supply for the configuration of the electronic device in the embodiment of the present application.
[0202] The wireless communication function of the mobile phone 10 can be implemented through the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modem processor and the baseband processor.
[0203] Antenna 1 and antenna 2 are used to transmit and detect electromagnetic wave signals. Each antenna in mobile phone 10 can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve the utilization of antennas. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In some other embodiments, the antenna can be used in combination with a tuning switch.
[0204] The mobile communication module 150 can provide wireless communication solutions including 2G / 3G / 4G / 5G etc. applied on the mobile phone 10 .
[0205] The modulation and demodulation processor may include a modulator and a demodulator. The modulator is used to modulate the low-frequency baseband signal to be transmitted into a medium-high frequency signal. The demodulator is used to demodulate the detected electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After being processed by the baseband processor, the low-frequency baseband signal is transmitted to the application processor.
[0206] The wireless communication module 160 can provide wireless communication solutions for application on the mobile phone 10, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication technology (NFC), infrared technology (IR), etc.
[0207] The mobile phone 10 implements the display function through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, which connects the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 may include one or more GPUs that execute program instructions to generate or change display information.
[0208] The display screen 194 is used to display images, videos, etc. The display screen 194 includes a display panel.
[0209] The mobile phone 10 can realize the shooting function through ISP, camera 193, video codec, GPU, display screen 194 and application processor.
[0210] The ISP is used to process data fed back by the camera 193 .
[0211] The camera 193 is used to capture still images or videos. The object is projected onto the photosensitive element by generating an optical image through the lens.
[0212] The digital signal processor is used to process digital signals. In addition to processing digital image signals, it can also process other digital signals. For example, when the mobile phone 10 is selecting a frequency point, the digital signal processor is used to perform Fourier transform on the frequency point energy.
[0213] The external memory 120 generally refers to an external memory, and common external memories include hard disks, floppy disks, optical disks, USB flash drives, Micro SD cards, etc., which are used to expand the storage capacity of the mobile phone 10. The external memory can communicate with the processor 110 through an external memory interface or bus to realize data storage function.
[0214] The internal memory 121, which may also be referred to as “memory”, may be used to store computer executable program codes, which may include instructions.
[0215] The mobile phone 10 can implement audio functions such as music playing and recording through the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, the earphone interface 170D, and the application processor.
[0216] The pressure sensor 180A is used to sense pressure signals and convert the pressure signals into electrical signals.
[0217] The gyro sensor 180B may be used to determine the motion posture of the mobile phone 10. In some embodiments, the angular velocity of the mobile phone 10 around three axes (ie, x, y, and z axes) may be determined by the gyro sensor 180B.
[0218] The air pressure sensor 180C is used to measure air pressure.
[0219] The magnetic sensor 180D includes a Hall sensor.
[0220] The acceleration sensor 180E can detect the magnitude of the acceleration of the mobile phone 10 in various directions (generally three axes).
[0221] The distance sensor 180F is used to measure the distance.
[0222] The proximity light sensor 180G may include, for example, a light emitting diode (LED) and a light detector, such as a photodiode. The light emitting diode may be an infrared light emitting diode.
[0223] The ambient light sensor 180L is used to sense the brightness of the ambient light. The mobile phone 10 can adaptively adjust the brightness of the display screen 194 according to the sensed brightness of the ambient light.
[0224] The fingerprint sensor 180H is used to collect fingerprints. The mobile phone 10 can use the collected fingerprint characteristics to achieve fingerprint unlocking, access application locks, fingerprint photography, fingerprint call answering, etc.
[0225] The temperature sensor 180J is used to detect the temperature.
[0226] The touch sensor 180K is also called a “touch panel.” The touch sensor 180K may be disposed on the display screen 194 , and the touch sensor 180K and the display screen 194 form a touch screen, also called a “touch screen.”
[0227] Bone conduction sensor 180M can obtain vibration signals.
[0228] The color temperature sensor 180N can be used to detect the color or color temperature of the light source. It can also be used to transmit the corresponding electrical signal according to the color or color temperature of the light source, so that the corresponding binary information after the electrical signal is converted can be recognized by the machine. In some embodiments, the color temperature sensor can automatically adjust the screen color temperature of the electronic device according to the color temperature of the environment, and can be used to detect the color temperature of the environment when the electronic device is shooting, so that the color of the captured video or image is more accurate, or the image is color calibrated, etc.
[0229] The key 190 includes a power key, a volume key, etc. The key 190 may be a mechanical key or a touch key. The mobile phone 10 may detect the key input and generate a key signal input related to the user settings and function control of the mobile phone 10.
[0230] Motor 191 can generate vibration prompts. Motor 191 can be used for incoming call vibration prompts, and can also be used for touch vibration feedback.
[0231] Indicator 192 may be an indicator light, which may be used to indicate charging status, power changes, messages, missed calls, notifications, etc.
[0232] The SIM card interface 195 is used to connect a SIM card.
[0233] Each method implementation of the present application can be implemented in software, magnetic components, firmware or a combination of these implementation methods.
[0234] Program code can be applied to input instructions to perform the functions described herein and generate output data. The output data can be applied to one or more output devices in a known manner.
[0235] Program code can be implemented with high-level programming language or object-oriented programming language to communicate with the processing system. When necessary, program code can also be implemented with assembly language or machine language. In fact, the mechanism described herein is not limited to the scope of any specific programming language. In either case, the language can be a compiled language or an interpreted language.
[0236] One or more aspects of at least one embodiment may be implemented by representative instructions stored on a computer-readable storage medium, which represent various logic in a processor, and when the instructions are read by a machine, cause the machine to fabricate logic for performing the techniques described herein. These representations, known as "IP cores," may be stored on a tangible computer-readable storage medium and supplied to multiple customers or manufacturing facilities to load into a manufacturing machine that actually manufactures the logic or processor.
[0237] Although the description of this application will be introduced in conjunction with a preferred embodiment, this does not mean that the features of this application are limited to this embodiment. On the contrary, the purpose of introducing the invention in conjunction with the embodiment is to cover other options or modifications that may be extended based on the claims of this application. In order to provide a deep understanding of this application, many specific details will be included in the following description. This application can also be implemented without using these details. In addition, in order to avoid confusion or blurring the focus of this application, some specific details will be omitted in the description. It should be noted that the embodiments in this application and the features in the embodiments can be combined with each other without conflict.
[0238] Furthermore, various operations will be described as multiple discrete operations in a manner that is most helpful for understanding the illustrative embodiments; however, the order of description should not be construed as implying that these operations are necessarily order dependent. In particular, these operations do not need to be performed in the order presented.
[0239] As used herein, the term "module" or "unit" may refer to, be or include: an application specific integrated circuit (ASIC), an electronic circuit, a (shared, dedicated or group) processor and / or memory that executes one or more software or firmware programs, a combinational logic circuit and / or other suitable components that provide the described functionality.
[0240] In the accompanying drawings, some structural or method features are shown in a specific arrangement and / or order. However, it should be understood that such a specific arrangement and / or order may not be required. In some embodiments, these features may be arranged in a manner and / or order different from that shown in the illustrative drawings. In addition, the inclusion of structural or method features in a specific figure does not mean that such features are required in all embodiments, and in some embodiments, these features may not be included or may be combined with other features.
[0241] Embodiments of the present application may be implemented as a computer program or program code executed on a programmable system including multiple processors, a storage system (including volatile and non-volatile memory and / or storage elements), multiple input devices, and multiple output devices.
[0242] In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. In some cases, one or more aspects of at least some embodiments may be implemented by representative instructions stored on a computer-readable storage medium, which represent various logics in a processor, and when the instructions are read by a machine, the machine makes logic for performing the techniques described herein. These representations, known as “IP cores,” may be stored on a tangible computer-readable storage medium and provided to multiple customers or production facilities to be loaded into a manufacturing machine that actually manufactures the logic or processor.
[0243] Therefore, various embodiments of the present application also include non-transitory computer-readable storage media that contain instructions or contain design data, such as hardware description language (HDL), which defines the structures, circuits, devices, processors and / or system features described in the present application.
Claims
1. A device initialization method, characterized in that: Applied to electronic equipment, the electronic equipment comprises a first device; The method comprises: detecting that the electronic device is activated; Acquire first identification information and a first communication address corresponding to a first device to be initialized based on a device configuration file of the electronic device; Determine that the first identification information matches the stored second identification information of the second device, wherein the first identification information and the second identification information are device names; Acquire first initialization information corresponding to the second device; reading third identification information of the first device based on the first device identification function corresponding to the second device and the first communication address, determining that communication of the second device is normal when the third identification information matches the second identification information of the second device, initializing and configuring the first device based on the first initialization information, and binding the first device to the corresponding application through the public node entrance of the electronic device, wherein the third identification information is a device name; The first identification information corresponding to the first device does not match the stored second identification information of the second device, and the first device is not registered with the power management module of the electronic device based on the public node entry.
2. The method according to claim 1, characterized in that Acquiring first identification information and a first communication address corresponding to a first device to be initialized based on a device configuration file of the electronic device; comprising: Acquire an identification information set and a communication address set corresponding to the first device to be initialized based on the device tree file; The first identification information is identification information in the identification information set, and the first communication address is a communication address in the communication address set.
3. The method according to claim 1, characterized in that The electronic device stores a first function pointer group corresponding to the second device, wherein the first function pointer group includes the second identification information, the first initialization information and the first device identification function; Corresponding to determining the first identification information of the first device, matching it with the stored second identification information, establishing an association between the first communication address and the first function pointer group.
4. The method according to claim 3, wherein the initializing configuration of the first device based on the first initialization information comprises: Determine identification information of a first function pointer group corresponding to the second device; The first initialization information is called based on the identification information of the first function pointer group to initialize and configure the first device.
5. The method according to any one of claims 1 to 4, characterized in that: The first initialization information includes a detection function, a removal function, a power suspend function and a power recovery function.
6. The method according to any one of claims 1 to 4, characterized in that: The electronic device stores identification information of a plurality of mountable devices corresponding to the first device; The determining that the first identification information matches the stored second identification information of the second device includes: The second identification information matching the first identification information is determined from the identification information of the plurality of mountable components.
7. An electronic device, characterized in that: including a memory for storing instructions; A processor is used to execute the instruction so that the electronic device implements the device initialization method according to any one of claims 1 to 6.
8. A readable storage medium, characterized in that: The readable storage medium stores instructions, which, when executed on an electronic device, enable the electronic device to execute the device initialization method according to any one of claims 1 to 6.
9. A computer program product, characterized in that The device comprises instructions, which, when executed on an electronic device, enable the electronic device to execute the device initialization method according to any one of claims 1 to 6.