CN117707628A

CN117707628A - Device initialization method, electronic equipment and readable storage medium

Info

Publication number: CN117707628A
Application number: CN202310716499.5A
Authority: CN
Inventors: 罗润发
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2023-06-15
Filing date: 2023-06-15
Publication date: 2024-03-15

Abstract

The application relates to the technical field of intelligent terminals, in particular to a device initialization method, electronic equipment and a readable storage medium. In the device initializing method provided by the application, when the startup of the electronic device is detected, the identification information and the communication address of the configurable device corresponding to the first device can be obtained based on the configuration file of the electronic device, such as the device tree file, then the identification information of the device in the preset loadable device can be matched with the configurable identification information read in the device tree file, so that the communication address is associated with the corresponding loadable device. Therefore, the detection flow can be effectively simplified, and resources are saved.

Description

Device initialization method, electronic equipment and readable storage medium

Technical Field

The present disclosure relates to the field of intelligent terminals, and in particular, to a device initializing method, an electronic device, and a readable storage medium.

Background

The electronic equipment can be provided with the same type of electronic devices provided by different suppliers, and the code information of the same type of electronic devices of a plurality of different suppliers is preset on a software base line (namely a stable version of a software document or source code in the electronic equipment) of the electronic equipment, so that the electronic equipment can be compatible with the same type of electronic devices provided by different suppliers. In the starting-up stage of the electronic equipment, for example, when the electronic equipment is started up for the first time, the electronic equipment needs to perform initialization configuration on the electronic device in the electronic equipment, namely, code information corresponding to the electronic device is called to perform initialization configuration on the electronic device, so that functions corresponding to the electronic device in the electronic equipment can be normally used. Therefore, it is necessary to determine which specific electronic device among the plurality of electronic devices of the same type is actually mounted on the electronic apparatus by detecting the electronic device, and then to perform initializing configuration of the electronic device based on the determined code information of the electronic device.

For example, by presetting code information of the color temperature sensors S1 to S5 provided by different suppliers on a software base line of the mobile phone, the mobile phone can be provided with (i.e., compatible with) any one of the color temperature sensors S1 to S5. If the mobile phone is actually mounted with the color temperature sensor S1. In the starting-up stage of the electronic equipment, the color temperature sensor of the mobile phone needs to be detected, the color temperature sensor S1 actually carried by the mobile phone is accurately detected, and the color temperature sensor S1 is initialized and configured based on code information of the color temperature sensor S1, so that corresponding functions in the mobile phone can be normally used, for example, functions of adjusting shooting parameters of a camera in the mobile phone in a shooting process or adjusting colors of a shot video and an image and the like can be included.

How to accurately detect an electronic device actually mounted in an electronic device is a problem to be solved at present.

Disclosure of Invention

In order to solve the above problems, embodiments of the present application provide a device initialization method, an electronic apparatus, and a readable storage medium.

In a first aspect, an embodiment of the present application provides a device initialization method, applied to an electronic device, where the method includes: detecting that the electronic device is started; acquiring first identification information and a first communication address corresponding to a first device to be initialized based on an equipment configuration file of the electronic equipment; determining first identification information, and matching the first identification information with stored second identification information of the second device; acquiring first initialization information corresponding to a second device; and carrying out initialization configuration on the first device based on the first initialization information when the communication of the second device is determined to be normal based on the first communication address.

It is understood that the device configuration file of the electronic device may be a device tree file, in which each identification information (e.g., device name) and each communication address, such as an I2C address, etc., of the electronic device that can be configured by the current item may be configured. Wherein each identification information can form an identification information list, and each communication address can form a communication address list.

It may be appreciated that the first identification information may be an electronic device name in a name list of the first device acquired based on the configuration file, and the first communication address may be an electronic device address in an address list of the first device acquired based on the configuration file.

It is understood that the first device may be an electronic device actually mounted on the electronic apparatus.

It can be understood that the identification information of the second device may be the identification information of one device in the mountable electronic devices corresponding to the first device prestored in the electronic apparatus.

It can be understood that the device tree file defines configuration information of the current electronic device, so when a device name which does not exist in the device tree file 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 sensors which can be mounted is named as A2, and the electronic devices corresponding to the A2 are proved to be impossible to exist in the electronic device based on the device names acquired by the device tree file as A3 and A4, therefore, subsequent detection of the color temperature sensor named as A2 is not needed, for example, whether subsequent communication is normal or not is not needed, so that a detection flow can be effectively simplified, and resources are saved.

In one possible implementation of the first aspect, acquiring, based on a device configuration file of the electronic device, first identification information and a first communication address corresponding to a first device to be initialized; comprising the following steps: acquiring an identification information set and a communication address set corresponding to a first device to be initialized based on the equipment 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.

In one possible implementation of the first aspect, determining that the communication of the second device is normal based on the first communication address; comprising the following steps: reading third identification information of the first device based on a first device identification function and a first communication address corresponding to the second device; and when the third identification information is matched with the second identification information of the second device, determining that the communication of the second device is normal.

It can be understood that the third identification information of the first device may be read based on the first device identification function, for example, get_chip_id function, and when the device name corresponding to the actually mounted first device can be read and the read third identification information of the first device is matched with the device name in the corresponding function pointer group acquired based on the equipment tree file, it may be determined that the currently detected first device is the actually mounted electronic device and the communication is normal.

It will be appreciated that in some embodiments, some compatible electronic devices may be wired in the same manner, for example, the device a and the device B may be wired in the same manner, so that the I2C communication conditions of the device a and the device B are substantially the same, and therefore, when the electronic device actually mounted in the electronic device is the device B, and when the device a is detected, the communication condition is detected to be normal, which results in misjudgment that the device a is the device actually mounted, and a misjudgment problem may occur. In the method provided by the embodiment of the application, when the device is detected, whether the I2C communication is abnormal or not is simply judged, and whether the names of the electronic devices are matched or not is also judged, and based on the judgment of the two aspects, the detection accuracy can be improved, and the misjudgment condition in some embodiments is avoided.

In one possible implementation manner of the first aspect, the electronic device stores a first function pointer group corresponding to the second device, where the first function pointer group includes second identification information, first initialization information, and a first device identification function; and corresponding to the first identification information of the first device, matching with the stored second identification information, and establishing the association of the first communication address and the first function pointer group.

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 is matched with the stored second identification information of the second device, the first communication address is assigned to the first function pointer group for storage.

In one possible implementation of the first aspect, the initializing the first device based on the first initialization information includes: determining the identification information of a first function pointer group corresponding to the second device; and calling first initialization information based on the identification information of the first function pointer group to perform initialization configuration on the first device.

It is understood that the identification information of the first function pointer set may be a subscript of the function pointer set mentioned in the embodiments of the present application, such as a numerical identification or the like.

Based on the above scheme, the initialization configuration can be performed on the actual carrying device by directly matching the corresponding function in the function pointer group according to the identified array corresponding to the actual carrying device, so that when a plurality of alternative electronic devices exist in the same base line, the number of the function functions is reduced, and the loading time required to search for and match the corresponding function functions again is long.

In one possible implementation of the first aspect, the first initialization information includes a probe function, a removal function, a power suspension function, a power recovery function, and a device identification function.

In one possible implementation manner of the first aspect, the electronic device stores identification information of a plurality of loadable devices corresponding to the first device in the electronic device; determining first identification information, and matching the first identification information with stored second identification information of the second device; comprising the following steps: and determining second identification information matched with the first identification information from the identification information of the plurality of the devices capable of being mounted.

In a second aspect, embodiments of the present application provide an electronic device, including a memory for storing instructions; a processor configured to execute instructions to cause the device initialization method provided by the above first aspect and various possible implementations of the first aspect to be implemented.

In a third aspect, embodiments of the present application provide a readable storage medium having stored thereon instructions that, when executed on an electronic device, cause the device initialization method provided by the foregoing first aspect and various possible implementations of the first aspect to be implemented.

In a fourth aspect, embodiments of the present application provide a computer program product comprising instructions that, when executed on an electronic device, cause the electronic device to perform the device initialization method provided by the above first aspect and various possible implementations of the first aspect.

Drawings

Fig. 1 is a schematic view of a mobile phone power-on configuration according to some embodiments of the present application;

FIG. 2 illustrates a flow diagram of a device initialization method, according to some embodiments of the present application;

FIG. 3 illustrates a flow diagram of a mutex lock-based device initialization method, according to some embodiments of the present application;

FIG. 4A illustrates a system architecture diagram of an electronic device, according to some embodiments of the present application;

FIG. 4B illustrates a system architecture diagram of another electronic device, according to some embodiments of the present application;

FIG. 4C illustrates a system architecture diagram of yet another electronic device, according to some embodiments of the present application;

FIG. 4D illustrates a system architecture diagram of yet another electronic device, according to some embodiments of the present application;

FIG. 5 illustrates a flow diagram of another device initialization method, according to some embodiments of the present application;

FIG. 6 illustrates a particular flow diagram of a device initialization method, according to some embodiments of the present application;

fig. 7 illustrates a schematic diagram of an electronic device 10, according to some embodiments of the present application.

Detailed Description

Illustrative embodiments of the present application include, but are not limited to, a device initialization method, an electronic apparatus, and a readable storage medium.

It can be appreciated that the embodiments of the present application may be applied to any electronic device that needs to perform device detection, including, but not limited to, a mobile phone, a tablet computer, a wearable device (such as a smart watch, a smart bracelet, etc.), a vehicle-mounted device, an internet of things device, an intelligent home device, etc. For convenience of description, the technical solution of the embodiments of the present application is described below by taking an electronic device handset as an example.

It is to be appreciated that the embodiments of the present application may be applied to detect any electronic device that needs to be detected and configured by an electronic device, including, but not limited to, proximity optics, ambient light, and laser (dtop) devices in an electronic device, etc. For convenience of description, the technical scheme of the application is described below by taking an electronic device color temperature sensor in a mobile phone as an example.

For ease of understanding, the terms involved in the embodiments of the present application are first described.

(1) Software baseline

The software baseline is a stable version of the software code document or source code in the electronic device, and during the software development process, when new requirements are made to the software, frequent updates are required, an unknown error may be generated. At this time, the system can be rolled back to the last software baseline so as to meet the requirements of equipment testing and the like by using a stable version, and the existing problems are repaired. In the embodiment of the present application, for example, the code information of the color temperature sensors S1 to S5 may be preset in the software baseline, so that when the color temperature sensor S1 actually mounted in the electronic device is detected, the initialization configuration may be performed on the basis of the code information of the color temperature sensor S1.

(2) Kernel target module

The kernel object module (kernel object module, KO) is a loadable module in the kernel layer, the KO module includes driver code therein, and functions can be dynamically added to the kernel layer. While the electronic device is running, the kernel functionality may be extended or reduced by loading or unloading the KO module. The KO module may generally include kernel functions such as drivers, file systems, network protocol stacks, and the like. The functionality of the kernel layer may be extended or improved by writing the KO module.

(3) Device tree

A device tree (device tree source, DTSI) is a data structure describing hardware, which consists of a series of named nodes and attributes, which hardware devices can use to avoid extensive redundancy coding in the kernel layer; attributes refer to names and values that appear in pairs.

In order to facilitate understanding of the technical solution of the present application, an application scenario of the device initialization method is described below by taking the scenario shown in fig. 1 as an example. Fig. 1 illustrates a schematic diagram of a mobile phone 10 configured for power-on initialization, according to some embodiments of the present application.

Referring to fig. 1, a user may control the mobile phone 10 to perform a power-on configuration by pressing a power-on key 11 of the mobile phone 10 for a long time. After the user presses the power-on key 11 of the mobile phone 10 for a long time for a preset duration, the interactive interface of the mobile phone 10 displays a prompt box 101 to prompt the user to determine whether to activate and configure the mobile phone 10, and the user can determine to start activating and configuring the mobile phone 10 by clicking a confirmation box 1011. In the process of powering on the mobile phone 10, the mobile phone 10 may detect an electronic device used therein, for example, a color temperature sensor, so as to determine information of the color temperature sensor carried by the mobile phone 10, where the information of the color temperature sensor may include name information, model information, communication address information, and the like of the color temperature sensor.

It is understood that a color temperature sensor is a sensor for detecting the color or color temperature of a light source. The device can be used for transmitting corresponding electric signals according to the color or the color temperature of the light source, so that corresponding binary information after the electric signals are converted can be identified by a machine.

In some embodiments, the color temperature sensor may automatically adjust the screen color temperature of the electronic device according to the color temperature of the environment, and may be used to detect the color temperature of the environment when the electronic device photographs, so that the photographed video or image is more accurate in color, or the image is subjected to color calibration, etc., without limitation.

It should be understood that the power-on mode of the mobile phone 10 shown in fig. 1 is only an example, and in other embodiments, the mobile phone 10 may be controlled to power on by other keys or key combinations of the mobile phone 10, which is not limited herein.

As described above, the electronic device may support the carrying of the same type of electronic devices provided by different suppliers, and the code information of the same type of electronic devices of a plurality of different suppliers may be preset on the software baseline of the electronic device, so that the electronic device may be compatible with the same type of electronic devices provided by different suppliers. In the starting-up stage of the electronic equipment, the electronic equipment needs to perform initializing configuration on the electronic devices in the electronic equipment, namely, the electronic devices are required to be subjected to initializing configuration by calling code information corresponding to the electronic devices so that the corresponding functions can be normally used, therefore, the electronic equipment needs to be determined to truly carry specific electronic devices in a plurality of electronic devices of the same type through detecting the electronic devices, and then the electronic devices are subjected to initializing configuration based on the determined code information of the electronic devices.

In some embodiments of the present application, the electronic device may be detected sequentially by the detection function, and whether the electronic device is a color temperature sensor actually carried by the electronic device is judged by judging whether the I2C address communication of the electronic device is normal, but the scheme needs to be operated to drive the loadable device, so that whether the electronic device is actually carried can be determined when the I2C address communication condition is judged, and each device needs to be judged, which results in waste of flow and overlarge resource consumption.

For example, fig. 2 shows a schematic flow chart of a device initialization method. For easy understanding, an electronic device is taken as an example of a color temperature sensor, and the specific flow comprises:

s201: the probing mode (mod_probe) is started.

It will be appreciated that the device probe (mod_probe) function is a drive command for linux and may load a specified single module or a group of modules into the kernel layer. In this application, the kernel layer may call a device probe (mod_probe) function to execute a subsequent procedure to implement loading the color temperature sensor into the KO module and communicate with the upper layers.

S202: the common entry function (mod_init) of the KO module is initialized.

It will be appreciated that each driver has the statement mod_init, which means that the driver command is automatically executed at system start-up, i.e. the common population function mod_init is defined.

In some embodiments, the driver codes corresponding to the electronic devices may be encapsulated in a KO module in Kernel, and when the device detection is performed, a common entry function mod_init of the KO module may be initialized, so as to define functions related to initialization and exit of the driver.

It can be understood that the Linux kernel compilation needs to include kernel header files, and the driving code of the KO module of the kernel layer needs to include the following three header files: #include < linux/init.h >, #include < linux/module h >, #include < linux/kernel h >. Wherein init.h defines the initialization and exit related functions of the drive; kernel.h defines frequently used function prototypes and macro definitions, module.h defines functions, variables, etc. associated with the kernel module.

S203: the i2c_add_driver function of the ith color temperature sensor is called based on the common entry function.

In some embodiments, the i2c_add_driver function of the current ith color temperature sensor may be invoked based on a common entry function so that the current ith color temperature sensor may be registered into the device chain table of the KO module. It will be appreciated that the device chain table is a collection of compatible electronic devices in the kernel layer.

S204: and calling a real_probe function of the ith color temperature sensor, and driving the current color temperature sensor.

In some embodiments, the real_probe function of the current color temperature sensor may be invoked, i.e., ready to drive the current color temperature sensor, so that the current color temperature sensor may be tied to the common node entry of the kernel layer.

S205: and judging whether the I2C communication of the current color temperature sensor is normal or not.

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, and if so, the process goes to S206, where the color temperature sensor with normal communication is bound to a common node entry in the kernel layer. If the communication is abnormal, the process goes to step S207, where the color temperature sensor with abnormal communication is stored as a virtual device in the kernel layer of the system.

S206: the color temperature sensor with normal communication is bound to a common node entrance in the kernel layer.

In some embodiments, if the communication of the current color temperature sensor is normal, the color temperature sensor with normal communication is bound to a common node portal in the kernel layer, so that the current color temperature sensor can be communicatively connected with the upper layer based on the driving of the kernel layer

S207: the color temperature sensor with abnormal communication will be stored as a virtual device in the system.

In some embodiments, if the communication of the current color temperature sensor is abnormal, the color temperature sensor with the communication abnormal will be stored as a virtual device in the system.

S208: the function returns, i=i+1.

It will be appreciated that whether or not the communication of the current color temperature sensor is normal, it is necessary to return to step S202 to continue the detection flow of the next, i.e., i+1th color temperature sensor.

As described above, in this solution, it is necessary to drive the loadable device to determine whether the device is an actually loaded device according to the I2C address communication condition, and each device needs to perform the determination, which results in waste of flow and excessive resource consumption.

In other embodiments, whether the color temperature sensor is actually mounted on the electronic device may be determined by adding a Mutex (Mutex) lock, when each device detects, by adding the Mutex lock, then determining a flag bit of the Mutex lock first, if the flag bit is not null, indicating that the detection has succeeded, if the flag bit is null, indicating that the detection has not succeeded on the device currently, and continuing to call the I2C address of the electronic device in sequence to determine the I2C address communication condition, and determining whether the corresponding color temperature sensor is the color temperature sensor actually mounted on the electronic device is implemented based on the I2C address communication condition. According to the scheme, the flag bit for judging the Mutex lock is added before the I2C communication is judged, so that the next color temperature sensor is detected after one color temperature sensor is detected, the problem that the detection flow of the current color temperature sensor is interrupted and the current color temperature sensor needs to be detected again due to the fact that other sensors are continuously detected when the current color temperature sensor is not detected is avoided, the I2C communication judgment flow of all the color temperature sensors mentioned in the above figure 2 still needs to be executed in sequence, flow waste is caused, and resource consumption is overlarge is avoided.

Referring to fig. 3, fig. 3 shows a flow diagram of a device initialization method based on mutex lock. For easy understanding, an electronic device is taken as an example of a color temperature sensor, and the specific flow comprises:

s301: the probing mode (mod_probe) is started.

It is understood that step S301 may refer to step S201 described above, and will not be described herein.

S302: the common entry function (mod_init) of the KO module is initialized.

It is understood that step S302 may refer to step S202 described above, and will not be described herein.

S303: the i2c_add_driver function of the ith color temperature sensor is called based on the common entry function.

It is understood that step S303 may refer to step S203, which is not described herein.

S304: and calling a real_probe function of the current color temperature sensor.

It is understood that step S304 may refer to step S204 described above, and will not be described herein.

S305: the driving process of the current color temperature sensor is locked (probe_lock) through a Mutex lock.

In some embodiments, by adding a Mutex (Mutex), i.e. a Mutex lock, the driving process of the current color temperature sensor is performed, i.e. 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 cannot be detected and driven.

It will be appreciated that Mutex lock is a sleep lock mechanism that ensures serialization, and can suspend the current process, i.e., lock the current detection process. The use of Mutex locks requires setting a flag bit to determine whether the Mutex lock is currently in a locked state.

S306: and judging whether the flag bit color_name of the Mutex lock is empty or not.

In some embodiments, judging a flag bit color_name of the Mutex lock, when determining that the flag bit color_name is empty, determining that no current color temperature sensor is in a driving process, turning to step S307, calling a real_probe function of the current color temperature sensor, and driving the current color temperature sensor; when it is determined that the flag color_name is not empty, it is determined that the detection of the color temperature sensor is successful, and the process goes to step S310, where the I2C communication judgment of the current color temperature sensor is not performed, but the current detection process is unlocked to continue to perform the detection process of the next color temperature sensor.

S307: and calling a real_probe function of the current color temperature sensor, and driving the current color temperature sensor.

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 current color temperature sensor is driven based on the real_probe function of the current color temperature sensor called by the I2C, so that the current color temperature sensor can be bound to the common node entry of the kernel layer.

S308: and judging whether the current color temperature sensor I2C is normal in communication.

In some embodiments, when the current color temperature sensor is driven, judging whether the I2C communication of the current color temperature sensor is normal, if so, going to S309, and setting a flag bit color_name 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 goes to step S310, and instead of performing the I2C communication judgment of the current color temperature sensor, the current detection process is unlocked to continue to perform the detection process of the next color temperature sensor.

S309: the set flag color_name indicates that the current color temperature sensor is an electronic device actually mounted on the electronic device.

In some embodiments, it is determined that when the I2C of the color temperature sensor can normally communicate, it is determined that the current color temperature sensor is the color temperature sensor actually carried by the electronic device, and a flag bit color_name is set as a corresponding identifier, so as to indicate that the current color temperature sensor has successfully detected.

S310: the calling process (probe_unlock) of the current color temperature sensor is unlocked.

In some embodiments, after the detection process of the current color temperature sensor is finished, the calling process of the current color temperature sensor is unlocked through a probe_unlock function.

In some embodiments, when the flag bit is determined not to be empty, it indicates that the currently existing color temperature sensor is detecting the current color temperature sensor in progress or that the detection of the currently existing color temperature sensor is successful, and the calling process of the currently successfully detected color temperature sensor can be unlocked through the probe_unlock function.

S311: the function returns, i=i+1.

In some embodiments, after determining the color temperature sensor actually carried by the electronic device, the color temperature sensor actually carried may be bound to the common node portal so that it completes the connection with the upper layer. And returning to step S302, the next color temperature sensor is continuously detected, that is, whether the flag bit is empty or not, and whether the color temperature sensor is in normal communication, the next color temperature sensor is required to be continuously detected in step S202, that is, the detection flow of the (i+1) th color temperature sensor is required to be continuously executed.

In some embodiments, if the current color temperature sensor is not the color temperature sensor actually carried by 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 continuously detect the next color temperature sensor. In some embodiments, when the flag bit is empty, the process returns to step S302 directly to continue to detect the next color temperature sensor.

In the above scheme, the flag bit for judging the Mutex lock is added before the I2C communication is judged, so that the next color temperature sensor is detected after the detection of one color temperature sensor is finished, the problem that the detection flow of the current color temperature sensor is interrupted and the flow needing to be detected again is complicated due to the fact that other sensors are continuously detected when the detection of the current color temperature sensor is not finished is avoided, and the I2C communication judging flow of all the color temperature sensors mentioned in the above figure 2 still needs to be executed in sequence, so that the flow is wasted and the resource consumption is overlarge.

In order to solve the above-mentioned problems, an embodiment of the present application provides a method for initializing a device, where first, a function pointer set (or called an array) of a compatible electronic device corresponding to a device to be initialized may be preset, for example, the device to be initialized is a color temperature sensor, and the color temperature sensor has 5 types of compatible color temperature sensors, then a function pointer set corresponding to each of the 5 types of color temperature sensors is preset, where the function pointer set may include function functions such as device identification information (for example, device name, I2C address, etc.), probe (probe), remove (remove), suspend (suspend) and resume) functions corresponding to each electronic device,

And then, acquiring each piece of identification information (such as device name) and each I2C address of the electronic device which can be configured by the current project of the electronic device based on the DTSI device tree file corresponding to the electronic device. And matching the device names in the function pointer groups based on the device names acquired by the DTSI file to acquire corresponding function pointer groups to be selected, and assigning the I2C addresses corresponding to the device names acquired by the DTSI equipment tree file to the corresponding function pointer groups to be selected. And taking the device which is normally communicated in the devices corresponding to the function pointer group to be selected as the device actually carried by the current electronic equipment, and carrying out initialization configuration on the device based on the function in the function pointer group to be selected.

It can be understood that the DTSI device tree file defines configuration information of the current electronic device, so that a device name that does not exist in the DTSI device tree file will not be configured in the current electronic device, for example, a device name of one of the compatible color temperature sensors corresponding to the color temperature sensor is A2, and the device names acquired based on the DTSI device tree file are A3 and A4, so that it is proved that an electronic device corresponding to the A2 cannot exist in the electronic device, and therefore, subsequent detection, for example, whether subsequent communication is normal or not, is not required, so that a detection process can be effectively simplified, and resources are saved.

In some embodiments, a key function (get_chip_id) may also be included in the set of function pointers for each electronic device.

After the function pointer group to be selected is determined, the device name of the electronic device actually carried at present can be read based on a key function (get_chip_id) in the function pointer group to be selected, when the device name corresponding to the electronic device actually carried can be read and the read device name is matched with the device name in the corresponding function pointer group to be selected, it can be judged that the electronic device actually carried by the electronic device is the currently detected electronic device and the communication is normal, and the currently detected electronic device actually carried by the electronic device is taken as the electronic device of the electronic device, and the function binding and the initialization flow of the device and the like are carried out. If the device name of the electronic device actually carried by the electronic equipment cannot be read or the read device name is not matched with the device name of the corresponding function pointer group to be selected, namely the currently detected mountable electronic device is not the actually carried electronic device, the next electronic device is directly detected.

Therefore, when in detection, not only is the I2C communication simply judged whether to be abnormal, but also the names of the electronic devices are judged whether to be matched, so that the detection accuracy can be improved, the misjudgment condition in the prior art is avoided, and the misjudgment condition in the prior art is explained as follows: it will be appreciated that some compatible electronic devices may be wired in the same manner, for example, the devices a and B may be wired in the same manner, which results in that I2C communication conditions of the devices a and B are substantially the same, and therefore, when the electronic device actually mounted in the electronic device is the device B, it may occur that the communication condition is detected as normal when the device a is detected, which results in misjudging that the device a is the device actually mounted.

In some embodiments, the function pointer group includes function functions such as probe, remove, suspend and resume functions corresponding to each electronic device, after determining that the electronic device is actually carried, the function binding and the initialization flow of the device can be directly performed based on the probe function in the function pointer group, and in addition, the remove function can be used for cleaning corresponding memory resources when the electronic device is removed from the kernel layer; the suspend function can manage the sleep of the power management module; the resume function may manage power restoration. Therefore, functions required to be used by the device are normalized, corresponding function functions in the function pointer group can be directly matched according to the identified actual carried device, and when a plurality of alternative electronic devices exist in the same base line, the function functions are multiple, and the loading time required to search for and match the corresponding function functions again is long.

In order to facilitate understanding of the technical scheme of the application, the system architecture of the electronic equipment mentioned in the application is described by taking the architecture example of the color temperature sensor,

in some embodiments, as shown in fig. 4A, the system architecture of the electronic device may include a framework layer, a hardware abstraction layer, a kernel layer, and a hardware layer. Wherein:

A camera service unit may be included in the framework layer, and in some embodiments, camera services may be invoked by the framework layer when a user turns on the camera, e.g., obtain camera device attributes, etc.

The hardware abstraction layer (hardware abstraction layer, HAL) may include automatic exposure, automatic white balancing, network control systems, etc. The hardware abstraction layer is the abstraction and encapsulation of the hardware devices, and provides a unified access interface for the system in different hardware devices. The HAL layer is positioned between the framework layer and the kernel layer, can shield the difference of different hardware devices, and provides a unified interface for accessing the hardware devices for the system.

The hardware abstraction layer may communicate with the framework layer using a hardware abstraction layer interface definition language (interface definition language, HDIL). For example, the hardware abstraction layer may invoke functions of auto-exposure, auto-white balancing, network control, etc., based on notifications in the framework layer that acquire camera device attributes. The hardware abstraction layer may further include an automated test tool communication protocol (mmi_apk), which may be used to provide a communication test interface for testing electronic devices of the electronic device, for example, may provide a communication test interface for color testing of a color temperature sensor in the electronic device, and may also provide a communication test interface for flicker testing of a flicker sensor in the electronic device. The hardware abstraction layer may further include a function server, in which a diag_client function may be included, which may be used to provide support for driving the color temperature sensor, for example, color calibration may be performed by driving the color temperature sensor through the diag_client function. Sensor hardware abstraction layers may also be included in the hardware abstraction layers.

Color temperature sensor drivers may be included in the kernel layer.

The hardware layer may include color temperature sensors of different models, etc.

It should be understood that the framework layer, the hardware abstraction layer, the kernel layer, and the hardware layer may further include other units or modules besides the foregoing, which are not limited herein.

For example, in some embodiments, as shown in fig. 4B, the sensor hardware abstraction layer may include a color temperature sensor hardware abstraction layer and a flicker sensor hardware abstraction layer.

A common node entry and color temperature sensor driver file may be included in the kernel layer. The driving file of the color temperature sensor of the kernel layer may include a color temperature sensor interface, code information of the color temperature sensor, and the like. The color temperature sensor interface may be used to bind the color temperature sensor to the common node portal, thereby binding the color temperature sensor to the upper layer application through the common node portal. The drive file of the color temperature sensor may include drive code information, for example, drive code information of the color temperature sensor TCS3408, drive code information of the color temperature sensor BU27006, drive code information of the color temperature sensor a57341, and the like. It is understood that the color temperature sensor may be an ambient light sensor or a strobe sensor, which is not limited herein. It will be appreciated that in other embodiments, the driving code information of other color temperature sensors besides the above color temperature sensor may be further included in the driving file of the color temperature sensor, which is not limited herein.

The hardware layer may be a color temperature sensor of different types, for example, the color temperature sensor may be a TCS3408, a BU27006, or a color temperature sensor a57341, which is not limited herein.

In some embodiments, the method shown in fig. 3 and described above may be implemented based on the structure shown in fig. 4B, for example, the i2c_add_driver function of the color temperature sensor TCS3408 may be called based on the public entry function of the kernel layer, the real probe function of the color temperature sensor TCS3408 is called to drive the color temperature sensor TCS3408, whether the I2C communication of the color temperature sensor TCS3408 is normal or not is determined, if the communication is normal, the color temperature sensor TCS3408 may be bound to the public node entry through the color temperature sensor interface, and then the color temperature sensor TCS3408 and the upper application may be functionally bound through the public node entry; the color temperature sensor TCS3408 is stored as a virtual device in the kernel if communication is abnormal. Further, the detection of the color temperature sensors BU27006 or a57341 is continued until the detection of all the color temperature sensors is completed.

However, in the above scheme, the I2C communication judging process of all the color temperature sensors needs to be sequentially executed, that is, all the color temperature sensors are detected, and even if the color temperature sensor is successfully detected as the color temperature sensor actually mounted on the electronic device, the other color temperature sensors still need to be detected, so that the process is wasted and the resource consumption is overlarge.

In addition, in the above scheme, the electronic device called each time is registered in the power management module, so that other electronic devices which are not actually carried by the electronic device become virtual devices in the power management module, and further, each time of suspension (suspend) and recovery (resume) of the power management module call the virtual devices, which causes resource waste.

In some embodiments, to solve the above problem, as shown in fig. 4C, a device detection and function binding module may be added to the kernel layer, so that after the device detection and function binding module in the color temperature sensor interface completes the correct detection of the actually carried color temperature sensor, the actually carried color temperature sensor is bound to an upper layer application through the common node inlet.

Compared with the color temperature sensor interface in fig. 4B, the color temperature sensor interface in fig. 4C may include a device detection and function binding module, where the device detection and function binding module may implement that after the color temperature sensor actually carried by the electronic device is correctly detected, the color temperature sensor actually carried by the electronic device is communicated with an upper layer through a common node inlet and the function is bound, and the color temperature sensor actually carried by the electronic device is not directly registered in the power management module through the common node inlet, so that the operation that the power management module repeatedly suspends and recovers the virtual device due to the existence of a suspended virtual device in the power management module is avoided, that is, the problem of resource waste mentioned in the scheme is solved.

In addition, when device detection is performed based on the device detection and the function binding module, the I2C address read from the DTSI device tree file may be assigned to a function pointer group corresponding to each mountable electronic device, where the function pointer group includes a device name (e.g., device id) and a key function (get_chip_id). Then, the id of the actually-carried electronic device is read based on the corresponding I2C address through the key function (get_chip_id) corresponding to the currently-detected device, when the id corresponding to the actually-carried electronic device can be read and the read id is matched with the id in the pointer group of the current function, the currently-detected device can be judged to be the actually-carried electronic device and the communication is normal, and the currently-detected device can be taken as the actually-carried electronic device, so that the function binding and the initialization flow of the device can be carried out. When the id corresponding to the actually mounted electronic device can be read but the read id is not matched with the id in the current function pointer group, the currently detected mountable electronic device is not the actually mounted electronic device, and the next electronic device is detected. Based on the above, when the device detection is performed, whether the I2C communication is abnormal or not is simply judged, and whether the names of the electronic devices are matched or not is also judged, and based on the judgment in the two aspects, the detection accuracy can be improved, and the misjudgment condition existing in some embodiments can be avoided.

In some schemes, compared with the embodiment of the application in which an abstracted common node inlet is provided for a sensor at a kernel layer, some schemes do not adopt the abstracted common node inlet, but each electronic device is provided with a corresponding driver and node inlet, and then an interface adopting the common sensor is arranged at a hardware abstraction layer of the sensor, so that the interfaces on the sensor are unified, and the method has obvious defects that the compatibility to multiple devices is poor.

For example, as shown in fig. 4D, fig. 4D shows an interface schematic of a color temperature sensor, it can be seen that the color temperature sensor TMF882 needs to communicate with a hardware abstraction layer of the color temperature sensor TMF882 through a TMF882 node portal; the color temperature sensor VL5311 needs to communicate with the hardware abstraction layer of the color temperature sensor VL5311 through the VL5311 node portal. That is, each color temperature sensor needs to be bound with the upper layer through the corresponding color temperature sensor interface and the node inlet, and the compatibility of each interface and the node inlet is not high.

The device initialization method provided in the embodiment of the present application is described in detail below. Referring to fig. 5, fig. 5 shows a flow diagram of a device initialization method. For easy understanding, an electronic device is taken as an example of a color temperature sensor, and the specific flow comprises:

s501: the list of electronic device names and the I2C address of each electronic device in the current project are configured in the DTSI device tree file.

It will be appreciated that the DTSI device tree file is configured with each identification information (e.g., device name) and each communication address, e.g., I2C address, of the electronic device that the current project may configure. Wherein each identification information can form a device name list, and each communication address can form a communication address list.

In some embodiments, the names of the electronic devices may be configured in a DTSI device tree file to match the names of the electronic devices in the drive code when the electronic devices are probed. And the I2C address of each electronic device in the current project can be configured in the DTSI equipment tree file, and the electronic device is used for judging the communication condition of the electronic device based on the I2C address after the names of the electronic devices are matched. It can be understood that the device name which 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 color temperature sensor which can be mounted is A2, and the device names acquired based on the DTSI device tree file are A3 and A4, so that it is proved that the electronic device corresponding to A2 cannot exist in the electronic device, and therefore, subsequent detection, for example, detection of whether subsequent communication is normal or not, is not needed, the detection flow can be effectively simplified, and resources are saved.

S502: and reading the name and the corresponding I2C address of the electronic device in the KO drive of the kernel layer, and assigning the I2C address read in the DTSI equipment tree file to a predefined function pointer group to form a device function list for detecting the electronic device.

In some embodiments, the function pointer groups may refer to function pointer groups, which are predefined in the compiling stage, the function pointer groups are essentially a structure body array, each function pointer group includes a name, an i2c address, and a function corresponding to the electronic device that can be carried, and the function may include: get_chip_ id, probe, remove, suspend and resume functions, etc.

In some embodiments, each function pointer group may correspond to an array identification, such as an array index, which may be in digital form, or the like.

In actual detection, the name of an electronic device and a corresponding I2C address are read in KO drive of a kernel layer, device names in all the arrays are matched based on the device names acquired by the DTSI device tree file, a corresponding function pointer group to be selected is acquired, and the I2C address corresponding to the device names acquired based on the DTSI device tree file is assigned to a register address (reg-addr) of the corresponding function pointer group to be selected. And taking the device which is normally communicated in the electronic devices corresponding to the function pointer group to be selected as the device actually carried by the current electronic equipment, and carrying out initializing configuration of the device based on the function in the function pointer group to be selected. For example, the electronic device may support the mounted devices A1-A5, which correspond to respective groups of function pointers, and the subscripts of the respective groups of function pointers may be 1-5; further, based on the devices A3, A4 parsed from the DTSI device count. And respectively matching the names of each device in the devices A1-A5 with the names of the two devices analyzed from the equipment tree, and assigning the I2C address corresponding to the matched device to a corresponding function pointer group for storage when the names are matched, so that the matched device can be initialized and configured based on the function in the function pointer group corresponding to the matched device.

It will be appreciated that the name of the electronic device, the i2c address and the function may be included in the list of device functions, for example the function may include: get_chip_ id, probe, remove, suspend and resume, etc.

It can be understood that polling refers to sequentially determining whether the name of the color temperature sensor in the currently polled function pointer group is matched with the name of the color temperature sensor in the color temperature sensor name list (color_sensor_list), if so, ending polling, and storing the I2C address corresponding to the color temperature sensor in the function pointer group reg-addr; if not, continuing to judge whether the next color temperature sensor is matched with the array.

S503: and determining the name matching and I2C communication conditions of the electronic devices based on the get_chip_id function so as to confirm the electronic devices actually carried by the current electronic equipment.

It will be appreciated that the get_chip_id function may be used to determine whether the names of the currently detected electronic devices match and whether I2C communications are normal.

In some embodiments, an id (name) of an actually-mounted electronic device may be read through a key function (get_chip_id) corresponding to the currently-detected mountable device based on the corresponding I2C address, and when the id can be read and the read id is matched with the id in the function pointer group, it may be determined that the currently-detected mountable electronic device is an actually-mounted electronic device and communication is normal, and the currently-detected mountable electronic device is taken as the actually-mounted electronic device.

In some embodiments, it may be possible to confirm whether the currently detected electronic device is an electronic device actually carried by the electronic device by monitoring the return value. For example, when the return value is "true", it is determined that the currently detected electronic device is an electronic device actually carried by the electronic device, and an array index of a corresponding function pointer group of the current electronic device is saved.

S504: and calling a probe function corresponding to the electronic device actually carried on the electronic device based on the determined array subscript corresponding to the electronic device actually carried on the electronic device, and binding the functions of the electronic device.

In some embodiments, when the get_chip_id function determines that the names of the current color temperature sensors match and that the I2C communication is normal, an instance of a current color temperature sensor driver (color_ops) array is saved, i.e., an array index is saved. For example, it is determined that the electronic device is mounted with the current color temperature sensor TCS3408, the index of the color_driver_ops array corresponding to the current color temperature sensor TCS3408 is 3, then the array 3 of the current color temperature sensor TCS3408 is saved, the color temperature sensor TCS3408 is called and driven based on the function in the array 3, namely, the color temperature sensor successfully detected is bound to the color temperature sensor interface through the device detection and function binding module, the color temperature sensor successfully detected is bound to the public node inlet through the color temperature sensor interface, and functions such as functional binding and initialization of the color temperature sensor TCS3408 and upper application are realized through the public node inlet.

In some embodiments, when the system loads a module or creates an instance for the module, for example, when the KO module saves an array of color temperature sensors TCS3408, the system automatically allocates memory space for the color temperature sensors TCS3408 for the KO module, and after allocating memory, automatically initializes environmental variables, then initializes hardware, starts an operating system, etc. with the environmental variables.

In some embodiments, when the color temperature sensor TCS3408 detects failure, the device detection and function binding module does not bind the color temperature sensor TCS3408 to the color temperature sensor interface, i.e., to the common node portal for function binding with the upper layer.

Based on the method, the initialization configuration can be carried out on the actual carrying device by directly matching the corresponding function in the function pointer group according to the array corresponding to the identified actual carrying device, so that when a plurality of alternative electronic devices exist on the same base line, the number of the function functions is reduced, and the loading time required to search for and match the corresponding function functions again is long.

In some embodiments, the function pointer group further includes function functions such as probe, remove, suspend and resume functions corresponding to each electronic device, after determining that the electronic device is actually carried, function binding and initialization processes of the device can be directly performed based on a probe function in the function pointer group, and in addition, a remove function can be used for cleaning corresponding memory resources when the electronic device is removed from the kernel layer; the suspend function can manage the sleep of the power management module; the resume function may manage power restoration. Therefore, functions required to be used by the device are normalized, corresponding function functions in the function pointer group can be directly matched according to the identified actual carried device, and when a plurality of alternative electronic devices exist in the same base line, the function functions are multiple, and loading time consumption caused by the fact that the corresponding function functions need to be matched again is shortened.

In addition, in the embodiment of the application, the information of a plurality of electronic devices possibly used for the detection result is partially obtained through configuration in the DTSI equipment tree file, the configuration information of the electronic devices is dynamically obtained by creatively adopting a global electronic device array mode, and the actually carried electronic devices are confirmed when the electronic devices are detected, so that dynamic electronic device identification is realized. After the electronic device actually carried by the electronic device is correctly detected, other electronic devices do not need to be detected, so that the problem of flow redundancy is greatly solved, and the detection efficiency is improved.

In addition, the color temperature sensor which is not actually carried by the electronic equipment is not directly registered in the power management module through the public node inlet, so that the operation that the power management module repeatedly suspends and restores the virtual device due to the existence of the suspended virtual device in the power management module is avoided, and the problem of resource waste in the scheme is solved.

The following describes a specific flow of the device initialization method provided in the present application.

Referring to fig. 6, fig. 6 shows a specific flow diagram of a device initialization method. For easy understanding, an electronic device is taken as an example of a color temperature sensor, and the specific flow comprises:

S601: the common entry function (mod_init) is initialized.

In some embodiments, each driver has a statement mod_init that indicates that the driver command is automatically executed at system start-up, i.e., defines a common population function mod_init.

S602: initializing the color_driver_ops array.

In some embodiments, the color_driver_ops array is initialized, where the color_driver_ops array includes names of color temperature sensors, I2C communication addresses, function functions, etc. supported in the kernel-layer compiled driver code. The function functions may include a probe detection function, a remove removal detection function, a suspend power supply suspension function, a resume power supply recovery function, and the like.

For example, if there are 5 color temperature sensors that can be mounted, 5 function pointer groups may be set, and for example, the names of the color temperature sensors S1 to S5, I2C communication addresses, function functions, and the like may be included in the function pointer groups. The function functions may include a probe detection function, a remove removal detection function, a suspend power supply suspension function, a resume power supply recovery function, and the like. It is understood that the array indices of the function pointer groups of different color temperature sensors are all different, for example, the array indices of the color temperature sensors S1-S5 may correspond to 1-5. It will be appreciated that the subscripts of the arrays of the different color temperature sensors may be preset to any value at the time of initial compiling, and the like, and are not limited herein.

S603: the i2c_add_driver function of the ith color temperature sensor is called based on the common entry function.

In some embodiments, the ith color temperature sensor i2c_add_driver function may be invoked based on a common entry function so that each color temperature sensor may be registered into the device chain table of the KO module. The device chain table is a set of compatible electronic devices in the kernel layer.

S604: the Client pointer is empty.

In some embodiments, the transmission parameters of the color temperature sensor may be determined to be empty based on a Client (Client) pointer, that is, the system memory allocation and the driving code information may be checked to ensure that the transmission parameters, such as the name of the color temperature sensor, the I2C communication address, the key function, etc., are not empty in the color_driver_ops array.

S605: client- > dev preservation.

In some embodiments, the structure corresponding to the Client- > dev Client is saved, i.e. the color_driver_ops array is saved.

It can be understood that the color_driver_ops array includes a name, an I2C communication address, a function, and the like of each color temperature sensor supported in the kernel layer compiled driving code, where the function may include a probe detection function, a remove removal detection function, a suspend power supply suspension function, a resume power supply recovery function, and the like.

S606: and acquiring the structural body of the power management module Ido from the DTSI equipment tree file.

In some embodiments, the structure of the power management module Ido is obtained from the DTSI device tree file of the kernel layer, and it can be understood that the Ido is the power management module, and may control suspension and recovery of the power management module.

S607: powering up the power management module Ido based on the regulator-enable function.

In some embodiments, the power management module Ido is controlled to power up by a regulator-enable function.

S608: and resolving an address list and a name list of the color temperature sensor from the DTSI equipment tree file.

In some embodiments, address lists and name lists of the color temperature sensor are parsed based on a DTSI device tree file. For example, the driver code of the kernel layer includes information supporting the mounted color temperature sensors S1 to S5, and the information such as the address list and the name list of the color temperature sensors S1 to S3 can be analyzed by the DTSI device tree file.

It can be appreciated that the DTSI device tree file may include name information and communication address information of the electronic device, and the electronic device may be parsed based on the DTSI device tree file.

S609: the polling array matches the name of the color temperature sensor.

In some embodiments, each identification information (for example, a color temperature sensor name) and each I2C address of a color temperature sensor that can be configured by a current item of the electronic device may be obtained based on a DTSI device tree file corresponding to the electronic device. And matching color temperature sensor names in the function pointer groups based on the color temperature sensor names acquired by the DTSI file to acquire corresponding function pointer groups to be selected, and assigning I2C addresses corresponding to the color temperature sensor names acquired by the DTSI equipment tree file to the corresponding function pointer groups to be selected.

In some embodiments, the color temperature sensor may be named: TCS3408, BU27006, a57341, etc., are not limited herein. Judging whether the name of the currently polled color temperature sensor is matched with the name of the color temperature sensor in a color temperature sensor name list (color_sensor_list) based on the name of the color temperature sensor, and if so, going to step S610, storing the I2C address corresponding to the current color temperature sensor into an array register address (reg-addr). Otherwise, go to step S612, continue polling to determine if it matches the name of the next color temperature sensor.

S610: and storing the I2C address of the matched color temperature sensor into an array reg-addr.

In some embodiments, color temperature sensor names in each function pointer group are matched based on the color temperature sensor names acquired by the DTSI file, corresponding function pointer groups to be selected are acquired, and I2C addresses corresponding to the color temperature sensor names acquired by the DTSI equipment tree file are assigned to register addresses reg-addr of the corresponding function pointer groups to be selected.

S611: the address list of the array is updated.

In some embodiments, it may be understood that the function pointer set is an array, the initial register addresses reg-addr of the array are all assigned with 0 or other default values, when the current color temperature sensor is determined to be a color temperature sensor capable of being carried in the electronic equipment item, the array reg-addr may be updated, and the I2C communication address obtained by analyzing the DTSI equipment tree file is assigned to the reg-addr.

S612: and updating the name list of the array.

In some embodiments, it can be appreciated that when the name of the currently polled color temperature sensor is initially determined with the color temperature sensor name list, the name corresponding to the current color temperature sensor can be updated. For example, the color temperature sensor S3 is currently detected, the array initialized in step S602 is polled, whether the name of the current color temperature sensor matches the name of the color temperature sensor in the initialized array is determined, and if yes, 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.

It will be appreciated that in other embodiments, when it is determined by polling the array that the array does not match the name of the current color temperature sensor, the process may return to step S609 to continue to poll whether the name of the next color temperature sensor may match the name of the color temperature sensor in the array.

S613: whether communication is normal is judged based on the get_chip_id function.

It is understood that chip_id may be a code of the color temperature sensor type. Whether the names of the current color temperature sensor are matched or not and whether the I2C communication is normal or not can be judged through the get_chip_id function, a return value is monitored, and whether the current detected electronic device is an electronic device actually carried by the electronic equipment or not is confirmed through the return value. For example, when the return value is "true", it is determined whether the currently detected electronic device is an electronic device actually carried by the electronic device, and a corresponding array index of the current electronic device is saved, that is, when the electronic device names match and the communication is normal, the process goes to step S615, and the current color_driver_ops instance is saved. Otherwise, go to step S614 to update the array index.

S614: updating the array subscript.

In some embodiments, when the get_chip_id function determines that the current color temperature sensor is abnormal in communication, the process returns to step S613 to continuously match whether the I2C of the next color temperature sensor is normal in communication based on the get_chip_id function, and if the name of the next color temperature sensor is matched with the name of the corresponding color temperature sensor in the array and the I2C is normal in communication, the array index is updated to the array index of the color temperature sensor corresponding to the normal communication.

S615: and storing the current color_driver_ops instance and the array subscript.

In some embodiments, when the get_chip_id function determines that the names of the current color temperature sensors match and the I2C communication is normal, the current color_driver_ops array instance is saved, i.e., the array index is saved. For example, if it is determined that the electronic device is mounted with the current color temperature sensor TCS3408 and the index of the color_driver_ops array corresponding to the current color temperature sensor TCS3408 is 3, 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, so that the color temperature sensor TCS3408 can be connected with an upper layer and realize a corresponding function.

S616: an environment variable is initialized.

In some embodiments, it will be appreciated 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 KO module stores an array of color temperature sensors TCS3408, the system automatically allocates memory space for the color temperature sensors TCS3408 and after allocating memory, automatically initializes the environment variable, then initializes hardware, starts an operating system, etc. with the environment variable.

S617: and calling a probe function of the current color_driver_ops array.

In some embodiments, the probe function of the saved color_driver_ops array 3 is called to realize detection of 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 may be called, the cleaning of the memory resource of the color temperature sensor may be performed based on the remove removal function, the power sleep may be managed based on the suspend, and the power restoration may be managed based on the resume.

Based on the above, when the device detection is performed, whether the I2C communication is abnormal or not is judged, whether the names of the electronic devices are matched or not is also judged, the detection accuracy can be improved, and the situation that the electronic device actually carried by the electronic equipment is the device B due to the fact that some compatible electronic devices are identical in possible wiring mode is avoided, the communication condition is normal when the device A is detected, and the device A is the actually carried device is misjudged.

Fig. 7 illustrates a system schematic diagram of an electronic device (e.g., a mobile phone 10 described herein) provided according to some embodiments of the present application.

It should be understood that the illustrated structure of the embodiment of the present invention is not intended to limit the specific structure of the mobile phone 10. In other embodiments of the present application, the handset 10 may include more or fewer components than shown, or certain components may be combined, certain components may be split, or different arrangements of components may be provided. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

The handset 10 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (universal serial bus, USB) connector 130, a charge 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, keys 190, a motor 191, an indicator 192, a camera 193, a display 194, and a subscriber identity module (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 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, and the like.

The processor 110 may include one or more processing units, such as: the processor 110 may include an Application Processor (AP), a modem processor, a graphics processor (graphics processing unit, GPU), an image signal processor (image signal processor, ISP), a controller, a video codec, a digital signal processor (digital signal processor, DSP), a Baseband Processor (BP), and/or a neural network processor (neural-network processing unit, NPU), etc. Wherein the different processing units may be separate devices or may be integrated in one or more processors.

A memory may also be provided in the processor 110 for storing instructions and data.

The charge management module 140 is configured to detect a charge input from a charger. The charger can be a wireless charger or a wired charger. In some embodiments, the charge management module 140 may detect a charging input of the wired charger through the USB interface 130. In other embodiments, the charge management module 140 may detect a wireless charge input through a wireless charging coil of the handset 10. The charging management module 140 may also supply power to the electronic device through the power management module 141 while charging the battery 142.

The power management module 141 is used for connecting the battery 142, and the charge management module 140 and the processor 110. The power management module 141 detects inputs from the battery 142 and/or the charge management module 140 to power the processor 110, the internal memory 121, the external memory 120, the display 194, the camera 193, the wireless communication module 160, and the like. The power management module 141 may also be configured to monitor battery capacity, battery cycle number, battery health (leakage, impedance) and other parameters. In some embodiments, the power management module 141 may also be provided in the processor 110. In some embodiments, the power management module 141 and the charge management module 140 may also be provided in the same device. In some embodiments, the power management module 141 may perform power configuration for the configuration of the electronic device in the embodiments of the present application.

The wireless communication function of the mobile phone 10 can be implemented by the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, a modem processor, a baseband processor, and the like.

The antennas 1 and 2 are used for transmitting and detecting electromagnetic wave signals. Each antenna in the handset 10 may be used to cover a single or multiple communication bands. Different antennas may also be multiplexed to improve the utilization of the antennas. For example: the antenna 1 may be multiplexed into a diversity antenna of a wireless local area network. In other embodiments, the antenna may be used in conjunction with a tuning switch.

The mobile communication module 150 may provide a solution for wireless communication including 2G/3G/4G/5G, etc. applied to the handset 10.

The modem processor may include a modulator and a demodulator. The modulator is used for modulating the low-frequency baseband signal to be transmitted into a medium-high frequency signal. The demodulator is used for demodulating 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. The low frequency baseband signal is processed by the baseband processor and then transferred to the application processor.

The wireless communication module 160 may provide solutions for wireless communication including wireless local area network (wireless local area networks, WLAN) (e.g., wireless fidelity (wireless fidelity, wi-Fi) network), bluetooth (BT), global navigation satellite system (global navigation satellite system, GNSS), frequency modulation (frequency modulation, FM), near field wireless communication technology (near field communication, NFC), infrared technology (IR), etc. applied to the handset 10.

The handset 10 implements display functions through a GPU, a display 194, and an application processor, etc. The GPU is a microprocessor for image processing, and is connected to the display 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 110 may include one or more GPUs that execute program instructions to generate or change display information.

The display screen 194 is used to display images, videos, and the like. The display 194 includes a display panel.

The handset 10 may implement shooting functions through an ISP, a camera 193, a video codec, a GPU, a display 194, an application processor, and the like.

The ISP is used to process data fed back by the camera 193.

The camera 193 is used to capture still images or video. The object generates an optical image through the lens and projects the optical image onto the photosensitive element.

The digital signal processor is used for processing digital signals, and can process other digital signals besides digital image signals. For example, when the handset 10 selects a frequency bin, the digital signal processor is used to fourier transform the frequency bin energy, etc.

The external memory 120 is generally referred to as an external memory, and common external memories include a hard disk, a floppy disk, an optical disk, a usb disk, a Micro SD card, etc. for implementing the memory capability of the mobile phone 10. The external memory may communicate with the processor 110 through an external memory interface or bus to implement data storage functions.

Internal memory 121, which may also be referred to as "memory," may be used to store computer-executable program code, including instructions.

The handset 10 may implement audio functions through an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, an application processor, and the like. Such as music playing, recording, etc.

The pressure sensor 180A is used to sense a pressure signal, and may convert the pressure signal into an electrical signal.

The gyro sensor 180B may be used to determine the motion gesture of the handset 10. In some embodiments, the angular velocity of the handset 10 about three axes (i.e., x, y, and z axes) may be determined by the gyro sensor 180B.

The air pressure sensor 180C is used to measure air pressure.

The magnetic sensor 180D includes a hall sensor.

The acceleration sensor 180E can detect the magnitude of acceleration of the mobile phone 10 in various directions (typically three axes).

A distance sensor 180F for measuring a distance.

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.

The ambient light sensor 180L is used to sense ambient light level. The handset 10 may adaptively adjust the brightness of the display 194 based on perceived ambient light levels.

The fingerprint sensor 180H is used to collect a fingerprint. The mobile phone 10 can utilize the collected fingerprint characteristics to realize fingerprint unlocking, access application locks, fingerprint photographing, fingerprint incoming call answering and the like.

The temperature sensor 180J is for detecting temperature.

The touch sensor 180K, also referred to as 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, which is also called a "touch screen".

The bone conduction sensor 180M may acquire a vibration signal.

The color temperature sensor 180N may be used to detect a light source color or color temperature. And the device can also be used for transmitting corresponding electric signals according to the color or the color temperature of the light source, so that corresponding binary information after the electric signals are converted can be identified by a machine. In some embodiments, the color temperature sensor may automatically adjust the screen color temperature of the electronic device according to the color temperature of the environment, and may be used to detect the color temperature of the environment as the electronic device is photographed, so that the photographed video or image is more accurate in color, or the image is color calibrated, etc.

The keys 190 include a power-on key, a volume key, etc. The keys 190 may be mechanical keys. Or may be a touch key. The handset 10 may detect key inputs, generating key signal inputs related to user settings and function control of the handset 10.

The motor 191 may generate a vibration cue. The motor 191 may be used for incoming call vibration alerting as well as for touch vibration feedback.

The indicator 192 may be an indicator light, may be used to indicate a state of charge, a change in charge, a message indicating a missed call, a notification, etc.

The SIM card interface 195 is used to connect a SIM card.

The method embodiments of the present application may be implemented in software, magnetic, firmware, or a combination of these implementations.

Program code may be applied to input instructions to perform the functions described herein and generate output data. The output data may be applied to one or more output devices in a known manner.

The program code may be implemented in a high level procedural or object oriented programming language to communicate with a processing system. Program code may also be implemented in assembly or machine language, if desired. Indeed, the mechanisms described herein are not limited in scope to any particular programming language. In either case, the language may be a compiled or interpreted language.

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, which when read by a machine, cause the machine to fabricate logic to perform the techniques described herein. These representations, referred to as "IP cores," may be stored on a tangible computer readable storage medium and provided to a plurality of customers or production facilities for loading into the manufacturing machine that actually manufactures the logic or processor.

While the description of the present application will be presented in conjunction with the preferred embodiments, it is not intended that the features of this application be limited to only this implementation. Rather, the invention has been described in connection with specific embodiments, and is intended to cover various alternatives or modifications, which may be extended by the claims based on this application. The following description contains many specific details in order to provide a thorough understanding of the present application. The present application may be practiced without these specific details. Furthermore, some specific details are omitted from the description in order to avoid obscuring the focus of the application. It should be noted that, in the case of no conflict, the embodiments and features in the embodiments may be combined with each other.

Moreover, various operations will be described as multiple discrete operations in a manner that is most helpful in understanding the illustrative embodiments; however, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations need not be performed in the order of presentation.

As used herein, the term "module" or "unit" may refer to, be or include: an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) and/or memory that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality.

In the drawings, some structural or methodological features are shown in a particular arrangement and/or order. However, it should be understood that such a particular arrangement and/or ordering may not be required. In some embodiments, these features may be arranged in a different manner and/or order than shown in the illustrative figures. Additionally, the inclusion of structural or methodological features in a particular figure is not meant to imply that such features are required in all embodiments, and in some embodiments, may not be included or may be combined with other features.

Embodiments of the present application may be implemented as a computer program or program code that is executed on a programmable system comprising a plurality of processors, a storage system (including volatile and non-volatile memory and/or storage elements), a plurality of input devices, and a plurality of output devices.

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 logic in a processor, which when read by a machine, cause the machine to fabricate logic to perform the techniques described herein. These representations, referred to as "IP cores," may be stored on a tangible computer readable storage medium and provided to a plurality of customers or production facilities for loading into the manufacturing machine that actually manufactures the logic or processor.

Thus, embodiments of the present application also include non-transitory computer-readable storage media containing instructions or containing design data, such as Hardware Description Language (HDL), that define the structures, circuits, devices, processors, and/or system features described herein.

Claims

1. A device initialization method, characterized by being applied to an electronic apparatus, the electronic apparatus including a first device;

the method comprises the following steps:

detecting that the electronic device is started;

acquiring first identification information and a first communication address corresponding to a first device to be initialized based on an equipment configuration file of the electronic equipment;

determining the first identification information, and matching the first identification information with the stored second identification information of the second device;

acquiring first initialization information corresponding to the second device;

and carrying out initialization configuration on the first device based on the first initialization information when the communication of the second device is determined to be normal based on the first communication address.

2. The method of claim 1, wherein the first identification information and the first communication address corresponding to the first device to be initialized are obtained based on a device configuration file of the electronic device; comprising the following steps:

Acquiring an identification information set and a communication address set corresponding to the first device to be initialized based on an equipment 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 of claim 2, wherein the determining that the second device communicates normally is based on a first communication address; comprising the following steps:

reading third identification information of the first device based on a first device identification function corresponding to the second device and the first communication address;

and when the third identification information is matched with the second identification information of the second device, determining that the communication of the second device is normal.

4. A method according to claim 3, wherein the electronic device stores a first function pointer group corresponding to the second device, and the first function pointer group includes the second identification information, the first initialization information, and the first device identification function;

and corresponding to the first identification information of the first device, matching with the stored second identification information, and establishing the association between the first communication address and the first function pointer group.

5. The method of claim 4, the initializing the first device based on the first initialization information, comprising:

determining identification information of a first function pointer group corresponding to the second device;

and calling the first initialization information based on the identification information of the first function pointer group to perform initialization configuration on the first device.

6. The method of any of claims 1-5, wherein the first initialization information comprises a probe function, a remove function, a power suspend function, and a power resume function.

7. The method according to any one of claims 1 to 5, wherein the electronic apparatus stores identification information of a plurality of loadable devices corresponding to the first device;

the first identification information is determined to be matched with the stored second identification information of the second device; comprising the following steps:

and determining the second identification information matched with the first identification information from the identification information of the plurality of the devices capable of being carried.

8. An electronic device comprising a memory for storing instructions;

a processor for executing the instructions to cause the electronic device to implement the device initialization method of any one of claims 1-7.

9. A readable storage medium having stored thereon instructions that, when executed on an electronic device, cause the electronic device to perform the device initialization method of any of claims 1-7.

10. A computer program product comprising instructions that, when executed on an electronic device, cause the electronic device to perform the device initialization method of any one of claims 1-7.